LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・検証を受託

システムの性能要件を打ち合わせていると、「レイテンシは問題ないが、スループットが足りない」「応答は速いのに全体の処理量が伸びない」といった言葉が出てくることがあります。レイテンシとスループットは、どちらもシステムの性能を測る代表的な指標ですが、指しているものは大きく異なるものです。この違いを整理しないまま要件定義を進めてしまうと、体感の遅さは解消されたのに繁忙期に処理が詰まる、あるいはその逆といったすれ違いが起きやすくなります。

本記事では、レイテンシ（1件の処理にかかる時間・応答の速さ）とスループット（単位時間あたりに処理できる量）という二つの指標の意味と関係、トレードオフの考え方を整理します。台数を増やすスケールアウトや費用最適化の話には深入りせず、発注担当者・PM・設計者が押さえておきたい「指標の読み方と使い分け」に焦点を当てて解説します。

レイテンシとは（応答の速さ）

レイテンシ（Latency）とは、1件の処理を依頼してから、その結果が返ってくるまでにかかる時間のことです。利用者がボタンを押してから画面が切り替わるまでの体感速度に直結する指標で、値が小さいほど応答が速いシステムということになります。

身近な例：Webページの表示時間

Webサイトのリンクをクリックしてからページが表示されるまでの時間を思い浮かべると分かりやすいでしょう。この間には、リクエストがサーバーへ届くまでの通信時間、サーバー側での処理時間、データベースへの問い合わせ時間、結果を利用者の端末へ返す通信時間などが積み重なっています。これらすべてを合計したものが、利用者の体感するレイテンシです。

レイテンシを構成する要素

レイテンシは単一の処理時間ではなく、複数の要素の合計として捉えると設計しやすくなります。

• ネットワークの伝送遅延――リクエストとレスポンスが物理的な回線を伝わる時間
• 待ち行列による遅延――処理待ちの状態で発生する時間
• アプリケーションの処理時間――ロジックの実行やデータベースへの問い合わせにかかる時間
• 直列に連なる依存処理――他のサービスへの呼び出しが連鎖することで積み上がる時間

どこか一箇所の遅延が大きい場合、そこがレイテンシ短縮の着眼点になりやすいといえます。

レイテンシが体感に与える影響

操作画面のレイテンシは、利用者の体感に直結しやすい性質を持ちます。ボタンを押してから反応が返るまでの時間がわずかに伸びただけでも、利用者は「重い」「使いにくい」と感じることがあり、離脱につながる場合もあるでしょう。社内システムであっても、日々何度も操作する画面の応答が遅いと、業務全体の生産性に影響が及びます。レイテンシは単なる技術指標にとどまらず、利用体験そのものを左右する要素と捉えておく必要があります。

スループットとは（処理量）

スループット（Throughput）とは、単位時間あたりにシステムが処理できる件数や量を表す指標です。1秒あたりのリクエスト数（RPS）や1秒あたりのトランザクション数（TPS）といった形で表されることが多く、システム全体としてどれだけの仕事量をこなせるかを示すものになります。

身近な例：注文処理の件数

ECサイトのセール期間中に、1分間あたり何件の注文を処理しきれるかを考えると分かりやすいでしょう。1件あたりの応答が多少ゆっくりでも、多数の注文を並行してさばければ全体の処理量は保たれます。逆に1件あたりの応答が速くても、同時に扱える件数に限りがあれば、混雑時には全体としての処理量が頭打ちになることがあります。

スループットを左右する要素

スループットは、システムが持つ処理能力の余力によって決まる部分が大きい指標です。

• 並列度――同時に処理を進められるプロセスやスレッドの数
• 計算資源の量――CPUやメモリ、ディスクI/Oといったリソースの余裕
• 処理の効率――アルゴリズムやクエリの組み方による無駄の少なさ
• 外部との接続数の上限――データベースの接続プール数など、上限が定められている要素

スループットの求め方

スループットは、一定の期間に処理できた件数を、その期間の長さで割ることで求められます。例えば10分間で1200件の注文を処理できた場合、1分あたりのスループットは120件という計算になります。この値を平常時とピーク時とで比較しておくと、繁忙期にどの程度の余力が残っているかを見積もる手がかりになるでしょう。

両者の違い：対比表とたとえ図

レイテンシとスループットは、どちらも「速さ」に関わる言葉として語られがちですが、着目している対象が異なる指標です。主な観点を次の表に整理します。

対比表からも分かるとおり、レイテンシは「1件あたりの速さ」、スループットは「全体としての処理量」に着目した指標です。次の図は、高速道路を例にした両者のイメージです。

両者の関係とトレードオフ

レイテンシとスループットは、それぞれ独立した指標というより、負荷の状況によって影響し合う関係にあります。

並列化でスループットは上がるが、個々のレイテンシが縮むとは限らない

処理を並列に走らせるワーカーやサーバーの数を増やすと、同時にさばける件数が増えるため、全体のスループットは向上しやすくなります。ただし、これは1件あたりの処理時間そのものが短くなることを意味するわけではありません。共有するデータベースや外部サービスへのアクセスが増えれば資源の奪い合いが生じやすくなり、かえって個々のレイテンシが伸びることもあるものです。並列化はスループットを底上げする有力な手段ですが、レイテンシの改善とは狙いが異なる打ち手だと捉えておくとよいでしょう。

