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

1）キャパシティプランニングとは何か、なぜ必要なのか

キャパシティプランニングは、目標SLOを最小限のコストで達成するために必要なリソースを評価し、確保する体系的なプロセスです。CPU/メモリだけでなく、ネットワーク帯域幅、ストレージ、データベース/キャッシュ、キュー/イベントバス、外部プロバイダ（payment/CCM/anti-fraud）、人事（on-call、 support）についても話しています。

• ピークや劣化でもSLO/SLAを実行します。
• TCOと資本の過剰供給を最小限に抑えます。
• リソース不足（飽和→p99/エラー）によるインシデントのリスクを軽減します。
• リリースとキャンペーン（マーケティング、トーナメント、トップマッチ）の予測可能性を確保します。

2）真実の入力と情報源

観測性：RPS/連結、 p50/p95/p99、エラー率、飽和（CPU、 mem、 ディスクIOPS、 ネットワークpps/mbps）、キュー長、レート制限。
ビジネスイベント：キャンペーンカレンダー、季節性（夜/週末/メガイベント）、地域/管轄。
技術的負債/機能：リリースのロードマップ、アーキテクチャの変更（暗号化、新しいロギングなど）。
プロバイダー：クォータと支払いのスループット/CUS/メール/詐欺防止サービス。
過去のインシデント：ボトルネック（データベース、キャッシュ、L7バランサー、バス、CDN、ディスク）はどこにありますか。

3）基本的な概念と数式

ヘッドルーム-容量マージン：'headroom=（max_stable_RPS − actual_RPS ）/max_stable_RPS'。
20-40％ピーク時の目標（クリティカルストリームの場合）。
飽和-使用可能なリソースの比率（CPU％、 メモリ/GC、接続、ファイル記述子、IOPS、キュー深さ）。
スループット安定-p99とエラーレートがSLOを長時間実行する速度（ワンタイムバーストではありません）。
容量単位（CU）-サービスのための電源の正規化された単位（例えば、ポッドvCPUあたりX RPS=1、 RAM=2 GiB）。
システム制限は、劣化せずに最大です：'N_pods × CU'。共有依存関係（DB/cache/bus）を考慮することが重要です。

4）需要モデル： 予測

統計シリーズ：毎週/毎日の季節性、休日、スポーツ決勝、地域のピーク。
コホート：国によって、支払の提供者、装置、VIPセグメント。
イベントデルタ：キャンペーン/プーチ/リリース/SEOの影響。
「What if」（シナリオ計画）：19：00-22：00のトラフィックに+50％；プロバイダA→Bへの再配布のドロップ（遅延に対する+30％）。
リアルタイム調整：リードメトリクス（セッションのリバイタリゼーション、マッチのキュー、バスケット）によるノウキャスト。

5）供給モデル： チェーンが「壊れる」ところ"

お問い合わせコンベア：エッジ/CDN→L7バランサー→アプリケーション→キャッシュ→DB→外部API→ターン/タイヤ→ハンドラ/ETL。

• 容量（CU/インスタンス）、拡張性（horizon/vertex）、制限（connections、 pps、 IOPS）、遅延。
• 故障ポリシー（レート制限、遮断器、劣化）。
• SLOはローカルであり、e2e-SLOへの貢献です。

6）エラー証拠金と予算

私たちは、ヘッドルームをエラー予算にバインドします。
クリティカルフロー（支払い/検証）-上記のヘッドルーム、セカンダリフロー-以下。
寒さ/暖かい埋蔵量：ピーク/事故で活性化。

7）スケーリング： 戦術

HPA（ロードメトリクスによる）：RPS、レイテンシ、キュー長、ユーザーSLI （CPU％より優れています）。
VPA：ポダムリソースの修正（statefulとp99 GCに注意）。
KEDA/アダプター：外部ソース（Kafka lag、 Redis list length、 CloudQueue depth）によるスケーリング。
ウォームプール/ウォームアップ：コールドスタートを避けるために事前に発生したインスタンス。
「Load-as-Code」アプローチ：オートスケール/リミット/タイムアウト/リトレイポリシーはバージョン管理およびレビューされます。

8）キュー、背圧および尾制御

目標は、p99の雪崩のような成長を防ぐことです。
並行性とキューサイズを制限し、タイムウィンドウとidempotenceを入力します。
ヘッジ/再試行予算：ユーザーとシステムの合計時間予算を制限します。
グレースフルな劣化：オーバーロード時にセカンダリ機能を無効にします。

9） DB、キャッシュ、ストレージ

DB：接続制限、ログ/FSync、インデックス、クエリ計画、レプリカラグ、ホットキー/テーブル、トランザクションの最大TPS。
けし：セグメント別ヒット率、リリース/障害時の「ミスの嵐」、キー配分。
ストレージ：IOPS/スループット、遅延、圧縮、TTL、古いバッチ/スナップショットのクリーニング。
移行スキーム：expand→migrate→contract（ストップロックなし）。

10）イベントフローとETL

Kafka/bus：パーティースループット、遅延、ISR、圧縮、生産者/消費者の限界。

ETL/バッチ： 起動ウィンドウ、ランタイムバジェット、スロットルI/O

重要なフロー（支払い/残高）のためのIdempotenceとPercety-Once-like。

11）ネットワークおよび周囲

L4/L7バランサ：接続制限、syn backlog、 TLSオフロード、セッション再利用。
CDN/Edge：帯域幅、原点負荷を低減するキャッシュポリシー。
ネットワーク内の制限：VPC/サブネットのpps/mbps、 egress-cost （FinOps）。

