キャパシティモデリングと負荷予測
勘の見積もりを卒業し、需要予測と利用率目標から必要台数を数式で導けます。季節性・成長率・p99余裕を織り込み、待ち行列理論で飽和点を統計的に見極めます。
- 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.5 | 2倍 | 余裕は大きいがコスト過剰 | 50% |
| 0.7 | 約3.3倍 | 実務の安全圏の下限 | 30% |
| 0.8 | 5倍 | 多くのオンラインサービスの定石 | 20% |
| 0.9 | 10倍 | テイルが急悪化、急増に脆弱 | 10% |
| 0.95 | 20倍 | ほぼ飽和、運用は危険 | 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、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。