capacity-planning

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

サービスの完全なキャパシティプランニング文書を作成します。キャパシティプランニングは、未来を正確に予測することではありません。現在の余力を把握し、成長をモデル化し、制約がインシデントになる前にチームがインフラ対応を行えるようにすることです。

優れたキャパシティプランは、次の問いに答えます。最初に不足するものは何か、不足するまでどれくらいかかるか、解消にはいくらかかるか、そしていつ対応するかを誰が決定するのか。

必要な入力情報

まだ提供されていない場合は、次の情報を尋ねてください。

• サービス名と説明 — サービスが何を行い、誰が依存しているか
• 現在のトラフィックと使用状況の指標 — リクエスト数（秒あたり、または日あたり）、アクティブユーザー、データ量など、サービスに最も適した単位
• 現在のリソース使用率 — CPU％、メモリ％、ディスク使用量、コネクションプール使用率、データベースのクエリスループット
• 成長率または予測 — 過去の成長率、または予定されているイベント（製品のローンチ、セール期間、季節的なピーク）
• 技術スタックとインフラ — クラウドプロバイダー、コンピューティングの種類（VM、コンテナ、サーバーレス）、データベース、キャッシュ層、CDN
• コスト制約 — 現在のインフラ支出、許容可能なコスト上限、またはトラフィック単位あたりの目標コスト

出力形式

---

キャパシティプラン：[サービス名]

サービス： [名前] | チーム： [チーム名] 作成者： [名前] | 最終更新日： [日付] 計画期間： [12か月 — [月 年] から [月 年] まで] レビュー頻度： [四半期ごと]

---

1. エグゼクティブサマリー

[現状、最も重大なキャパシティ制約、リスクになるまでの期間、推奨する対応、コストへの影響を含む3～5文。文書全体を読まずに主要な事実を把握する必要があるエンジニアリングマネージャーやVP向けに記述します。]

重大な所見： [例：「現在の成長率では、データベースのコネクションプールは6週間以内に使用率が90％に達します。対応しなければ、通常のトラフィックでもリクエストのキューイングとレイテンシの急増が発生します。」]

直ちに推奨する対応： [例：「今後2週間以内にコネクションプールの上限を引き上げ、リードレプリカを追加します。」]

コストへの推定影響： [例：「推奨する変更により、インフラ支出が月額約 $[X] 増加します。」]

---

2. 現在のベースライン

特記がない限り、すべての指標は30日間の平均です。取得日：[日付]

トラフィック

指標	値	ピーク（7日間）	備考
1秒あたりのリクエスト数（平均）	[X req/s]	[X req/s]	[ピークの時間帯／曜日]
1日あたりのリクエスト数	[X M/day]	[X M/day]	—
アクティブユーザー数（DAU/MAU）	[X] / [X]	—	—
[サービス固有の指標 — 例：1時間あたりの処理ジョブ数]	[X]	[X]	—
[サービス固有の指標 — 例：1日あたりの取り込みデータ量（GB）]	[X GB]	[X GB]	—

コンピューティング

リソース	現在の使用率	インスタンスタイプ	数	備考
CPU（平均）	[X%]	[例：c5.2xlarge]	[X]	ピーク：[X%]
メモリ（平均）	[X%]	—	—	ピーク：[X%]
ネットワーク送信量	[X Mbps]	—	—	—
コンテナ／ポッド数	[X]	[例：2 vCPU / 4 GB]	—	オートスケーリング範囲：[X–Y]

データベース

リソース	現在の使用率	仕様	備考
CPU	[X%]	[例：db.r5.2xlarge]	ピーク：[X%]
メモリ	[X%]	[X GB RAM]	—
使用ストレージ	[Y GB] 中 [X GB]（[Z%]）	[X GB プロビジョニング済み]	成長量：[月あたり約 X GB]
IOPS（平均）	[Y プロビジョニング済み] 中 [X]	[Y IOPS]	ピーク：[X IOPS]
コネクションプール	[Y 最大] 中 [X]（[Z%]）	最大接続数：[Y]	[ORM プールサイズ：X]
クエリ P99 レイテンシ	[X ms]	—	[最も遅いクエリ：X]
読み取り／書き込み比率	読み取り [X%] / 書き込み [Y%]	—	—

