変更要約: 初版
4.1性能設計とキャパシティプランニング
ユーザ体感を左右するレスポンスタイムと処理能力を示すスループットの違い、待ち行列理論の基本モデルM/M/1による利用率（ρ）と待ち時間の関係、そしてボトルネックを診断してキャパシティを見積もる判断力を、業務要件のシナリオを通じて養います。
システムアーキテクトにとって性能設計は「サーバを増やせば速くなる」という単純な話ではありません。利用者が体感する応答時間（レスポンスタイム）とシステム全体が単位時間に処理できる量（スループット）は別の指標であり、両者はしばしばトレードオフの関係にあります。さらに、キャパシティ（処理能力）に対する負荷の比率が高まるほど、待ち時間は線形にではなく急激に（非線形に）悪化するという待ち行列理論の性質を理解していないと、「まだ利用率50%だから余裕がある」といった誤った安心につながります。この節では、レスポンスタイム/スループットの違いとM/M/1待ち行列モデルを踏まえ、負荷試験の結果からボトルネックを診断し、必要なキャパシティを見積もる判断力を養います。
4.1.1レスポンスタイムとスループット
- レスポンスタイム＝1件のリクエストを送信してから応答を受け取るまでの時間で、利用者が直接体感する指標。スループット＝単位時間あたりにシステムが処理できるリクエスト件数（例：req/秒）で、システム全体の処理能力を示す指標。両者は独立ではなく、後述のとおり負荷（利用率）が高まるとレスポンスタイムが急激に悪化し、結果としてスループットも頭打ちになるという関係にある。
- 性能設計の判断で陥りやすい誤りは「平均レスポンスタイムだけを見て良し悪しを判断する」ことである。実務ではパーセンタイル値（95パーセンタイル・99パーセンタイル等）を用い、「ほとんどのリクエストは速いが、一部が極端に遅い（テールレイテンシ）」という分布の偏りを見抜く必要がある。平均値だけでは、少数の利用者が著しく悪い体験をしている状況を見逃す。
4.1.2M/M/1待ち行列モデルと利用率
- M/M/1＝到着間隔・サービス時間がともに指数分布に従う（ランダム到着・ランダム処理時間）、窓口（サーバ）が1つの待ち行列モデル。到着率を
λ（1秒あたりの平均到着件数）、サービス率をμ（1秒あたりに処理できる平均件数）とすると、利用率（ρ）＝λ／μ（ρ<1が安定条件）で定義される。 - M/M/1モデルにおける平均待ち時間（システム内平均滞在時間）は
W = 1 / (μ − λ)で表される。この式の核心は、利用率ρが1に近づくほど分母(μ−λ)が0に近づき、待ち時間が急激に（非線形に）発散するという性質にある。例えばμ=10件/秒のサーバでλ=8件/秒（ρ=0.8）ならW=1/(10−8)=0.5秒だが、λ=9.5件/秒（ρ=0.95）に増えるとW=1/(10−9.5)=2秒と4倍に悪化する——利用率がわずか15ポイント上がっただけで待ち時間は4倍になる。
「利用率ρ＝λ／μ」「待ち時間W＝1／(μ−λ)＝ρが1に近づくほど非線形に急増」が最頻出です。「利用率50〜60%なら安全」という直感は誤りではありませんが、根拠は待ち行列理論の非線形性（ρが1に近づく手前で余裕を持たせる設計判断）にあることを理解し、単なる経験則の暗記ではなく計算根拉として説明できるようにしておくこと。
4.1.3ボトルネック診断とキャパシティプランニング
- 負荷試験でレスポンスタイムが急激に悪化した場合、システムアーキテクトはどの資源（CPU/メモリ/ディスクI/O/ネットワーク/DB接続プール等）の利用率がρ=1に近づいているかを計測データから特定する。ボトルネックとは、複数の資源のうち処理能力上の律速段階（最も先に飽和する資源）を指し、ボトルネック以外の資源をいくら増強してもシステム全体のスループットは向上しない。
- キャパシティプランニング＝将来の負荷増加（利用者数増・データ量増）を見込み、必要な処理能力をあらかじめ見積もり確保する活動。単に現状のピーク負荷に合わせるのではなく、成長率・季節変動・突発的なスパイク（キャンペーン等）を踏まえた余裕（マージン）を持たせ、かつスケールアウト（水平拡張）かスケールアップ（垂直拡張）のどちらで対応するかを、コストと拡張性のトレードオフで判断する。
あるECサイトのシステムアーキテクトが、注文API のレスポンスタイムが平常時0.3秒だったのに対し、セール開催中は平均2.5秒まで悪化したという報告を受けたとします。まず監視データを確認すると、Webサーバ層のCPU利用率は60%程度で余裕があるものの、注文処理が参照するDB接続プールの利用率が95%（ρ=0.95）に達していたことが分かりました。ここでM/M/1モデルの直感を当てはめると、DB接続プールをμ（処理能力）一定のサーバとみなしたとき、ρ=0.95付近ではW=1/(μ−λ)の分母がほぼ0に近づき、わずかなλ（リクエスト増）の変化でも待ち時間が急激に悪化することが説明できます。ここで陥りやすい誤判断は「CPUに余裕があるのでWebサーバを増設する」という対処です——ボトルネックはDB接続プールであり、Webサーバを増設してもDB接続プールへの要求はむしろ増え、状況が悪化しうる。正しい判断は、
①DB接続プールの上限を引き上げる、
②接続を使い回すコネクションプーリングの効率化、
③参照系クエリをキャッシュやリードレプリカに逃がして接続プールへの負荷そのものを減らす、のいずれか（または組合せ）です。さらに、セールのような予測可能なスパイクに対しては、恒常的にリソースを確保する（コスト増）のではなく、オートスケーリングで一時的にスケールアウトし、平常時のコストを抑えるという設計判断も、キャパシティプランニングの重要な観点です。
| λ（req/秒） | μ（req/秒） | 利用率ρ | 平均待ち時間W |
|---|---|---|---|
| 8 | 10 | 0.8 | 0.5秒 |
| 9.5 | 10 | 0.95 | 2秒（4倍に悪化） |
ひっかけ： 「CPU利用率に余裕があるので性能問題は起きていない」は誤りです——ボトルネックはCPU以外の資源（DB接続プール・ディスクI/O・特定のロック等）に生じうるため、複数資源のうちどれがρ=1に近づいているかを個別に計測する必要があります。また「待ち時間は利用率に比例して緩やかに悪化する」も誤り＝M/M/1モデルでは利用率が1に近づくほど待ち時間は非線形に急増します。
4.1.4この節のまとめ
- レスポンスタイム（利用者体感）とスループット（処理能力）は別指標で、平均値だけでなくパーセンタイル（テールレイテンシ）も見る
- M/M/1モデルの利用率ρ＝λ／μが1に近づくほど待ち時間
W=1/(μ−λ)は非線形に急増する - ボトルネック（律速段階）を計測で特定し、それ以外の資源増強では改善しないと判断する。予測可能なスパイクにはオートスケーリングでコストと性能を両立する
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. ECサイトのセール中に注文APIのレスポンスタイムが悪化した。監視の結果、WebサーバのCPU利用率は60%だが、DB接続プールの利用率が95%に達していた。最も適切な対処はどれか。
Q2. あるサーバのサービス率がμ=10件/秒のとき、到着率λが8件/秒から9.5件/秒に増加した。M/M/1モデルでの平均待ち時間の変化として正しいものはどれか。
Q3. 性能監視の設計で、平均レスポンスタイムだけでなく95パーセンタイル値も併せて確認すべき理由として最も適切なものはどれか。