レイテンシとスループット
Latency and Throughput ・ れいてんしとするーぷっと
1件が返るまでの時間と、単位時間に捌ける量。別の軸だが、限界付近で待ち行列を介して結びつく。
✦ 30秒で試す — 航海サーバを倍に増やしても、空いている時の応答は速くならない1件が返ってくるまでの平均時間は？予想してみる概要
レイテンシ（latency）は「1つのリクエストを送ってから応答が返るまでの時間」、スループット（throughput）は「単位時間あたりに処理できる量」です。前者はミリ秒（ms）で、後者は毎秒のリクエスト数（rps）や毎秒のビット数（bps）で測ります。どちらも「性能」「速さ」と呼ばれるため混同されがちですが、別々の軸です。
道路にたとえるなら、レイテンシは「1台の車が目的地に着くまでの所要時間」、スループットは「1時間に通過できる車の台数」です。車線を10倍に増やせば通過台数は増えますが、空いている道を走る1台の所要時間は縮みません。逆に制限速度を上げれば所要時間は縮みますが、車線が1本のままなら通過できる台数の上限はあまり変わりません。
API の応答が遅い、サーバが捌ききれない、ページの表示がもたつく——性能の相談はたいていこのどちらかの話です。まず「どちらの軸の話をしているのか」を分け、そのうえで両者が結びつく場所（限界付近の待ち行列）を知っておくことが、性能を語る出発点になります。
なぜ生まれたか
この2軸の区別が強く意識されるようになったのは、「回線を太くしたのに速くならない」という経験が繰り返されたからです。通信回線は昔から「100Mbps」「1Gbps」といった帯域幅（スループットの上限）を売りにしてきましたが、Webページのような小さなやり取りの体感速度を決めるのは、多くの場合、往復にかかる時間のほうです。たとえば東京とアメリカ西海岸はおよそ8,000〜9,000km 離れていて、真空中の光でも片道約28ms、光ファイバの中では光が3分の2ほどの速さになるので片道40ms強かかります。実際の経路は直線ではなく途中の機器も通るため、往復時間（RTT: Round Trip Time）は100ms 前後になります。これは帯域をいくら増やしても縮みません。「帯域はお金で買えるが、レイテンシは物理法則で決まる」という格言は、この混同への戒めです。
サーバの側でも同じ区別が必要でした。「毎秒1万リクエストを捌けるサーバ」が「1リクエストを速く返すサーバ」とは限りません。まとめて処理（バッチング）すればスループットは稼げますが、1件あたりは待たされます。さらに厄介なのは、スループットに余裕がなくなると、ある地点から急にレイテンシが悪化することでした。この現象は電話交換機の設計から生まれた待ち行列理論（1900年代初頭の A.K. アーラン以来の研究）で説明され、1961年にはリトルの法則として「系の中にいる数＝スループット×滞在時間」という関係が証明されています。2軸を分けて測り、その結びつき方を理解しておくことが、性能の議論をかみ合わせるための基礎になりました。
詳細
2軸は独立に動く
まず、レイテンシとスループットは別々に改善も悪化もします。CDN でコンテンツを利用者の近くに置けば往復の距離が縮み、キャッシュにヒットした応答は桁違いに速く返ります。これらは主にレイテンシ側の改善です。一方、ロードバランサの後ろにサーバを並べる水平スケーリングや、回線の帯域の増強は主にスループット側の改善で、空いているときの1リクエストの応答時間はほとんど変わりません。
限界に近づくと、待ち行列でレイテンシが跳ね上がる
2軸が独立なのは「空いているとき」だけです。1件の処理に平均100ms かかるサーバは、毎秒10件までなら捌けます。到着が毎秒5件（使用率50%）のうちは、たまに前の処理を待つ程度で済みます。ところが毎秒9件（90%）になると、到着はランダムにばらつくので、ちょっとした偶然の集中で待ち行列が伸び、その行列が解消しきらないうちに次の集中が来ます。単純なモデル（M/M/1 と呼ばれる、到着も処理時間もランダムな1窓口の待ち行列）では、平均の滞在時間は「処理時間 ÷（1 − 使用率）」になります。使用率50%で2倍、90%で10倍、99%で100倍です。スループットはまだ上限に届いていないのに、レイテンシはすでに何倍にも悪化しているわけです。
このため、実務ではサーバの使用率を100%近くまで使い切る設計はしません。ピーク時でも使用率に余裕を残しておくのは、スループットの上限ではなく、その手前で起きるレイテンシの急増を避けるためです。上限を超えて押し寄せた分は行列に積まれ続けるので、タイムアウトやレート制限、バックプレッシャーで入口を絞ることも必要になります。
下の部品で確かめてください。グラフの金の線（到着率）をつかんで右へ動かし、処理能力に近づけていくと、待ち行列とレイテンシがどう変わるかが見えます。サーバを2台にすると曲線がどちらへずれるかも試してみてください。
グラフの金の線（到着率）をつかんで右へ動かし、処理能力（1台で毎秒10件）に近づけてみてください。離すと、その負荷での測定点が打たれていきます。
リトルの法則 — 3つの量をつなぐ式
系の中にいる件数を L、スループットを λ、1件あたりの滞在時間（レイテンシ）を W とすると、定常状態では L = λ × W が成り立ちます（リトルの法則）。到着や処理の分布によらず成り立つので、見積もりに便利です。たとえばデータベースへの問い合わせに平均20ms かかり、毎秒500件を流したいなら、同時に使われている接続は平均で 500 × 0.02 = 10本です。コネクションプールの本数を決めるときの目安になります。逆に言えば、プールの本数（同時に処理できる数）が固定されているとき、1件のレイテンシが2倍になればスループットの上限は半分になります。ここでも2軸は、限界の近くで結びついています。
平均に騙されない — パーセンタイルとテールレイテンシ
レイテンシを測るとき、平均値はあまり役に立ちません。レイテンシの分布は「大半は速いが、ごく一部が極端に遅い」という裾の長い形になりやすく、平均はその実態を隠すからです。実務ではパーセンタイルで語ります。p50（中央値）は「半分のリクエストはこれより速い」、p99 は「100件に1件はこれより遅い」という意味で、SLO では「p99 レイテンシ 300ms 以下」のように目標を定めるのが定番です。この裾の部分はテールレイテンシと呼ばれ、規模が大きいほど効いてきます。1ページの表示が100個の内部呼び出しに依存していると、1個あたりでは1%でしか起きない遅れでも、「どれか1つが遅い」確率は 1 − 0.99¹⁰⁰ ≒ 63% になり、ユーザー体験は最も遅い1つに引きずられます。ガベージコレクションによる停止やコネクションプールの枯渇など、テールを悪化させる原因探しが性能チューニングの主戦場で、分散トレーシングやメトリクスのヒストグラムがその道具になります。
帯域遅延積 — 2軸の掛け算が効く場面
ネットワークでは、2軸の積そのものが意味を持ちます。帯域幅と往復時間を掛けた値は帯域遅延積（BDP: Bandwidth-Delay Product）と呼ばれ、「送ったデータが相手に届いて確認応答が返ってくるまでの間に、回線上を飛んでいるデータ量」を表します。1Gbps・RTT 100ms の回線なら約12.5MB です。TCP は確認応答を待ちながら送るので、確認前に送ってよい量（ウィンドウ）がこの値より小さいと、太い回線が空いたまま終わります。「遠距離の太い回線ほど速度テストの数字が出ない」のはこのためです。
往復の回数を減らす工夫も、同じくレイテンシの支配から逃れるための工夫です。HTTP の keep-alive やコネクションプールは接続の確立の往復を省き、HTTP/2 は1本の接続で複数のリクエストを並行させ、HTTP/3とQUIC は接続と暗号化の準備を1往復にまとめました。
トレードオフとして設計する
2軸は、意図的なトレードオフの対象にもなります。書き込みを1件ずつ確定させれば1件のレイテンシは最小ですが、まとめて処理すれば1件あたりのコストが下がりスループットが伸びます。メッセージキューやストリーム処理は、応答の即時性を少し譲って、処理量と安定性を取る設計の典型です。逆にオンライン決済や対話型の画面では、多少の効率を捨ててでもレイテンシを優先します。
性能要件を書くときは「速くする」ではなく、「毎秒何件を、p99 何ms 以内で」と、2つの軸を分けたうえで組にして書きます。スループットの目標だけでは限界付近のレイテンシの急増を見落とし、レイテンシの目標だけではどれだけの負荷の下での話かが決まらないからです。
試問
利用者からサーバへ、リクエストがばらばらのタイミングで届きます。サーバ1台は1件を平均100ミリ秒で処理し、毎秒10件まで捌けます。グラフの金の線（到着率）をつかんで左右に動かすと届く量が変わり、しばらく待つとその到着率での測定点が打たれます（p99 は「100件に1件はこれより遅い」という応答時間）。下のボタンでサーバを2台にできます。
グラフの金の線（到着率）をつかんで右へ動かし、処理能力（1台で毎秒10件）に近づけてみてください。離すと、その負荷での測定点が打たれていきます。