キャッシュ

リソース	現在の使用率	仕様	備考
使用メモリ	[Y GB] 中 [X GB]（[Z%]）	[例：cache.r6g.large]	エビクション率：[X%]
ヒット率	[X%]	—	ミス率：[Y%]
接続数	[X]	最大：[Y]	—

ストレージ／オブジェクトストア

リソース	現在の使用量	増加率	備考
[S3 / GCS / Blob]	[X GB / TB]	[~X GB/月]	[ライフサイクルポリシーは設定済みですか？ Y/N]
ディスク（該当する場合）	[Y GB] 中 [X GB]	[~X GB/月]	[RAID / EBS タイプ]

コストのベースライン

コンポーネント	現在の月額コスト	合計に占める割合
コンピューティング（アプリサーバー）	$[X]	[X%]
データベース	$[X]	[X%]
キャッシュ	$[X]	[X%]
ストレージ	$[X]	[X%]
CDN／帯域幅	$[X]	[X%]
その他（[説明]）	$[X]	[X%]
合計	$[X]	100%

ユニットエコノミクス： [1,000 リクエスト／1,000 ユーザー／処理済み GB] あたり $[X]

---

3. 成長予測

前提条件

前提条件	値	情報源	確度
月間トラフィック増加率	[X%]	[過去の傾向／製品予測]	[高／中／低]
季節的なピーク係数	[［月］に +X%]	[昨年のデータ／予定されているローンチ]	[高／中]
今後のイベント	[例：マーケティングキャンペーン — ［月］、トラフィックが +[X]% 急増する見込み]	[マーケティング計画]	[中]
ユーザー増加数	[月あたり新規ユーザー X 人]	[営業パイプライン／成長モデル]	[中]
データ増加量	[X GB/月]	[現在の傾向]	[高]

トラフィック予測

期間	リクエスト/秒（平均）	リクエスト/秒（ピーク）	DAU	データ量（累計）
現在（ベースライン）	[X]	[X]	[X]	[X GB/TB]
+3 か月	[X]	[X]	[X]	[X GB/TB]
+6 か月	[X]	[X]	[X]	[X GB/TB]
+12 か月	[X]	[X]	[X]	[X GB/TB]

成長の計算式：[ベースライン] × (1 + [月間増加率])^[月数] + 季節調整

キャパシティ余力の分析

現在の使用率と予測成長率に基づき、各リソースはいつ上限に達しますか？

リソース	現在の使用率	安全上限	残りの余力	上限までの月数
アプリ CPU	[X%]	70%	[X%]	[X か月]
アプリメモリ	[X%]	80%	[X%]	[X か月]
DB CPU	[X%]	70%	[X%]	[X か月]
DB ストレージ	[Y GB] 中 [X GB]	80% = [Z GB]	[X GB]	[X か月]
DB IOPS	[Y] 中 [X]	80% = [Z]	[X IOPS]	[X か月]
DB 接続数	[Y] 中 [X]	80% = [Z]	[X]	[X か月]
キャッシュメモリ	[Y GB] 中 [X GB]	75% = [Z GB]	[X GB]	[X か月]
ストレージ（オブジェクト）	[X TB]	固定上限なし — コストをトリガーとして判断	—	[コストのトリガー：$X/月]

警告サイン（3 か月以内に上限に達するリソース）：

• [リソース]：[現在値]% → [X 週間]で上限 — 対応が必要
• [リソース]：[現在値]% → [X 週間]で上限 — 対応が必要

---

4. リソース要件

コンピューティング要件

