コンテンツにスキップ

【比較】レイテンシとスループットの違い

概要

「レイテンシ（latency）」は1つの操作が完了するまでにかかる時間で、ミリ秒などの時間単位で測ります。「スループット（throughput）」は単位時間あたりに処理できる仕事量で、リクエスト/秒やバイト/秒のような「量÷時間」で測ります。両者は性能を語る軸が異なり、片方を改善しても他方が改善するとは限りません。

混同が起きるのは「速い＝両方良い」と直感的に結びつけてしまうためです。しかしレイテンシとスループットは単純な逆数関係ではありません。リクエストをまとめて処理（バッチング）すれば1秒あたりの処理件数（スループット）は上がりますが、各リクエストはバッチが揃うまで待たされるためレイテンシは悪化します。本記事ではネットワーク／システム設計の文脈で、両者の関係をリトルの法則やバンド幅との区別を含めて整理します。

例えるなら：高速道路の「所要時間」と「通過台数」

レイテンシは「ある1台の車が入口から出口まで走り切る所要時間」、スループットは「料金所を1時間に何台通過できるか」に相当します。車線を増やせば1時間の通過台数（スループット）は増えますが、1台あたりの所要時間（レイテンシ）はほとんど変わりません。逆に道のりを短くすれば所要時間は減ります。さらに「料金所でまとめて10台分を一括処理する」運用にすると処理効率（スループット）は上がる一方、最初に来た車は残り9台が揃うまで待つので所要時間（レイテンシ）は伸びます。比喩は関係性の直感を与えますが、実システムでは輻輳・キュー・プロトコルの影響が加わるため、定量はリトルの法則などで考える必要があります。

詳細比較

項目 レイテンシ (Latency) スループット (Throughput)
測るもの 1操作の開始から完了までの所要時間 単位時間あたりに完了する仕事量
単位 時間（ms, μs, s）。ネットワークでは RTT など 量/時間（req/s, ops/s, bytes/s, MB/s）
改善手段の例 距離短縮（伝搬遅延）、処理段数削減、キャッシュ、近接配置（CDN/エッジ） 並列化、バッチング、パイプライン化、バンド幅増強、ボトルネック解消
相互関係 単純な逆数ではない。高レイテンシは間接的にスループットを下げ得る（例: TCP のウィンドウ制限）が、独立に最適化できる場面も多い バッチングやパイプライン化でスループットを上げると個々のレイテンシは悪化し得る（トレードオフ）
リトルの法則 L = λ × W の W（系内滞在時間≒レイテンシ） L = λ × W の λ（到着＝処理レート≒スループット）。L は系内の平均同時数
ネットワークでの関連語 伝搬遅延（媒体を伝わる時間）、RTT（往復時間）が主因の一つ バンド幅（理論最大容量）とは別物。スループットは実効値で、レイテンシ等の影響を受ける
ユーザー体感への効き方 操作の「キビキビ感」「待たされ感」に直結（クリック→応答） 大量データ転送やバッチ処理の「総処理時間」「捌ける量」に直結

ネットワークではバンド幅・スループット・レイテンシはいずれも別の量です。Cloudflare の定義では、バンド幅は「任意時点でネットワークを通過できるデータの最大量」、スループットは「一定期間に実際に通過したデータの平均量」、レイテンシは「データがネットワークのある点から別の点へ届くまでの時間」であり、スループットはレイテンシ等の影響を受けるためバンド幅と一致しません。AWS も両者を別指標とし、高レイテンシだとスループットが下がり得る一方、両者を一緒に最適化することも可能だと説明しています。

よくある誤解

  • 「レイテンシとスループットは逆数（片方を上げれば他方は必ず下がる、または逆）」は誤り。 両者は別次元の指標であり、固定的な反比例関係ではありません。たとえば CDN でユーザーに近いエッジから配信すればレイテンシもスループットも改善し得ます（両方良くなる）。一方でバッチングはスループットを上げつつレイテンシを悪化させます（トレードオフが生じる）。「常にトレードオフ」でも「常に独立」でもなく、どの最適化を選ぶかで関係が変わる、が正確な理解です。

  • 「バンド幅が大きければレイテンシも小さい（回線を太くすれば速くなる）」は誤り。 バンド幅（容量）とレイテンシ（遅延）は別物です。光ファイバの伝搬遅延は距離で決まり、回線を太くしても1パケットが地球の裏側まで届く時間は短くなりません。大容量ファイルの転送時間はバンド幅で改善しますが、小さなリクエストの応答の速さ（体感）は主にレイテンシ（RTT）で決まります。Cloudflare もスループットはバンド幅と等価ではないと明言しています。

  • 「スループットを上げれば自動的にレイテンシも下がる」は誤り。 スループット最適化の代表手段であるバッチングやキューイングは、仕事をまとめて待たせることで効率を上げる手法なので、個々の操作のレイテンシは悪化しがちです。NVIDIA GPU での推論例でも、バッチサイズを上げるとスループットは大きく伸びる一方レイテンシも数倍に増えることが報告されています。

  • 「リトルの法則は到着分布が分かっていないと使えない（M/M/1 などの仮定が必要）」は誤り。 リトルの法則 L = λW は、到着過程の分布・サービス時間分布・処理順序に依存しない非常に一般的な関係です（Wikipedia も「到着過程分布・サービス分布・サービス順序の影響を受けない」と明記）。だからこそ「平均同時処理数 = 到着レート × 平均滞在時間」という形で、スループット（λ）とレイテンシ（W）と並列度（L）の関係を素早く見積もるのに使えます。

実務での選び分け

  • 対話的な操作（API 応答、ページ表示、ゲーム）が主目的 → レイテンシを最優先。p50 だけでなく p99 など末尾のレイテンシを見る。CDN/エッジ、キャッシュ、処理段数削減、接続再利用（keep-alive/HTTP2）。
  • 大量データの一括処理・バッチ ETL・ログ集約が主目的 → スループットを最優先。バッチング、並列化、パイプライン化、バンド幅増強。個々の遅延は許容できることが多い。
  • 両立が必要（オンラインかつ大量） → リトルの法則で必要な並列度を見積もる（必要同時数 ≒ 目標スループット × 許容レイテンシ）。レイテンシ予算を決めてからスループットを積む。
  • ボトルネックを疑うとき → 「遅い」が所要時間（レイテンシ）の問題か、捌けない（スループット）問題かをまず切り分ける。改善策がまったく異なる。
  • ネットワーク設計 → 遠距離・対話型なら経路短縮/エッジで RTT を削る。大容量転送ならバンド幅と並列ストリームでスループットを稼ぐ。

ひとことまとめ

レイテンシは「1操作にかかる時間」、スループットは「単位時間あたりの処理量」で、単純な逆数ではなく独立に良くできることもトレードオフになることもあります。何を最適化したいか（応答の速さか、捌ける量か）を先に決め、リトルの法則で並列度を見積もるのが実務の定石です。

出典・参考