TL

キャパシティモデリングと負荷予測

勘の見積もりを卒業し、需要予測と利用率目標から必要台数を数式で導けます。季節性・成長率・p99余裕を織り込み、待ち行列理論で飽和点を統計的に見極めます。

応用キャパシティプランニング待ち行列理論需要予測性能SRE最終更新: 2026-06-21
TL;DR要点だけ先に
  • 1.必要容量は『予測需要 ÷(1台あたり処理能力 × 目標利用率)』が基本式。利用率を上げるほど台数は減るが、待ち時間は1/(1−ρ)で跳ね上がる。
  • 2.需要予測は基準水準・成長トレンド・季節性・不確実性に分解する。p99余裕は平均ではなく分散と裾を見て、予測区間の上側で台数を決める。
  • 3.飽和点は待ち行列理論で見極める。利用率の目標は70〜80%が定石で、それを超えると応答時間が非線形に悪化するため、ヘッドルームが安全余裕になる。

キャパシティモデリングとは何を解く問題か

キャパシティモデリング は「この需要を、決めた品質目標(応答時間やエラー率)で捌くには、資源がどれだけ要るか」を 数式とデータで導く 営みです。勘で台数を盛るキャパシティプランニングを、再現可能なモデルに置き換えます。

核になる関係式は単純です。プレーンテキストで書くと次のとおり。

必要容量 = 予測需要(ピーク時の毎秒リクエスト数)
         / (1台あたり処理能力 × 目標利用率)

ここで肝心なのは 目標利用率 をどう置くかです。利用率を1.0に近づけるほど割り算の分母が大きくなり、必要台数は減ってコストは下がります。しかし後述するとおり、利用率を上げると待ち時間が非線形に悪化するため、ここに ヘッドルーム(余裕) を埋め込みます。

需要予測:4成分への分解

将来需要 D(t) は、時系列を4つの成分に分解して予測するのが定石です。

  • 基準水準(レベル):その時点でのベースとなる量。直近の移動平均などで掴む。
  • トレンド(成長率):右肩上がり/下がりの傾き。線形成長か複利成長(指数)かで将来像が大きく変わる。
  • 季節性:日次・週次・年次の周期。ECなら日曜夜のピーク、業務系なら月初・期末など。
  • 残差(不確実性):上記で説明しきれないノイズ。これがヘッドルームの根拠になる。
D(t) ≈ レベル(t) + トレンド(t) + 季節成分(t) + 残差

成長率を 複利 で扱うことが特に重要です。月次 r の成長が続くなら、n か月後は基準値に (1+r) の n 乗を掛けます。月5%でも12か月で約1.8倍、24か月で約3.2倍になります。線形外挿で済ませると、急成長期には深刻に過小見積もりになります。

平均ではなくピークで設計する

需要予測で見るべきは月平均ではなく ピーク時の毎秒リクエスト数 です。容量は最も混む瞬間に耐えられなければ意味がありません。日次・週次のピーク係数(平均に対するピークの倍率、ピーク・トゥ・アベレージ比)を実測し、平均予測に掛けてピークを推定します。

飽和点を待ち行列理論で見極める

なぜ利用率を100%まで使い切ってはいけないのか。答えは 待ち行列理論 にあります。サーバーへの到着がランダムで処理時間にばらつきがある(M/M/1モデル)とき、システム内の平均応答時間は利用率 ρ(ロー、到着率÷処理率)に対して次のように振る舞います。

平均応答時間 ∝ 1 / (1 − ρ)

この 1/(1−ρ) が飽和の正体です。ρ が0.5なら係数は2、0.8なら5、0.9なら10、0.95なら20。つまり利用率を80%から95%へ「少し」上げただけで、待ち時間は4倍に膨らみます。容量を削ってコストを下げたつもりが、応答時間が崖から落ちる——これが飽和点です。

目標利用率 ρ待ち時間係数 1/(1−ρ)意味ヘッドルーム
0.52倍余裕は大きいがコスト過剰50%
0.7約3.3倍実務の安全圏の下限30%
0.85倍多くのオンラインサービスの定石20%
0.910倍テイルが急悪化、急増に脆弱10%
0.9520倍ほぼ飽和、運用は危険5%