期間	必要なインスタンス数	推奨インスタンスタイプ	オートスケーリング範囲	備考
現在	[X]	[タイプ]	[最小：X、最大：Y]	現在の構成
+3 か月	[X]	[タイプ]	[最小：X、最大：Y]	[インスタンスタイプの変更が必要ですか？]
+6 か月	[X]	[タイプまたはアップグレード]	[最小：X、最大：Y]	[［より大きなタイプ／水平スケーリング］を検討]
+12 か月	[X]	[タイプまたはアップグレード]	[最小：X、最大：Y]	[水平スケーリングと垂直スケーリングの判断状況]

メモリ余力の目標： 平均負荷時に使用可能なメモリを 30% 以上、ピーク時に 20% 以上確保します。 CPU 余力の目標： 平均負荷時に使用可能な CPU を 30% 以上、ピーク時に 15% 以上確保します。

データベース要件

期間	インスタンスタイプ	ストレージ	IOPS	リードレプリカ	備考
現在	[タイプ]	[X GB]	[X]	[Y/N]	現在
+3 か月	[タイプ]	[X GB]	[X]	[Y/N]	[ストレージ／IOPS をアップグレード]
+6 か月	[タイプまたはアップグレード]	[X GB]	[X]	はい	[この時点までにリードレプリカを推奨]
+12 か月	[タイプ]	[X GB]	[X]	[X 個のレプリカ]	[この規模ではシャーディング／パーティショニングを検討]

ストレージ増加の管理：

• 現在の増加量：[~X GB/月]
• ストレージのオートスケーリング：[有効／無効 — [日付]までに有効化]
• アーカイブポリシー：[X か月より古いレコードを [低頻度アクセスストレージ／アーカイブ層] に移動]

キャッシュ要件

期間	ノードタイプ	ノード数	メモリ	備考
現在	[type]	[X]	[X GB]	現在
+6 か月	[type]	[X]	[X GB]	[スケールアウトまたはアップグレード]
+12 か月	[type]	[X]	[X GB]	[必要な容量が >Y GB の場合はクラスターモード]

---

5. スケーリング戦略

コンピューティング — 水平スケーリング

方針：[水平／垂直／両方]

[スケーリング戦略とその理由を記述します。例：「アプリケーションはステートレスで、CPU バウンドです。水平スケーリングを優先し、垂直スケーリングは短期的な代替策としてのみ使用します。」]

オートスケーリングの設定：

Scale-out trigger:  CPU > [X%] for [Y minutes] OR memory > [X%] for [Y minutes]
Scale-in trigger:   CPU < [X%] for [Y minutes] AND memory < [X%] for [Y minutes]
Min instances:      [X] (ensures HA across [X] AZs)
Max instances:      [Y] (cost ceiling)
Cooldown period:    [X seconds]
Warmup time:        [X seconds] (time for new instance to be healthy)

水平スケーリングの限界：

• [例：現在のボトルネックはデータベースの接続プールです。DB 接続数を増やさずにアプリインスタンスを増やしても効果はありません]
• [例：WebSocket 接続にはセッションアフィニティが必要なため、完全なステートレススケーリングには制限があります]

データベース — 読み取りスケーリング

戦略：[読み取りレプリカ／PgBouncer による接続プーリング／クエリキャッシュ／現時点では不要]

読み取りレプリカを追加するタイミング：

• DB CPU 使用率が 60% を超える状態が 30 分以上継続した場合、または
• 読み取りクエリの P95 レイテンシが 50ms を超えた場合、または
• 接続プールの使用率が 70% を超えた場合

接続プーリング：

• プーラー：[PgBouncer／RDS Proxy／アプリケーションレベル／未設定]
• プールサイズ：[アプリインスタンスあたり X 接続 × Y インスタンス = 合計 Z]
• DB 接続の最大数：[20% の余裕を加え、Z に設定]

キャッシュ戦略

キャッシュポリシー：[キャッシュアサイド／ライトスルー／ライトビハインド] TTL 戦略：

