1.5 パフォーマンス
ここまでの議論は主にネットワークの機能に関する側面を考えてきた。しかし、あらゆるコンピューターシステムと同じように、コンピューターネットワークには効率の良い動作も求められる。これはネットワークを通じて分散される計算の有用性が計算で使われるデータのネットワークを通じた転送効率に大きく左右されることがよくあるためである。「まず正しくせよ。それから速くせよ」というプログラミングの古い格言は今も正しいものの、ネットワークでは「パフォーマンスのための設計」が必要になる場合が多い。そのためネットワークのパフォーマンスに影響する様々な要因を理解しておくことが重要となる。
1.5.1 帯域とレイテンシ
ネットワークのパフォーマンスを測定する重要な指標として、帯域 (bandwidth) と レイテンシ (latency) の二つがある。帯域はスループット (throughput) とも呼ばれ、レイテンシは遅延 (delay) とも呼ばれる。ネットワークの帯域とは単位時間あたりにネットワークを通して転送できるビット数を言う。例えば、あるネットワークが 10 メガビット毎秒 (megabit per second, Mbps) の帯域を持つなら、そのネットワークは 1 秒ごとに 10 メガビット (1000 万ビット) のデータを転送できる。帯域を 1 ビットを転送するのにかかる時間を表すものとして捉えると考えやすい場合もあるので覚えておくといいだろう。例えば帯域が 10 Mbps のネットワークでは、1 ビットの転送に 0.1 マイクロ秒 (μs) の時間がかかる。
帯域とスループットは少しだけ違う意味を持つ。まず、帯域は文字通り周波数帯 (frequency band) の幅を意味することがある。例えばレガシーな音声用電話回線 (voice-grade telephone line) は 300 Hz から 3300 Hz の周波数帯をサポートするので、3300 - 300 = 3000 Hz の帯域を持つと言われる。「帯域」の単位がヘルツのときは、その数値はおそらく回線が伝えられる信号の範囲を示している。
通信リンクについて話をしているとき、通常「帯域」は 1 秒あたりにリンクを通じて転送できるビット数を意味する。この値はビットレート (bit rate) とも呼ばれる。例えば「このイーサネットリンクの帯域は 10 Mbps だ」のように使う。一方で「リンクで利用可能なデータレートの理論的最大値」と「実際に使ったときに 1 秒あたりに転送できるビット数」の区別が必要になる場合も多い。後者のようにシステムの測定されたパフォーマンスを表すときは「スループット」がよく使われる。例えば「実装が非効率なので、帯域 10 Mbps のリンクで接続されたノードの組が 2 Mbps のスループットしか持たない」などと言う。この一文は、いずれかのホストで実行されるアプリケーションがもう一方のホストにデータを送るときの速度が 2 Mbps にしかならないことを意味する。
最後に、アプリケーションの帯域要件 (bandwidth requirement) という言葉がよく使われる (「スループット要件」とは普通言わない)。帯域要件とはアプリケーションが快適に動作するためにネットワークを通じてピアと通信する必要がある 1 秒あたりのビット数を言う。例えば、あるアプリケーションでは帯域要件が「ある分だけ欲しい」かもしれないし、何らかの固定された値があるかもしれない (この値が利用可能なネットワーク帯域を超えないことが望ましい)。あるいは時間の経過とともに帯域要件が変化する場合もあるだろう。この話題は本節の最後でさらに触れる。
ネットワーク全体の帯域を議論したいこともあれば、もっと細かい部分、例えば単一の物理リンクあるいは論理的プロセス間チャンネルの帯域に注目したい場合もある。物理レベルの帯域は止むことなく向上しており、限界は見えていない。帯域を直感的に説明しよう。1 秒の時間を線分として表すと、帯域はその線分に詰め込めるビット数、各ビットは同じ幅のパルスとして表せる。例えば 1 Mbps リンクの各ビットは 1 μs の幅を持ち、2 Mbps リンクの各ビットは 0.5 μs の幅を持つ (図 16)。データの送受信技術が高度になると各ビットは薄くなり、帯域は増加する。論理的なプロセス間チャンネルの帯域はチャンネルを実装するソフトウェアがデータの各ビットに対して行う処理 (あるいは変形) など、他の要因にも影響を受ける。
二つ目のパフォーマンスの指標であるレイテンシは、メッセージがネットワークの端から端まで伝わるのにかかる時間を意味する (帯域と同様に、単一のリンクやプロセス間チャンネルのレイテンシに注目することもできる)。レイテンシは厳密に時間だけで測定される。例えば大陸横断ネットワークが 24 ミリ秒 (ms) のレイテンシを持つと言った場合、それは北アメリカの端から端までメッセージを伝達するのに 24 ms かかることを意味する。レイテンシが表す「メッセージがネットワークの端に届くまでの時間」ではなく、「メッセージをネットワークの端に送って、その返事が返ってくるまでの時間」がより重要になる状況も多い。この値は RTT (round-trip time, ラウンドトリップタイム) と呼ばれる。
レイテンシは三つの要素からなると考えることが多い。第一に、光速伝播遅延 (speed-of-light propagation delay) がある。この遅延が発生するのは、リンクを伝わるビットを含めたどんなものも光速より速く移動できないためである。二点間の距離が分かれば、その間を接続するネットワークの光速伝播遅延を計算できる。ただし媒体によって光速が異なることには注意が必要となる: 真空では 3.0×108 m/s、銅線では 2.3×108 m/s、光ファイバー線では 2.0×108 m/s となる。第二に、データを一定の単位 (パケット) ごとにまとめて転送するために発生する遅延がある。この値はネットワークの帯域およびデータを運ぶときに使われるパケットのサイズの関数である。第三に、ネットワークの内部でのキュー待ち遅延 (queuing delay) がある: 通常スイッチはパケットを転送する前にパケットを内部のバッファに保存する。まとめると、全体のレイテンシは次のように表せる:
Latency = Propagation + Transmit + Queue
Propagation = Distance/SpeedOfLight
Transmit = Size/Bandwidth
ここで Distance はデータが伝わる回線の長さ、SpeedOfLight は回線における光の実効速度、Size はパケットの大きさ、Bandwidth はパケットが転送されるときの帯域をそれぞれ表す。なお、1 ビットのメッセージを (ネットワーク全体だけではなく) 単一のリンクを通して送るときのレイテンシを考えるときは Transmit と Queue からの影響は無くなり、レイテンシは光速伝播遅延だけから決定することに注意してほしい。
帯域とレイテンシからリンクあるいはチャンネルのパフォーマンス特性が定まる。ただし、どちらがどれだけ重要かはアプリケーションによって異なる。一部のアプリケーションではレイテンシがパフォーマンスを支配する: 例えば、クライアントが 1 バイト (B) のメッセージをサーバーに送り、サーバーから 1 B の応答を受け取るアプリケーションはレイテンシバウンドである。応答の準備に複雑な計算が関係しないと仮定すれば、このアプリケーションの動作は RTT が 100 ms の大陸横断チャンネルを使う場合と RTT が 1 ms の部屋を横切るチャンネルを使う場合で大きく変化する。一方で、チャンネルが 1 Mbps であろうと 100 Mbps であろうと動作にはあまり影響しない: 1 B を送るのにかかる時間 Transmit はそれぞれ 8 μs と 0.08 μs であり、差は無視できるほどに小さい。
これと対照的なシナリオとして、25 メガバイト (MB) の画像を取得するよう指示された電子図書館プログラムを考えよう。このときは利用可能な帯域が大きければ大きいほどユーザーにそれだけ速く画像を届けられる。つまりここでは、チャンネルの帯域がパフォーマンスを支配する。具体的な数字を使って考えてみよう。チャンネルが 10 Mbps の帯域を持つとすれば、画像の転送には (25×106×8) / (10×106) = 20 秒の時間がかかる。このとき画像があるサーバーとの RTT が 1 ms なのか 100 ms なのかは大して問題にならない: 20.001 秒 と 20.1 秒 の違いは無視できる程度である。
様々な設定でレイテンシと帯域のどちらがパフォーマンスを支配するかを示すグラフを図 17 に示す。このグラフは様々なサイズ (1 B, 2 KB, 1 MB) のオブジェクトを様々な速度 (1.5 Mbps または 10 Mbps) のリンクで送るときに、ネットワークの RTT を 1 ms から 100 ms まで変えると送信にかかる時間がどれだけ変わるかを示している。相対的なパフォーマンスを分かりやすくするために対数目盛を使用した。1 B のオブジェクト (例えばキーストローク) を送信するときはレイテンシがほぼ RTT に等しくなるので、1.5 Mbps のネットワークと 10 Mbps のネットワークがほとんど見分けられない。2 KB のオブジェクト (例えばメール) を転送するときは、RTT が 1 ms ならリンク速度が大きな違いを生むのに対して、RTT が 100 ms ならリンク速度はほとんど無視できる程度の違いしか生まない。最後に、1 MB のオブジェクト (例えばデジタル画像) を転送するときは、RTT がほとんど影響しない ── RTT がどんな値であれ、パフォーマンスを支配するのはリンク速度となる。
本書ではレイテンシ (latency) と遅延 (delay) を特定の操作を行うのにかかる時間を表す一般的な用語として使っていく。「特定の操作」とは例えばメッセージの転送やオブジェクトの移動を指す。リンクの片方の端からもう一方の端まで信号を伝播させるのにかかる時間は伝播遅延 (propagation delay) と呼ぶ。また、片道の遅延を指しているのかラウンドトリップタイムを指しているのかは文脈で明らかにしていく。
余談: 現代のコンピューターは非常に速い。そのため、ネットワークに接続して何か処理を行うときは 1 キロごとの命令数 (instructions per kilometer) を (最低でも頭の中で) 考えると役立つ場合がある。1 秒間に 1000 億個の命令を実行できるコンピューターから RTT が 100 ms のチャンネルにメッセージが送信されたとしよう (計算が簡単になるように、メッセージは 5000 キロの長さを転送されるとする)。コンピューターが応答を待つ 100 ms の間ずっと待ちぼうけだとしたら、100 億回の命令を実行する機会が失われる。このとき 1 キロごとの命令数は 200 万である。ネットワーク越しの通信は無駄になる命令を正当化するだけの意味を持たなければならない。
1.5.2 帯域遅延積
ここまでに議論した二つの指標の積も帯域遅延積 (bandwidth-delay product) と呼ばれる有用な指標となる。 図を使って説明しよう。プロセス間のチャンネルを図 18 のような中空の管 (パイプ) と考えるとき、帯域はパイプの直径に、遅延はパイプの長さに対応する。このとき帯域遅延積はパイプの体積となる ── つまり、ある瞬間に転送状態でいられるデータのビット数を表す。別の言い方をすればこうなる: レイテンシ (秒で表される) がパイプの長さに対応するなら、各ビットの幅 (同じく秒で表される) が与えられればパイプの中に詰められるビットの個数を計算できる。例えば大陸横断チャンネルのレイテンシが片道 50 ms で帯域が 45 Mbps なら、パイプの中に詰められるビットの個数は次のように計算できる:
つまり約 280 KB である。言い換えれば、例として出したこのチャンネルは 1980 年代初頭のパソコンが持っていたメモリと同程度のデータを保持できる。
高パフォーマンスネットワークを構築するときは帯域遅延積を意識することが重要になる。受信側に最初のビットが届くまでに送信側から送られることが期待されるビット数が帯域遅延積だからである。データが届き始めたこと伝える信号を受信側から送ってほしいと送信側が思っていて、その信号が送信側に伝播するまでにもチャンネルのレイテンシだけかかるとすれば、送信側は受信側からデータが正しく届いたと伝えられる前に RTT と帯域の積だけのデータを送信できる。また、受信側がデータの転送を停止せよと送信側に伝えたとしても、転送が止むまでの間に受信側は RTT と帯域の積だけのデータを受け取る可能性がある。上述の例で言えば、これは 5.5×106 ビット (約 671 KB) である。一方で、もし送信側がパイプを埋めないなら ── 受信側からの信号を受け取るまでに RTT と帯域の積だけのデータを送信しないなら ── 送信側はネットワークを完全に利用できていない。
なお、帯域遅延積を話題にするときはたいてい RTT を考えるので、「帯域遅延積」の「遅延」が RTT (片道のレイテンシの二倍) を意味することがある点には注意が必要である。「遅延」が片道のレイテンシと RTT のどちらを意味するかは文脈を考えれば普通は分かる。典型的なネットワークリンクに対する RTT と帯域の積を表 1 に示す。
| リンクの種類 | 帯域 | 片道の距離 | RTT | RTT と帯域の積 |
|---|---|---|---|---|
| 無線 LAN | 54 Mbps | 50 m | 0.33 μs | 18 ビット |
| 衛星リンク | 1 Gbps | 35,000 km | 230 ms | 230 Mb |
| 大陸横断光ファイバーリンク | 10 Gbps | 4,000 km | 40 ms | 400 Mb |
1.5.3 高速ネットワークのパフォーマンス特性
天井知らずに増加を続ける帯域を見て、ネットワーク設計者は極限において何が起こるか、つまり無限の帯域が手に入ったときにネットワーク設計にどのような影響が生じるかを考え始めた。
高速ネットワークはアプリケーションが利用できる帯域を大きく向上させるものの、ネットワークに対する影響を考える上では帯域が向上したときに変わらないものが重要となる: つまり、光速である。スタートレックでスコットも言ったように、「物理法則は変えられませんよ」というわけだ。言い換えれば、「高速」ネットワークでレイテンシが帯域と同じ比率で改善されるわけではない: 1 Gbps の帯域を持つ大陸横断ネットワークの RTT は、同じ場所を接続する帯域 1 Mbps のネットワークの RTT と同じ 100 ms でもおかしくない。
レイテンシが固定された状況で帯域が大きく増加することの意味を理解するために、1 MB のファイルを 1 Mbps のネットワークおよび 1 Gbps のネットワークで転送するときに何が起こるかを考えよう。どちらも RTT は 100 ms とする。1 Mbps のネットワークを使う場合は 1 MB のファイル転送にレイテンシの 80 倍の時間が必要になり、レイテンシごとにファイルの 1.25% が送信される。これに対して、1 Gbps のネットワークにおける 1 MB のファイルは帯域遅延積 12.5 MB のほんの一部でしかない。
二つのネットワークの違いを図 19 に示す。1 MB のファイルは 1 Mbps リンクを通るときデータストリームのように見えるのに対して、1 Gbps リンクを通るときはパケットのように見える。1 Gbps リンクにとっての 1 MB は 1 Mbps リンクにとってわずか 1 KB に過ぎないことを考えれば、この点がより理解できるだろう。
この状況を「高速ネットワークでは RTT でやり取りできるデータが増えるので、相対的に単一の RTT が大きくなる」と考えることもできる。例えば、あるファイルの転送にかかる時間が 101 RTT になろうと 100 RTT になろうと大きな影響はない (相対的な違いは 1%)。しかし、1 RTT と 2 RTT の違いは非常に大きい ── 100% の増加である。言い換えれば、スループットではなくレイテンシがネットワーク設計を考える上で中心的な問題となる。
スループットとレイテンシの関係を理解するには、基礎的な関係に立ち戻るのが一番だろう。ネットワークで達成されるエンドツーエンドの実効スループットは次の単純な関係で与えられる:
ここで「転送時間」には本節の紹介した要素の他にも転送のリクエストやセットアップにかかる時間が含まれる。一般に、転送時間は次のように表せる:
この数式はネットワークを通じて送られるリクエストメッセージおよび返ってくるデータを考慮するときに利用される。例えば帯域が 1 Gbps で RTT が 100 ms のネットワークを通して 1 MB のファイルを取得するとき、全体の転送時間は 1 MB の転送にかかる時間 1 / 1 Gbps × 1 MB = 8 ms と RTT 100 ms の和 108 ms と求まる。よって実効スループットは
となって 1 Gbps とは大きく異なる値になる。明らかに、転送するデータの量が増えれば実効スループットも向上し、無限大に近づけると実効スループットはネットワークの帯域に限りなく近づいていく。一方で、ラウンドトリップが二度以上行われる ── 例えば、欠損したパケットを再送する ── と、任意の有限データの転送で実効スループットに影響が出る。この影響は小さなデータを転送しているときほど目立ちやすくなる。
1.5.4 アプリケーションの要件
本節の議論はネットワークを中心とした視点でパフォーマンスを考えてきた。つまり、特定のリンクあるいはチャンネルで何がサポートされるのかを話題にしてきた。言及はしなかったものの、この議論ではアプリケーションの要求が単純なことが仮定されている ── アプリケーションはネットワークが提供できるだけの帯域を全て求めている。これは前述した 25 MB の画像を取得しようとする電子図書館プログラムではもちろん正しい: 利用可能な帯域が大きければそれだけ、画像を早くユーザーに届けられる。
しかし、必要とする帯域に上限があるアプリケーションも存在する。分かりやすい例として映像アプリケーションがある。通常のテレビ画面の 4 分の 1 のサイズで映像をストリーミングしたいとしよう。つまり映像の解像度は 352×240 である。各ピクセルが 24 ビットの情報 (24 ビットカラー) で表されるとすれば、各フレームは (352 × 240 × 24) / 8 = 247.5 KB となる。もしアプリケーションが秒間 30 フレームをサポートしたいとすれば、要求すべきスループットは 75 Mbps となる。一定時間内にこれ以上のデータを転送することはないので、このアプリケーションに 75 Mbps 以上の帯域は必要ない。
しかし残念ながら、実際の状況はこの例ほど単純ではない。映像の隣り合うフレーム間の違いは小さい場合が多いので、隣り合うフレーム間の違いだけを転送すれば映像を圧縮できる。さらに、画像の細かい部分全てが人間の眼によってすぐに捉えられるわけではないので、各フレームも圧縮できる。映像内の動きの量や画像の詳細さ、あるいは利用される圧縮アルゴリズムといった要因により、圧縮された映像の大きさは時間と共に変化する。そのため、そういったアプリケーションは平均的な帯域要件を示すことはできても、瞬間的に利用される帯域はそれより大きくもなれば小さくもなる。
ここで重要な問題が、その平均帯域要件を計算するときに使う時間である。例えば上述の例で、圧縮のおかげで必要な帯域が平均 2 Mbps になったとしよう。もし最初の 1 秒間で 1 Mb を送信し、次の 1 秒間で 3 Mb を送信したら、この 2 秒間の平均送信レートは 2 Mbps となる。しかし転送に利用されるチャンネルが任意の 1 秒間に 2 Mb より多いデータの転送をサポートできければ、そのチャンネルはこの送信に対応できない。明らかに、平均的に必要とされる帯域を知るだけでは十分でない状況が存在する。
しかし一般に、今考えているようなアプリケーションで発生するバースト (瞬間的な送信量の増大) の大きさには上限が存在する。バーストはピークレートが維持される時間、あるいはピークレートで送信されるバイト数などとして記述される。もしピークレートが利用可能なチャンネルの容量より大きいなら、入りきらないデータはどこかにバッファして後から送る必要がある。バーストの大きさを知っておけば、ネットワーク設計者はそのバーストを保持するだけの容量を持ったバッファを確保しておくことができる。
アプリケーションの帯域要件が「もらえる分を全部もらう」より複雑な場合があるのと同じように、アプリケーションの遅延要件も「なるべく小さく」より複雑になる場合がある。遅延を考える上では、ネットワークの片道遅延が 100 ms なのか 500 ms なのかが問題になるよりも、パケット同士の遅延の変化が問題になることの方が多い。この遅延の変化をジッター (jitter) と呼ぶ。
送信側が 33 ms ごとにパケットを一つ送信する状況を考えよう。例えば映像アプリケーションが 1 秒間に 30 フレームを転送するような状況である。もしパケットが正確に 33 ms ごとに受信側へ届くなら、そのネットワークで各パケットの遅延は全く同じだと判断できる。しかし、もしパケットが受信側に届く間隔 ── パケット間ギャップ (inter-packet gap) と呼ばれる ── が変化するなら、「ネットワークはパケットストリームにジッターを加えている」と言う。そういった変動は単一の物理リンクでは通常起きず、マルチホップのパケット交換ネットワークにおけるキュー待ち遅延がパケットごとに異なるために発生する。このキュー待ち遅延は本節の前半で定義したレイテンシの一要素であり、時間と共に変化する。
ジッターの何が問題かを理解するために、転送されているパケットに映像のフレームが含まれていて、受信側は 33 ms ごとに画面に表示する新しいフレームが必要になる状況を考えよう。フレームが 33 ms より早く到着した場合は、受信側はそれを表示するまで待つことができる。しかし不幸にもフレームが 33 ms より遅く到着した場合は、期待される時刻に画面へ表示すべきフレームが受信側に存在しないので、映像が滑らかでなくってクオリティが低下する。なお、この問題を解決するためにジッターを完全に消す必要はなく、ジッターが最大でどの程度かを知れば十分である点に注意してほしい。受信側がレイテンシの上限さえ知っていれば、映像の再生 (最初のフレームの表示) をそれだけ (あるいはそれ以上) 遅らせることで将来フレームが必要になったときにフレームが必ず存在することを保証できる。つまり受信側がバッファにフレームを保存することでフレームの表示を遅延させれば、事実上ジッターを平滑化できる。