TL

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

将来の負荷を予測し、それを捌くのに必要な資源を前もって見積もり・確保する営みです。スケール戦略とコストのバランスを取り、足りない事故も余りすぎる無駄も避けます。

中級キャパシティプランニングスケーラビリティコスト最適化性能最終更新: 2026-06-06
TL;DR要点だけ先に
  • 1.キャパシティプランニングは、将来の需要を予測し、必要な計算資源を不足なく・無駄なく確保するための計画。
  • 2.需要予測 → 必要資源の見積もり → 余裕(ヘッドルーム)を上乗せ、という流れ。負荷テストの結果が基礎データになる。
  • 3.スケール戦略(垂直/水平)とコストのバランスが核心。クラウドの自動スケールでも“上限・初動・コスト”の設計は必要。

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

キャパシティプランニング(Capacity Planning) は、将来どれだけの負荷が来るかを予測し、それを捌くのに必要な資源を前もって見積もり・確保する 営みです。CPU・メモリ・サーバ台数・データベースの処理能力・ネットワーク帯域などを、「足りなくて落ちる」ことも「余りすぎて無駄に払う」こともないよう調整します。

ねらいは、両極端を避けることです。

  • 過小:資源が足りず、アクセス増でレスポンス悪化やダウンを招く(機会損失・信頼失墜)。
  • 過剰:使われない資源に金を払い続ける(コストの無駄)。

つまりキャパシティプランニングは 「信頼性」と「コスト」のトレードオフを設計する 仕事です。技術だけでなく、ビジネスの成長見込みと結びつけて考えます。

基本の流れ

キャパシティプランニングは、おおむね次のステップで進みます。

  1. 需要予測(Demand Forecasting):将来のトラフィックや利用量を見積もる。過去データの傾向、季節性、キャンペーンや新規ユーザー獲得計画を加味する。
  2. 資源の見積もり:その需要を捌くには何がどれだけ要るかを算出する。「1台あたり何リクエスト捌けるか」を負荷テスト(/devops/load-testing/)で測っておくと、必要台数を逆算できる。
  3. ヘッドルーム(余裕)の確保:予測ぴったりではなく、急増や故障に備えた余裕 を上乗せする。
  4. 監視と見直し:実績と予測のズレを観測し、計画を更新し続ける。
負荷テストが土台になる

「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、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

キャパシティプランニングスケーラビリティコスト最適化性能キャパシティプランニングスケーラビリティコスト最適化性能
参考: 公式情報