性能設計と評価｜スループット・応答時間・利用率・待ち時間を計算する

サーバを二台にしたのに、応答がほとんど速くならない。CPU利用率は低いのに、利用者は遅いと感じる。こうした状況を判断するには、処理した件数、応答までの時間、待っている場所を分けて測る必要があります。平均値だけで結論を出さず、測定条件と処理経路を対応付けます。

この記事で理解すること

• スループット、応答時間、利用率、同時処理数の単位と意味を区別する。

• 単純な待ち行列モデルの前提を確認して、負荷増大の影響を計算する。

• 共通のボトルネックと直列部分を見つけ、増設・負荷分散・並列化の効果を判断する。

架空の受注APIを例にします。測定値や構成は教材用です。クライアント、アプリ、共有DBの順に処理され、どの区間に待ちがあるかを確認します。TLSやIP経路、SQLの詳しい仕組みは既存記事を参照し、この記事は性能指標と設計判断を主担当とします。

性能指標：件数と時間と割合を混ぜない

100秒で800件を完了したなら、測定区間のスループットは8件/秒です。一件の応答時間が0.5秒でも、複数要求が同時に進むなら、スループットは単純な1÷0.5とは限りません。逆数が能力を表すのは、単一の処理窓口で一件ずつ同じ時間で処理するような条件です。

CPU利用率、DB接続プール使用率、回線利用率は測る対象が違います。DBの応答を待つ間、アプリのCPUが低いこともあります。「利用率が低い」という文だけでは、どこに余裕があるかを判断できません。

応答時間の内訳：処理だけでなく待ちを測る

受付待ち0.10秒、アプリ処理0.05秒、DBの待ちと処理0.30秒、その他の通信等0.05秒なら、重なりのない区間の合計は0.50秒です。DBの区間が大きくても、それがDBのCPU計算なのかロック待ちなのか接続待ちなのかは、追加の観測が必要です。

測定区間を二重に数えないことも大切です。アプリの総時間にDB待ちが含まれるなら、アプリ総時間とDB総時間をそのまま足すと重複します。トレースや時刻記録で、区間の開始と終了、並行して進む処理を明らかにします。

利用率と待ち行列：能力に近づくと待ちが増える

到着率λを平均8件/秒、単一窓口の平均サービス時間Sを0.10秒とします。処理率μは1/S = 10件/秒で、利用率ρはλS = λ/μ = 0.8です。この計算は一件が対象窓口を一度利用するモデルです。複数回のDBアクセスや複数窓口なら条件を調整します。

M/M/1モデルは、ポアソン到着、独立した指数分布のサービス時間、単一窓口などを仮定する待ち行列モデルです。ここでは先着順、十分な待ち容量、定常状態でλ < μを前提にします。その場合、平均応答時間WはS/(1−ρ)、平均待ち時間WqはW−Sです。

λ = 8件/秒
S = 0.10秒/件、μ = 10件/秒
ρ = λS = 0.8
W = 0.10 / (1 - 0.8) = 0.50秒
Wq = W - S = 0.40秒

処理時間を変えなくても、能力に近づくと待ちが増えます。ρが1以上なら、このモデルで有限の定常平均を計算する前提が崩れます。負の時間が出た式をそのまま使わず、到着と処理の条件を見直します。

実システムでは到着の集中、固定的な処理時間、優先度、タイムアウト、複数窓口があり、この数式の値と一致するとは限りません。平均のモデルを実測の保証値にせず、モデルの前提と負荷試験の条件を記します。

Littleの法則：同じ境界の件数と時間を使う

安定した系の長期平均では、平均滞在数Lは実効的な到着率λと平均滞在時間Wの積、L = λWで関係付けられます。対象が待ち行列だけなら、待機数と待ち時間を使います。処理中も含む系なら、両方に処理中を含めます。

先ほどの系はL = 8 × 0.50 = 4件です。待機中だけならLq = 8 × 0.40 = 3.2件です。平均の件数は小数になり得ます。小数の要求が存在する意味ではなく、時刻を通じた平均です。長期平均の関係であり、瞬間の件数から必ず次の応答時間を予測できるわけではありません。

ボトルネックと負荷分散：共有する資源を探す

ボトルネックは全体の処理能力を制約する箇所です。アプリ一台が20件/秒を処理できても、全要求が通る共有DBの上限が10件/秒なら、アプリを二台にして40件/秒へ増やしても、全体を40件/秒にすることはできません。比較する能力は同じ要求種類と条件で測ります。

