キャパシティプランニング
将来の負荷を予測し、それを捌くのに必要な資源を前もって見積もり・確保する営みです。スケール戦略とコストのバランスを取り、足りない事故も余りすぎる無駄も避けます。
- 1.キャパシティプランニングは、将来の需要を予測し、必要な計算資源を不足なく・無駄なく確保するための計画。
- 2.需要予測 → 必要資源の見積もり → 余裕(ヘッドルーム)を上乗せ、という流れ。負荷テストの結果が基礎データになる。
- 3.スケール戦略(垂直/水平)とコストのバランスが核心。クラウドの自動スケールでも“上限・初動・コスト”の設計は必要。
キャパシティプランニングとは
キャパシティプランニング(Capacity Planning) は、将来どれだけの負荷が来るかを予測し、それを捌くのに必要な資源を前もって見積もり・確保する 営みです。CPU・メモリ・サーバ台数・データベースの処理能力・ネットワーク帯域などを、「足りなくて落ちる」ことも「余りすぎて無駄に払う」こともないよう調整します。
ねらいは、両極端を避けることです。
- 過小:資源が足りず、アクセス増でレスポンス悪化やダウンを招く(機会損失・信頼失墜)。
- 過剰:使われない資源に金を払い続ける(コストの無駄)。
つまりキャパシティプランニングは 「信頼性」と「コスト」のトレードオフを設計する 仕事です。技術だけでなく、ビジネスの成長見込みと結びつけて考えます。
基本の流れ
キャパシティプランニングは、おおむね次のステップで進みます。
- 需要予測(Demand Forecasting):将来のトラフィックや利用量を見積もる。過去データの傾向、季節性、キャンペーンや新規ユーザー獲得計画を加味する。
- 資源の見積もり:その需要を捌くには何がどれだけ要るかを算出する。「1台あたり何リクエスト捌けるか」を負荷テスト(/devops/load-testing/)で測っておくと、必要台数を逆算できる。
- ヘッドルーム(余裕)の確保:予測ぴったりではなく、急増や故障に備えた余裕 を上乗せする。
- 監視と見直し:実績と予測のズレを観測し、計画を更新し続ける。
「1インスタンスでどこまで捌けるか(限界点)」が分からないと、必要台数は見積もれません。負荷テストでサービス1単位の処理能力とボトルネックを掴む のが、現実的なキャパシティプランニングの出発点です。推測ではなく実測の数字から逆算しましょう。
スケール戦略:垂直 vs 水平
資源を増やす方法は大きく2つあり、スケールアップ(垂直) と スケールアウト(水平) と呼びます。
| 観点 | スケールアップ(垂直) | スケールアウト(水平) |
|---|---|---|
| やること | 1台を高性能にする(CPU/メモリ増強) | 台数を増やす(同じものを並べる) |
| 上限 | マシン性能の物理的な天井がある | 理論上は台数を足し続けられる |
| 可用性 | 1台依存(その1台が落ちると止まる) | 分散され、1台落ちても残りで継続 |
| 向く対象 | 分割しにくいもの(例:単一DB) | ステートレスなアプリ(複製しやすい) |
- スケールアップ:単純で分かりやすい反面、1台の性能には天井 があり、その1台が落ちると全停止です。
- スケールアウト:負荷分散(ロードバランサ)の後ろに同じサーバを並べる方式。台数で稼ぐ ため拡張余地が大きく、可用性も上がります。ただし「どのサーバに振っても同じ結果」になるよう、状態を持たない設計(ステートレス、/devops/twelve-factor-app/)が前提です。
現代のクラウド前提のシステムは、水平スケールを基本 に設計するのが定石です。
自動スケールとの関係
クラウドには オートスケーリング(負荷に応じて台数を自動増減する仕組み) があります。「自動なら、もう人が計画する必要はないのでは?」と思いがちですが、そうではありません。自動スケールにも“設計”が要る のです。
- 上限・下限の設定:際限なく増やすとコストが暴走し、少なすぎると捌けない。最小/最大台数 を決めるのは人間。
- スケールの初動の遅れ:新しいインスタンスが起動して温まるまでには 時間がかかる。瞬間的な急増(スパイク)には間に合わないことがある。
- コストの天井:自動で増えるぶん、放置すると 想定外の請求 になりうる。
オートスケーリングは便利ですが、起動の遅延 があるため瞬間的なスパイクは取りこぼしがちです。セールやテレビ露出のような 予見できる急増 は、自動任せにせず 事前にウォームアップ(先に増やしておく) するのが安全。上限設定を忘れるとコスト事故にもつながります。
コストとのバランス
キャパシティプランニングの肝は コスト最適化 です。資源は多いほど安心ですが、その安心には費用がかかります。代表的な打ち手を挙げます。
- ベース+バースト:常時必要な分は割安な長期契約(リザーブド等)で確保し、変動分だけ従量・自動スケールで賄う。
- 過剰な割り当てを削る:実際の使用率を測り、使っていない分(オーバープロビジョニング) を縮める。クラウドでは「念のため大きめ」が積み重なりがち。
- SLO と紐づける:どこまでの余裕が必要かは、信頼性目標(/devops/sre-slo/)次第。99.9% と 99.99% では要る冗長度もコストもまるで違う。
「安心のために盛る」と「無駄を削る」は綱引きの関係です。監視で実績を見ながら、両者の落としどころを更新し続ける のが、現実的なキャパシティプランニングです。
まとめ
- キャパシティプランニングは 将来の需要を予測し、必要資源を不足なく・無駄なく確保 する営み。信頼性とコストのトレードオフ設計。
- 流れは 需要予測 → 資源見積もり → 余裕(ヘッドルーム)の確保 → 監視と見直し。負荷テストの実測が土台。
- スケールは 垂直(1台を強く)と水平(台数で稼ぐ)。クラウド時代は水平スケール+ステートレスが基本。
- 自動スケールにも上限・初動・コストの設計が必要。SLO と結びつけ、実績を見て調整し続ける。
DevOps/インフラ Article
キャパシティプランニングを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
キャパシティプランニング
比較で見る軸
難易度: intermediate / カテゴリ: DevOps/インフラ / タグ数: 4
導入後に効く点
需要予測 → 必要資源の見積もり → 余裕(ヘッドルーム)を上乗せ、という流れ。負荷テストの結果が基礎データになる。
先に潰すリスク
用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。
- 難易度
- intermediate
- カテゴリ
- DevOps/インフラ
- タグ数
- 4
判断チェックリスト
- 自社の用途が「キャパシティプランニング / スケーラビリティ」に近いか確認する。
- 強みである「キャパシティプランニングは、将来の需要を予測し、必要な計算資源を不足なく・無駄なく確保するための計画。」が本当に評価軸になるか確認する。
- 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。