待ち行列（キュー）の視点で見る負荷の影響

システムへのリクエスト量が処理能力の上限に近づくにつれ、処理を待つ列（キュー）が伸びやすくなります。余裕がある状態では待ち時間はわずかですが、処理能力の上限に近い水準まで負荷が高まると、待ち時間が急に大きくなる傾向が知られています。これは待ち行列理論と呼ばれる考え方で説明される現象であり、稼働率が高い状態を維持し続けると、レイテンシが不安定になりやすい点が特徴です。性能要件を検討する際は、平常時の値だけでなく、負荷が高まった局面での振る舞いも合わせて確認しておきたいところです。

稼働率と余力の考え方

システムの処理能力に対して、実際に流れてくる負荷の割合を稼働率と呼びます。稼働率が低いうちはレイテンシへの影響もわずかですが、稼働率が上限に近づくほど、待ち時間の伸び方が緩やかから急激な変化へと転じやすくなる点が知られています。ピーク時の負荷を見込んで、あらかじめ稼働率に余裕を持たせておく設計が、レイテンシの安定につながりやすいといえるでしょう。

性能要件・SLAでの使い分け

どちらの指標を重視すべきかは、システムの用途によって変わります。

応答性が重視される用途

利用者の操作に対してその場で結果を返す必要がある画面操作や、リアルタイム性が求められる連携処理では、レイテンシを主要な指標としてSLAを定めることが一般的です。「95パーセンタイルで何ミリ秒以内に応答する」といった形で、平均値だけでなく遅い側の応答時間まで含めて基準を置く考え方がよく採られます。

大量処理が重視される用途

夜間バッチや大量データの取り込み、集計処理のように、利用者がその場で結果を待たない処理では、スループットを主要な指標として扱うことが多くなります。「1時間あたり何件処理できるか」「決められた時間内に処理を終えられるか」といった観点で性能要件を定める考え方です。

両方の指標が求められる場合

会員数の多いサービスの申込処理や決済処理のように、応答の速さと大量件数のさばきの両方が求められる場面も少なくありません。こうした場合は、レイテンシとスループットのどちらを優先するかを一律に決めるのではなく、機能ごと・処理経路ごとに求める水準を分けて整理する考え方が有効です。

計測とボトルネックの考え方

性能指標は、定めるだけでなく計測して初めて意味を持ちます。

何を計測するか

レイテンシを計測する際は、平均値だけでなく、p95やp99といったパーセンタイル値を合わせて見ることが望ましいでしょう。平均値が良好でも、一部の利用者が極端に遅い応答を経験している場合があり、こうした裾野（テール）の遅延は平均値からは見えにくいためです。スループットは、一定期間あたりの処理件数を継続的に記録し、負荷の変動とあわせて傾向を追うことが基本になります。

ボトルネックの切り分け方

レイテンシが悪化している場合は、どの処理段階に時間がかかっているのかを、監視ツールやAPM（アプリケーション性能監視）などを用いて切り分けることが出発点になります。ネットワーク、アプリケーションの処理、データベースへの問い合わせ、外部サービスの呼び出しのうち、どこに遅延が集中しているかを把握しないまま手を打つと、期待した改善につながらないことがあります。スループットが伸び悩む場合も同様に、特定のリソース（データベースの接続数、特定のロック、外部APIの呼び出し回数の上限など）が全体の上限を決めている場合が多く、その箇所を特定することが改善の近道になりやすいでしょう。

設計・発注時の確認点

システム開発を発注する際は、次のような観点を確認しておくと、性能要件のすれ違いを防ぎやすくなります。

• 対象の処理が、応答性（レイテンシ）と処理量（スループット）のどちらを重視するものか
• SLAとして定める値が、平均値なのかパーセンタイル値なのか
• 想定するピーク時の負荷（同時アクセス数・処理件数）はどの程度か
• 負荷が高まった局面でのレイテンシの振る舞いを、事前に確認・検証する計画があるか
• 性能を継続的に計測・監視する仕組みが、リリース後に用意されているか

要件定義段階で分けて整理する

「性能要件」とひとまとめに書いてしまうと、応答性の要件なのか処理量の要件なのかが曖昧になりがちです。要件定義の段階で、機能ごとにレイテンシとスループットのどちらを主眼に置くのかを分けて整理しておくことが、後工程での認識のずれを減らすことにつながります。

まとめ：二つの指標を分けて捉える

本記事では、レイテンシ（1件の処理にかかる時間）とスループット（単位時間あたりに処理できる量）という二つの性能指標の違いと関係を整理しました。両者は並列化や負荷の状況によって影響し合うトレードオフの関係になることがあり、一方を高めれば他方も自動的に良くなるとは限りません。

システムの用途に応じてどちらの指標を主眼に置くのかを見極め、平均値だけでなく裾野の遅延や負荷変動時の傾向も含めて計測していくことが、無理のない性能設計につながるでしょう。要件定義や発注の段階から、二つの指標を分けて確認しておきたいポイントです。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IPA（情報処理推進機構）基本情報技術者試験シラバスにおける性能指標・待ち行列に関する解説（https://www.ipa.go.jp/shiken/syllabus/index.html）

Tweet