負荷分散は複数の処理先へ要求を振り分ける仕組みです。セッションの偏り、要求ごとの重さ、共有DB、接続数の制限があると、台数に比例して効率よく分散しません。DB側に余裕があるか、要求が独立しているか、偏りを観測できるかを確認します。

キャッシュでDBアクセスを減らす、問合せを見直す、競合する更新を整理するなど、制約する資源への負荷を減らす案もあります。ただし整合性や鮮度を満たす必要があります。速くするために古い値を無条件に返すと、業務の正しさを壊す場合があります。

並列化とAmdahlの法則：直列部分は残る

並列化できる割合をp、同時に使う処理単位数をnとすると、理想的な高速化の上限は1/((1−p)+p/n)で表せます。Amdahlの法則です。仕事量は同じで、並列化できる部分を均等に分割し、通信や同期の追加費用を無視した理想条件です。

処理の80%を4並列にできるなら、1/(0.2+0.8/4) = 2.5倍です。4倍ではありません。並列数を非常に増やしても、直列20%が残るため上限は5倍です。実際には準備・同期・データ移動の費用も増え、理想値に届かない場合があります。

測定と改善：平均だけで判断しない

負荷試験では要求の種類、入力データ量、同時数、到着のさせ方、キャッシュの状態、測定区間をそろえます。成功した要求だけを平均に入れ、タイムアウトを全て捨てると、遅い失敗が見えなくなります。成功率・エラー率も一緒に確認します。

95パーセンタイルは、観測した時間の約95%がその値以下となる位置の指標です。平均が同じでも、一部が極端に遅いサービスの利用者体験は違います。p95とp99、ピークの待機数、資源別の飽和を見て、改善前後を同じ条件で比較します。

容量・能力管理の記事は将来需要と増強計画を、TCPの記事は通信のRTTやウィンドウを主担当とします。ここではまず処理経路、指標、単純モデルの計算を理解し、改善案を制約する箇所と結び付けます。

演習1：件数と時間

条件：100秒で800件を完了。

問い：この区間のスループットは幾つか。

解答例：8件/秒。800件を100秒で割る。

根拠と誤答の確認：一件の応答時間の逆数とは条件が異なります。

演習2：利用率

条件：到着率8件/秒、単一窓口の平均サービス時間0.10秒。

問い：利用率を答える。

解答例：0.8、すなわち80%。到着率と平均サービス時間の積。

根拠と誤答の確認：件/秒と秒/件を掛けて無次元になることも確認します。

演習3：待ち時間

条件：上の条件でM/M/1の定常モデルを仮定する。

問い：平均応答時間と平均待ち時間を答える。

解答例：応答0.50秒、待ち0.40秒。0.10/(1−0.8)から処理時間0.10を引く。

根拠と誤答の確認：0.50秒を全て待ち時間としないようにします。

演習4：滞在数

条件：安定した系で実効到着率8件/秒、平均滞在時間0.50秒。

問い：平均滞在数を答える。

解答例：4件。L = λWから8 × 0.50。

根拠と誤答の確認：対象の境界をそろえ、処理中を含むかどうかを確認します。

演習5：増設の限界

条件：アプリ二台の合計能力40件/秒、全要求が使うDBは10件/秒。

問い：全体が40件/秒になるといえるか。

解答例：いえない。共通DBの10件/秒が全体能力を制約するため。

根拠と誤答の確認：アプリの能力だけを足して全体能力としません。

演習6：並列化

条件：仕事量を固定し、80%を4並列にする。追加費用は無視する。

問い：理想的な高速化の上限は幾つか。

解答例：2.5倍。1/(0.2+0.8/4)で求める。

根拠と誤答の確認：直列20%を分割した扱いにすると4倍と誤答します。

参照資料とこの記事の範囲

事例・図・演習は教材用に独自に作成しました。公式・教育機関の資料で仕組みを確認し、特定年度の問題本文を前提にせず学べる構成にしています。

MIT M/M/1とLittleの法則

Google SRE 監視と性能指標

Google SRE 過負荷への対応

LLNL 並列計算とAmdahlの法則

IPA APシラバス

関連テーマを続けて学ぶ

SQLの結合と集計

IP・サブネット・経路・NAT

記述式の設問と本文根拠の読み方