データタイプ	TTL	無効化方法
[例：ユーザープロフィール]	[5 分]	[更新時に明示的に無効化]
[例：製品カタログ]	[1 時間]	[TTL の期限切れ — 結果整合性を許容]
[例：セッションデータ]	[24 時間]	[ログアウト時に明示的に無効化]

キャッシュミス時の処理：[キャッシュミス時の動作を記述します。問題なくフォールスルーするか、サンダリングハードのリスクが発生するかを記述してください。]

---

6. コスト予測

インフラコストの予測

コンポーネント	現在（月額）	+3 か月	+6 か月	+12 か月
コンピューティング	$[X]	$[X]	$[X]	$[X]
データベース	$[X]	$[X]	$[X]	$[X]
キャッシュ	$[X]	$[X]	$[X]	$[X]
ストレージ	$[X]	$[X]	$[X]	$[X]
CDN／帯域幅	$[X]	$[X]	$[X]	$[X]
合計	$[X]	$[X]	$[X]	$[X]
前月比成長率 %	—	[X%]	[X%]	[X%]

ユニットエコノミクスの推移：

期間	リクエスト 1,000 件あたりのコスト	ユーザー 1 人あたりの月額コスト	備考
現在	$[X]	$[X]	ベースライン
+6 か月	$[X]	$[X]	[改善／悪化 — 理由]
+12 か月	$[X]	$[X]	[目標：リクエスト 1,000 件あたり $X]

コスト最適化の機会：

機会	推定削減額	作業量	時期
[例：ベースラインのコンピューティングにリザーブドインスタンスを使用]	$[X/月]	低	即時
[例：S3 ライフサイクルポリシー — 90 日を超えたオブジェクトを Glacier に移動]	$[X/月]	低	今回のスプリント
[例：[instance] の適正サイズ化 — 現在は過剰にプロビジョニングされています]	$[X/月]	低	今回のスプリント
[例：上位 5 件の低速クエリを最適化 — DB のコンピューティング需要を削減]	$[X/月]	中	次の四半期

---

7. キャパシティのしきい値と対応

インシデント発生後の事後対応ではなく、明確な対応が必要となるしきい値を定義します。

リソース	監視（黄色）	対応（赤色 — 作業を計画）	緊急（インシデントのリスク）
アプリの CPU（継続的な平均）	>60%	>70%	>85%
アプリのメモリ	>70%	>80%	>90%
DB の CPU	>55%	>65%	>80%
DB のストレージ	>65%	>75%	>85%
DB の接続数	>60%	>70%	>85%
キャッシュのメモリ／エビクション	ヒット率 <90%	ヒット率 <85%	ヒット率 <75%
エラー率	>0.5%	>1%	>2%
P99 レイテンシ	ベースラインの >2 倍	ベースラインの >3 倍	ベースラインの >5 倍

監視しきい値を超えた場合：

• 検知したエンジニアが、キャパシティラベルを付けてチケットを作成します
• 次回のスプリント計画でチケットをレビューします

対応しきい値を超えた場合：

• オンコールエンジニアが、P2 としてマークしたチケットを作成します
• テックリードが 24 時間以内にレビューします
• 1 スプリント以内に対応計画を文書化し、スケジュールに組み込みます

緊急しきい値を超えた場合：

• インシデントの可能性として扱い、オンコール担当者にページを送ります
• 緊急のスケーリング対応を直ちに実施します（ランブックを参照）
• 2 時間以内に根本原因の調査を開始します

緊急スケーリングのランブック： [キャパシティインシデント用の oncall-runbook へのリンク]

---

8. インフラストラクチャ対応ロードマップ

直ちに実施する対応（今後 2 週間）