実務では 目標利用率を70〜80% に置くのが定石です。残りの20〜30%がヘッドルームで、これは「無駄な余り」ではなく 急増・故障・予測誤差を吸収する保険 です。サーバー台数を増やす(M/M/cにする)と、台数 c が多いほど同じ利用率でも待ち時間の悪化は緩やかになります(規模の経済)。大規模クラスタほど高い利用率を狙える理由です。

p99余裕:平均ではなく裾で決める

容量設計でやりがちな失敗は、平均だけを見ることです。SLO は通常 パーセンタイル(p99 など)で定義されます。p99 は分布の 裾(テイル) であり、利用率上昇に対して平均よりはるかに敏感に悪化します。前述の 1/(1−ρ) は平均の話で、テイルはさらに鋭く跳ねます。

そこで台数は 予測の点推定ではなく予測区間の上側 で決めます。需要予測 D には残差分散があるので、安全在庫の考え方と同じく次のように上乗せします。

設計需要 = 予測需要 + z × 予測誤差の標準偏差

z は目標とするサービスレベルに対応する係数で、片側でおよそ p95 なら 1.65、p99 なら 2.33、p99.9 なら 3.09。高い可用性を約束するほど z は大きくなり、必要容量とコストは増えます。どこまで盛るかは SLOエラーバジェット が決める経営判断であり、技術的に一意には決まりません。

頻出:リトルの法則で在庫を読む

待ち行列の基本である リトルの法則 は L = λ × W(系内の平均件数 = 到着率 × 平均滞在時間)。スループット λ と平均応答時間 W を実測すれば、同時に処理している件数 L が分かり、必要なスレッド数・コネクション数・ワーカー数の見積もりに直結します。負荷テスト(/devops/load-testing/)の結果から λ と W を取り、L を逆算するのが定石です。

モデルを運用に組み込む

モデルは作って終わりではなく、実績との誤差を監視して更新し続けます。予測値と実測値のズレ(MAPE など平均絶対パーセント誤差)を追い、季節成分や成長率を再校正します。さらに、予測した飽和点に対する現在地を常時可視化し、オートスケーリング の上限・下限や 負荷制御(ロードシェディング) の閾値とつなぎます。予見できる急増(セール・露出)は自動スケールの初動遅れが間に合わないため、モデルの予測に基づき 事前にウォームアップ します。

まとめ

  • 必要容量は 予測需要 ÷ (1台あたり処理能力 × 目標利用率)。利用率を上げると台数は減るが待ち時間が非線形に悪化する。
  • 需要は レベル・トレンド(複利成長)・季節性・残差 に分解し、月平均ではなく ピーク で設計する。
  • 飽和点は待ち行列理論の 1/(1−ρ) で見極める。目標利用率70〜80%、残りがヘッドルーム。
  • SLO は p99 など裾で定義されるため、点推定でなく 予測区間の上側(z 係数) で台数を決める。リトルの法則で系内件数を逆算し、実測で継続的に校正する。

DevOps/インフラ Article

キャパシティモデリングと負荷予測を実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

キャパシティプランニング

比較で見る軸

難易度: advanced / カテゴリ: DevOps/インフラ / タグ数: 5

導入後に効く点

需要予測は基準水準・成長トレンド・季節性・不確実性に分解する。p99余裕は平均ではなく分散と裾を見て、予測区間の上側で台数を決める。

先に潰すリスク

用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。

数字・仕様の読み方
難易度
advanced
カテゴリ
DevOps/インフラ
タグ数
5

判断チェックリスト

  • 自社の用途が「キャパシティプランニング / 待ち行列理論」に近いか確認する。
  • 強みである「必要容量は『予測需要 ÷(1台あたり処理能力 × 目標利用率)』が基本式。利用率を上げるほど台数は減るが、待ち時間は1/(1−ρ)で跳ね上がる。」が本当に評価軸になるか確認する。
  • 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

キャパシティプランニング待ち行列理論需要予測性能SREキャパシティプランニング待ち行列理論需要予測