レイテンシとスループット

概要

レイテンシ（latency）は「1つのリクエストを送ってから応答が返るまでの時間」、スループット（throughput）は「単位時間あたりに処理できる量」です。前者はミリ秒（ms）で、後者はリクエスト毎秒（rps）やビット毎秒（bps）で測ります。どちらも「性能」「速さ」と呼ばれるため混同されがちですが、まったく別の軸です。

道路にたとえるなら、レイテンシは「1台の車が目的地に着くまでの所要時間」、スループットは「1時間に通過できる車の台数」です。車線を10倍に増やせば通過台数（スループット）は増えますが、1台あたりの所要時間（レイテンシ）は縮みません。逆に制限速度を上げれば所要時間は縮みますが、車線が1本のままなら渋滞時の処理台数は変わりません。ネットワーク・データベース・APIなど、あらゆるシステムの性能を語るとき、まず「どちらの話をしているのか」を区別することが出発点になります。

なぜ生まれたか

この2軸の区別が意識されるようになったのは、「回線を太くしたのに速くならない」という経験が繰り返されたからです。通信回線の宣伝は昔から「100Mbps」「1Gbps」といった帯域幅（スループットの上限）を掲げてきましたが、Webページの表示のような小さなやり取りの体感速度を決めるのは、多くの場合、往復にかかる時間（レイテンシ）のほうです。東京とアメリカ西海岸の間は光の速さでも片道約50msかかり、これはどれだけ帯域を増やしても縮みません。「Bandwidth is not speed（帯域は速さではない）」という警句や、「後から帯域は買えるが、レイテンシは物理法則で決まる」という格言は、この混同への戒めとして生まれました。

サーバ側でも同じ区別が必要でした。「秒間1万リクエストを捌けるサーバ」が「1リクエストを速く返すサーバ」とは限らず、逆にレイテンシを犠牲にしてまとめ処理（バッチング）をすればスループットは稼げます。性能改善の議論がかみ合わない原因の多くはこの2軸の混同にあり、だからこそ性能を語る基礎語彙として両者をセットで押さえる必要があるのです。

詳細

2軸は独立に動く

まず押さえたいのは、レイテンシとスループットが独立に改善も悪化もすることです。CDN でコンテンツを利用者の近くに置けばレイテンシが縮み、キャッシュでヒットした応答は桁違いに速く返ります — これらは主にレイテンシ側の改善です。一方、サーバの台数を増やして負荷を分散したり、回線の帯域を増やしたりするのは主にスループット側の改善で、1リクエストの応答時間はほとんど変わりません。ただし完全に無関係でもなく、システムが処理能力の限界に近づくと、リクエストが待ち行列に積まれてレイテンシが急激に悪化します。「スループットの限界がレイテンシの悪化として観測される」のは負荷試験で必ず出会う現象です。

平均に騙されない — パーセンタイルとテールレイテンシ

レイテンシを測るとき、平均値はほとんど役に立ちません。レイテンシの分布は「大半は速いが、ごく一部が極端に遅い」という裾の長い形になりがちで、平均はその実態を覆い隠すからです。実務ではパーセンタイルで語ります。p50（中央値）は「半分のリクエストはこれより速い」、p99 は「100件に1件はこれより遅い」を意味し、SLO では「p99 レイテンシ 300ms 以下」のような形で目標を定めるのが定番です。この裾の部分はテールレイテンシと呼ばれ、規模が大きいほど深刻になります。1ページの表示が100個の内部呼び出しに依存していると、個々の p99 は稀でも「どれか1つが遅い」確率は6割を超え、ユーザー体験は最も遅い1つに引きずられるのです。ガベージコレクションの停止やコネクションプールの枯渇など、テールを悪化させる犯人探しは性能チューニングの主戦場で、分散トレーシングやメトリクスのヒストグラムがその道具になります。

帯域遅延積 — 2軸の掛け算が効く場面

ネットワークでは2軸の積そのものが重要な意味を持ちます。帯域幅とレイテンシ（往復時間、RTT）を掛けた値は帯域遅延積（BDP: Bandwidth-Delay Product）と呼ばれ、「送信したデータが相手に届いて確認応答が返るまでの間に、回線上に滞留しているデータ量」を表します。たとえば 1Gbps・RTT 100ms の回線なら BDP は約12.5MBで、TCP は確認応答を待ちながら送るため、送信側がこの量を送り続けられるだけのウィンドウ（未確認のまま送ってよいデータ量）を持たないと、太い回線がガラガラのまま終わります。「遠距離の太い回線ほど speed test の数字が出ない」現象の正体はこれです。また HTTP が1往復ごとに接続を張り直していた時代の非効率も本質は同じで、接続の使い回し（keep-alive やコネクションプール）、多重化を進めた HTTP/2・HTTP/3 は、いずれも「往復回数を減らしてレイテンシの支配を逃れる」工夫と読めます。

トレードオフとして設計する

2軸はしばしば意図的なトレードオフの対象になります。書き込みを1件ずつ確定させれば1件のレイテンシは最小ですが、まとめて処理（バッチング）すれば1件あたりのコストが下がりスループットが伸びます。メッセージキューやストリーム処理は、応答の即時性を少し譲って処理量と安定性を取る設計の典型です。逆にオンライン取引や対話型UIでは、多少の効率を捨ててでもレイテンシを優先します。性能要件を書くときは「速くする」ではなく、「p99 レイテンシを何msに」「秒間何リクエストを」と、どちらの軸をどこまで求めるのかを分けて書くこと — それがこの語彙を学ぶ実務上の結論です。