Capacity Planning

リソース枯渇の予測と事前対応で「突然のサーバーダウン」を防ぐ

ECクライアントで年末セール当日の午前10時、突然サイトが落ちる。DBのディスクが満杯。緊急で追加ストレージを発注するが調達に3日かかり、数千万円の機会損失。翌日の会議で「なぜ予測できなかったのか」と責任追及。

よくある課題

キャパシティプランニング 3 ステップ

1現状計測

CPU・メモリ・ストレージ・帯域の使用量をメトリクスで収集。過去トレンドを可視化。

↓

2成長予測

線形・指数・季節性モデルで将来のリソース需要を予測。枯渇時刻（Time to Exhaustion）を算出。

↓

3調達計画

リードタイムを考慮して事前に発注・スケールアウト。コスト最適化も同時に検討。

枯渇予測（TTE）たとえるなら「燃料計の「あと何km走れるか」」

Time to Exhaustion。現在の使用量と成長率から「何日後に上限に達するか」を計算。これが計画の出発点。

例：現在50GB、毎日2GB増加、上限100GB → (100-50)÷2 = 25日後に枯渇

成長モデルたとえるなら「需要予測の手法」

線形（毎月一定増加）・指数（毎月倍増）・季節性（年末に急増）の3パターン。間違ったモデルを選ぶと予測が大きく外れる。

例：SNSサービスが急成長中→線形ではなく指数モデルで予測しないと大幅に過小評価

リードタイムたとえるなら「発注から納品までの時間」

リソース調達に必要な期間。「枯渇予測日 - リードタイム - バッファ」が対応開始期限。これを知らないと手遅れになる。

例：クラウド新インスタンス: 即時。オンプレサーバー: 2〜4週間。

バッファ（安全余白）たとえるなら「安全在庫」

上限の20〜30%は余裕として確保する。ピークトラフィックへの対応とウォームアップ時間を考慮。

例：最大使用量80GBのディスク → 100GBを調達（20%バッファ）

Auto Scaling vs 事前スケールたとえるなら「エアコンの自動vs手動」

Auto Scalingは数分かかる。年末セールのような急激な増加には事前スケールが必要。組み合わせが重要。

例：大型セールの1週間前から段階的にキャパシティを増やし、当日に最大規模にしておく

閾値アラートたとえるなら「燃料警告灯」

上限の80%到達時点でアラートを発火させる。100%になってから知るのでは遅い。Prometheusで自動設定可能。

例：ディスク使用率80%でSlack通知 → チームが2週間前に対処できる

キャパシティ予測チャート（CPU使用率 %）

行動タイミング: 枯渇の 2〜3ヶ月前には調達・スケールアップを開始する必要がある。リードタイムを考慮した計画が重要。

これまで人がしていた作業

AI が担う作業

人に残る役割

主なツール：AWS Predictive Scaling、Google Cloud Autopilot、Datadog Forecast、Azure AI、Spot by NetApp

この先の見通し：2027年にはAIがビジネス計画（売上目標・マーケティングカレンダー）を読み込み、インフラ需要を自動予測・プロビジョニングする完全自律型キャパシティ管理が実現。人間の介入は異常値のレビューと大型投資の承認のみになる見込み。