対応	担当者	工数	根拠
[例：DB 接続プールの上限を X に引き上げる]	[名前]	[2 時間]	[DB 接続数が X% に達しており、X 週間で上限に達する]
[例：RDS でストレージの自動スケーリングを有効にする]	[名前]	[30 分]	[ストレージが X% に達しており、X か月後の緊急事態を防ぐ]
[例：[bucket] に S3 ライフサイクルポリシーを追加する]	[名前]	[1 時間]	[ストレージが不必要に月額 $X のペースで増加している]

今四半期（3 か月以内）

対応	担当者	工数	根拠
[例：本番 DB にリードレプリカを追加する]	[名前]	[1 日]	[DB の CPU は 2 か月後に 65% に達する見込み]
[例：自動スケーリングの最大値を X から Y に引き上げる]	[名前]	[2 時間]	[現在の最大値では、予想されるピークに対する余裕が少なすぎる]
[例：接続プーリング用に PgBouncer を設定する]	[名前]	[3 日]	[接続ごとのオーバーヘッドを削減し、成長に備えた余裕を確保する]

次の四半期（3〜6 か月）

対応	担当者	工数	根拠
[例：DB インスタンスクラスをアップグレードする — [現在] → [次]]	[名前]	[2 時間 — ブルー／グリーン]	[DB の CPU は Q[X] までに 70% に達する見込み]
[例：[読み取り頻度の高いエンドポイント] にキャッシュを実装する]	[名前]	[1 週間]	[DB の読み取り負荷を推定 [X%] 削減する]
[例：DB の水平シャーディングを評価する]	[名前]	[2 週間（スパイク）]	[12 か月後の予測では、単一の DB が上限に達する]

長期的な見通し（6〜12 か月）

対応	説明	トリガー条件
[例：マルチリージョンデプロイ]	[eu-west-2 にアクティブ／パッシブ構成を構築]	[DAU が X を超える、または SLA で 99.99% が求められる]
[例：データベースのシャーディング、または分散 DB への移行]	[CockroachDB / Vitess を評価]	[単一ノードの DB が上限に達する見込み]
[例：CDN の拡張]	[[region] に PoP を追加]	[[地域] でレイテンシ SLO に違反]

---

アンチパターン

• ベースラインを把握せずにキャパシティのしきい値を設定しないでください。「CPU > 70%」というアラートも、通常の状態を把握していなければ意味がありません
• 平均トラフィックだけを基準に計画しないでください。ピーク負荷をモデル化しないキャパシティ計画では、最も重要なイベント中にインシデントが発生します
• 垂直スケーリングと水平スケーリングを混同しないでください。データベースの接続数の上限に対処せずにアプリサーバーを増やしても、制約は解消されません
• 成長予測を確実なものとして提示しないでください。すべての予測には不確実性があります。確信度を示し、保守的なシナリオと楽観的なシナリオを提示してください
• 担当者と具体的な日付を決めずに対応項目を先送りしないでください。担当者のいないロードマップは、単なる願望のリストです

品質チェック

• すべてのリソースについて、現在の使用率を定量化し、上限に達するまでの予測月数を示しています。曖昧な表現はありません
• 最も重大な制約を、具体的な時期とともにエグゼクティブサマリーで明示しています
• 成長予測には前提条件と信頼度を記載しており、確実なものとして提示していません
• キャパシティのトリガーでは、注意・危険のしきい値を定め、それぞれのレベルで誰が対応するかを明記しています
• コスト予測には、絶対額だけでなくユニットエコノミクスを含めています
• インフラロードマップには、希望的な項目を並べるだけでなく、担当者と工数の見積もりを記載しています
• オートスケーリングの設定には、スケールアウトとスケールインの両方のトリガー、および最小・最大範囲が含まれています
• アクションは緊急度順に並んでおり、即時対応の項目が単なるバックログの埋め合わせになっていません

トリガーとなるフレーズの例

• 「インフラのキャパシティを計画する。」
• 「リソースのニーズを予測する。」
• 「トラフィックの成長をモデル化する。」
• 「スケーリング戦略を定義する。」
• 「サービスのキャパシティレビューを作成する。」