12）複数地域、DRおよび管轄

戦略：アクティブアクティブ（GSLB/Anycast）、アクティブパッシブ（ホット/ウォーム/コールドDR）。
地域ごとのN+1： SLOコアストリームを維持しながらAZ/regionの損失を維持します。
法的ローカライズ：国、異なる制限、SLOによるトラフィック/データのプロバイダへの分割。
DRテスト：実際の負荷伝達を用いる規則的なゲーム日。

13）外部プロバイダ： クォータとルート

支払い/KYC/詐欺 防止/メール/SMS： TPS、バーストクォータ、毎日の制限。
マルチプロバイダ：レイテンシ/成功によるルーティング、プロバイダごとのSLO、オートフィーラー。
SLA契約：e2e-SLOコンプライアンス、エスカレーションチャネル、ステータスWebフック。

14） FinOps： コストと効率

TCO： compute+storage+network egress+licenses/providers+duty。
ユニットエコノミクス：1kリクエストのコスト/1預金トランザクション/1 KYC。
最適化：右サイジング、スポット/プレフィックス割引、キャッシュのhitrate、ログ/トレースのdedup、コールドストレージレベル。
時間の負荷移動：「夜」の窓および安い地域の非重要なバッチ。

15）ダッシュボードとレポート（最小セット）

• リンク間での現在の負荷対定常なスループット。
• サービスおよび地域によるヘッドルーム；24/72時間予報。
• FinOps KPI： $/1kリクエスト、$/デポジット。

• トップボトルネック（p99、飽和、遅延）、DRマージン。

• プロバイダの成功/遅延と制限；ルートの交通の共有。

• アップグレード/インデックス/最適化計画、予想される節約/容量の増加。

16）プロセスと役割

RACI：プラットフォーム（infra/clusters/balancers）、データベース/データ（インデックス、レプリケーション）、サービスコマンド（プロファイリング/キャッシュ）、SRE （SLO、アラート）、Sec/Compliance（暗号/ログ）、財務（予算）。
リズム：毎週の容量レビュー（ロードマップ、予測、リスク）、毎月のFinOpsレポート、四半期ごとのDRテスト。
変更管理：主要なキャンペーン/リリースは、キャパシティ・ゲート（以下のチェックリスト）に移動します。

17）容量ゲート

• ピーク負荷予測と「+x％緊急テール」。
• コアストリーム（支払い/ACC/ログイン）用のヘッドルームが利用可能です。
• クォータはプロバイダに確認されています。代替ルートはアクティブです。
• HPA/KEDAスレッショルドとウォームプールが設定されています。
• キュー/リミットと劣化チェック（プレイブック準備完了）。
• カナリア共有と自動ロールバックが有効になります。
• ダッシュボード/アラート（バーンレート、彩度、p99）がチェックされました。
• DR計画とエスカレーションの連絡先が関連しています。

18）アンチパターン

「CPU <70％-すべてが正常です」：依存関係の制限（DB接続、IOPS、キュー）を無視します。
リンク単位のメトリックなしで「ブラックボックス」を集中化-制限がどこにあるかを理解することは不可能です。
キャッシュ戦略の欠如-リリースミスキルオリジン。
予算のないリトレイ制限ハードコードは、要求の嵐です。
「1つの支払いプロバイダー」は、そのピーク時に失敗のポイントです。
暖かい準備を無視することは、事件の原因としてのコールドスタートです。
定期的なDRテストはありません-計画は必要なときには機能しません。

19）小型費用の見積もり（例）

Service X： Podあたり安定した350 RPS （vCPU=1、 RAM=2 GiB）。目標は5,000 RPS、ヘッドルーム25％です。
必要な電力='5000/0。75=6667 RPS'。
Podov='ceil （6667/350）=20'。ウォームプール15％→さらに3ポッド。
DB： 12k TPSの限界、9k TPSの現在の信用、10のピーク予測。5k TPS→在庫1。5k （14％）。インデックス/シャーディング/レプリカまたはキャッシュが必要で、8に削減されます。5K。
プロバイダーA （KYC）：クォータ120 rps、ピーク95 rps、キャンペーン+40％→133 rps>クォータ→ルーティング70％ A/30％ B。

20）容量計画実装テンプレート

1.e2eパスとボトルネックについて説明します。
2.CUを入力し、各レイヤーの持続スループットを測定します。
3.すべてのリンクで彩度とp99メトリックを設定します。
4.イベント/キャンペーン/リリースカレンダーを生成します。
5.コホート予測とwhat-ifシナリオを構築します。
6.スレッドごとおよびリージョンごとのピンヘッドルーム（エラー予算へのバインディング）。
7.HPA/VPA/KEDA+ウォームプール、リミット/リトレイ/キューを設定します。
8.プロバイダのクォータをチェックし、マルチルートを有効にします。
9.ダッシュボードと毎週のリズムキャパシティレビューを収集します。
10.四半期ごと-DR演習とモデルリビジョン。

21）ボトムライン

容量計画は、CPUの追加ではなく、予測、アーキテクチャ上の制約、コストの管理可能なバンドルです。"e2eパスの各レイヤーに測定された容量があり、ヘッドルームと劣化戦略がSLOとエラー予算に関連している場合、ピーク負荷、キャンペーン、事故は驚くべきことではありません。このアプローチは、インシデントのリスクを低減し、ビジネスメトリクスを安定させ、コストを最適化します。