キャパシティプランニングと概算見積もり
翻訳についての注記: 本ドキュメントは英語原文
01-foundations/10-capacity-planning.mdを日本語に翻訳したものです。コードブロックおよびMermaidダイアグラムは原文のまま維持しています。
TL;DR
見積もりは、この本のすべてのパターンに先立つステップです: 暗記した少数の定数(レイテンシの梯子、ノード単位のスループットクラス、1日の秒数)、仮定を明示した10のべき乗の算術、そして2つの待ち行列の数学 — リトルの法則(並行数 = スループット × レイテンシ)と稼働率曲線(飽和に近づくとレイテンシが爆発する。だから実用上の天井は約70〜80%であり、余裕は無駄ではなく機能なのです)。これらがあれば、設計を5分でサイズでき、悪い設計を2分で殺せ、リトライストーム・満杯のコネクションプール・90%でのオートスケールがすべて同じ結末を迎える理由を数学的に説明できます。キャパシティプランニングは同じ数学をプロセスとして回すことです: 先行指標から予測し、明示的な余裕ポリシーを持ち、オープンループの負荷生成器で飽和の先までテストする — クローズドループのテストとcoordinated omissionは、まさにテストしたい崩壊を隠すからです。
暗記すべき数字
桁の定数、2026年版。精度は要点ではありません — 2つの設計が100倍違うと知ることが要点です。
レイテンシの梯子
| 操作 | 時間 | 覚え方 |
|---|---|---|
| L1キャッシュ参照 | 約1 ns | |
| メインメモリ参照 | 約100 ns | RAMはL1の100倍 |
| 1KB圧縮(snappy級) | 約2 µs | |
| NVMe SSDランダム読み取り | 約20–100 µs | SSDはRAMの約1000倍 |
| メモリから1MB順次読み取り | 約10–50 µs | |
| NVMeから1MB順次読み取り | 約200 µs–1 ms | |
| データセンター/AZ内往復 | 約0.5 ms | RPCの床 |
| クロスAZ往復 | 約1–2 ms | |
| HDDシーク | 約2–10 ms | ディスクは機械 |
| US東西海岸往復 | 約60–70 ms | |
| US ↔ 欧州 / US ↔ アジア往復 | 約80–150+ ms | 物理。マルチリージョン参照 |
表から直接落ちてくる3つの結論: メモリはディスクに10³で勝つ(キャッシングが機能する理由)。クロスリージョン1回はDC内100回より高い(お喋りなクロスリージョンプロトコルが死ぬ理由)。N回の逐次RPCにファンアウトするリクエストは、誰かが仕事をする前にN × 0.5msのレイテンシ床を持つ(並列ファンアウトとヘッジングの理由)。
ノード単位のスループットクラス
| コンポーネント(よく調整された1ノード) | 桁 |
|---|---|
| Postgres/MySQL、単純なインデックス付きクエリ | 約5–50K QPS |
| Redis / インメモリKV | 約100K–1M ops/s |
| Kafka、ブローカーあたり | 数百MB/s |
| ステートレスAPIサービス(JSON、軽い処理) | ノードあたり約1–10K RPS |
| NIC | 10–100 Gbps (1.25–12.5 GB/s) |
| TCP+TLSハンドシェイク1回 | 最初のバイトの前に1–3 RTT |
カレンダーの算術
- 1日 ≈ 86,400秒 ≈ 10⁵秒(最頻出の定数)
- 1か月 ≈ 260万秒。1年 ≈ 3,150万秒 ≈ π × 10⁷秒
- 100万リクエスト/日 ≈ 平均12 RPS。10億/日 ≈ 12K RPS
- 日次トラフィックの法則: X百万DAUが各Y回行動するなら、平均RPS ≈
X × Y × 10(10⁶/10⁵ = 10だから)
方法
- 何をサイズしているか明確に — 読みか書きか、平均かピークか、定常かバーストか。見積もりの議論の大半は、別のものをサイズしている2人です。
- 4つのメーターに分解: リクエストレート、ストレージ、帯域、メモリ(キャッシュ)。
- 容赦なく丸める — 10のべき乗、有効数字1桁。単位を明示的に追跡する — 古典的なミスは静かなKB/MB、bit/byteの取り違えです(ネットワークはビット、ストレージはバイト。8倍の差が多くの設計を沈めました)。
- 仮定を声に出す(「DAUあたり1日1投稿、投稿あたり10閲覧、画像の中央値200KBと仮定」)。仮定こそレビューの対象で、算術は機械的です。
- 別の方向から正気を確認 — 答えがPostgres 400シャードや0.3台のサーバーを意味するなら、仮定のどれかに物語があります。
実例: 写真共有サービス
1億DAU。各自1日0.5枚投稿、50枚閲覧。写真の中央値200KB+サムネイル20KB。メタデータは写真あたり1KB。保持5年。
Writes: 100M × 0.5 / 10⁵ s ≈ 500 uploads/s avg → ×3 peak ≈ 1,500/s
Reads: 100M × 50 / 10⁵ s ≈ 50K views/s avg → ×3 peak ≈ 150K/s
read:write ≈ 100:1 → design is read-path-dominated (cache + CDN problem)
Storage: 50M photos/day × 220KB ≈ 11 TB/day ≈ 4 PB/year ≈ 20 PB over 5y
→ object storage + lifecycle tiers, not a database ([Object Storage](../03-storage-engines/08-object-storage.md))
Metadata: 50M/day × 1KB ≈ 50 GB/day ≈ 18 TB/year → sharded DB territory in year one
Bandwidth (egress, peak): 150K views/s × 200KB ≈ 30 GB/s ≈ 240 Gbps
→ CDN is not optional; origin sees only misses ([CDN](../06-scaling/04-cdn-architecture.md))
Cache: 80/20 rule — 20% of today's content serves 80% of reads.
Hot set ≈ 20% × (last ~7 days × 11TB) ≈ 15 TB → a small cluster of
memory-heavy cache nodes, not "cache everything"10行で、アーキテクチャの背骨が決まりました: CDNを前置したオブジェクトストレージ、シャーディングされたメタデータストア、約15TBのキャッシュ層、まともなキュー1本で吸収できる書き込みパス。それが見積もりの目的です — この本の残りのパターンは、ここで到達した結論の実装詳細なのです。
リトルの法則: ただひとつの公式
L = λ × W — システム内の項目数 = 到着率 × 各項目の滞在時間。
並べ替えれば、並行に関するほぼすべてをサイズできます:
- サーバーの並行数: 5,000 RPS × 0.2秒レイテンシ = 実行中リクエスト1,000。ノードあたり200なら余裕ゼロで5ノード — 8台用意する理由は下記の曲線です。
- コネクションプール: 5ms/クエリのDBに2,000 QPSを打つサービスは2,000 × 0.005 = ビジー接続10本。プール20はバーストをカバーし、プール500はインシデント中にデータベースを溶かす設定ミスです(コネクション管理)。
- キュー深度/コンシューマのサイズ: 1件50msの処理で10K msg/sを捌くには500以上の並行コンシューマが必要。遅れ始めたときのバックログは(到着 − 処理)レートで成長し、リトルの法則はあらゆるバックログをユーザーに見える遅延へ変換します: 100万件 ÷ 10K/s = 100秒のラグ(バックプレッシャー)。
- 逆向きには診断としても動きます: 並行数が膨らんだのにスループットが伸びていないなら、レイテンシが伸びた — 下流の何かが遅く、スレッドプールは症状です。
稼働率曲線: 余裕が存在する理由
ランダム到着のサービスでは、待ち時間はおよそ:
W ≈ S / (1 − ρ) S = service time, ρ = utilization
ρ: 50% 70% 80% 90% 95% 99%
W/S: 2× 3.3× 5× 10× 20× 100×レイテンシ対稼働率はホッケースティックです: 70%と90%の差は「20%の効率化」ではなく3倍悪いレイテンシであり、分散(実トラフィックは数学の最良ケースよりバースト的。重い裾の処理時間はさらに悪化させる)が崖を左へ動かします。すべてが従います:
- 70〜80%の天井は俗説ではありません — 曲線の膝です。それより熱く運転すると、平均CPUが怖く見える前にp99が爆発します。
- オートスケールは膝のかなり下で発動しなければなりません(そしてスケールには数分かかる — その間、曲線はあなたに90→99%の区間を実演しています)。
- リトライストームに公式が付きました: ρ→1のまさにそのとき、リトライはλを足し、(1−ρ)をゼロへ割り込ませます — メタステーブル障害の機構が分数ひとつに。
- 余裕はプロダクト機能です: フェイルオーバー容量(静的安定性 — 2リージョンのペアは各≤50%で動く)、デプロイのサージ、「インシデント」と「些事」の差は、すべて(1−ρ)の中に住んでいます。
- 稼働率の数学はまた、1本の大きなキューがノード別キューに勝つ理由(プールされた容量が分散を吸収する)であり、騒がしいテナントの隔離(セル、シャッフルシャーディング)が他の全員のρを守る話である理由でもあります。
ピーク係数
ピークに合わせて用意し、平均に対して支払う(FinOps):
| パターン | ピーク ÷ 平均 |
|---|---|
| グローバルコンシューマの日周 | 1.5–2.5× |
| 単一リージョンの営業時間 | 3–5× |
| メディア/ソーシャルのイベント | 5–20×のスパイク |
| フラッシュセール、チケット販売 | 10–100× — 事前ウォーム、入口でキュー、シェディング |
| 同期したクライアント(毎時0分のcron、TTLの群れ) | 自業自得 — ジッターを足す |
自分に嘘をつかない負荷テスト
ほとんどのベンチマーク数字を無効にする2つの誤り:
- クローズドループの生成器は崩壊を隠します。 クローズドループのツール(N人の仮想ユーザーが、応答を待ってから次を送る)は、システムが遅くなると自動的に自分も遅くなります — 負荷が被害者に適応し、待ち行列を決して見ない行儀のよいシステムを測定してしまう。実際のユーザーはオープンループです: 到着はあなたのレイテンシに関心がありません。真の曲線を見るには、オープンループ・一定到着率の生成器(wrk2型、k6のarrival rate)でテストすること。
- Coordinated omission。 サーバーの停止中に生成器も止まると、最も苦しんだはずのリクエストを送り損ね、生存者のレイテンシだけを報告します。10秒のサーバーストールがp99から完全に消えうる。補正するツール(HdrHistogramベース: wrk2、補正付きk6)を使い、正気を確認すること: 最大レイテンシはパーセンタイルの裾に見えているべきで、不審に不在であってはなりません。
本物のテスト計画が含むもの: 飽和を超えてランプして実際の膝を見つける(キャパシティプランニングが必要とする数字)。膝で保持して劣化モードを観察する(優雅なシェディングか崩壊か)。それから負荷を落として回復を検証する — スパイク後も劣化したままのシステムは、本番が見つけるメタステーブル領域を持っています。本番形状のデータ(ホットキー、巨大テナント、冷えたキャッシュ)でテストし、リアリズムにはシャドー/本番トラフィックのリプレイを(マイグレーションのシャドーイングと同じ機構です)。
プロセスとしてのキャパシティプランニング
見積もりは設計をサイズし、プランニングはサイズを保ちます:
- リソースのグラフではなく先行指標から予測する。 容量をビジネスメトリクス(DAU、テナント、注文/日)に、実測した単価で結びつける — 「DAU 100万ごとに+ピーク120 RPS = +2ノード+0.4TBキャッシュ」 — そうすれば計画はCPUの後ではなく、営業と同時に動きます。
- 余裕ポリシーを文書化する: 例「全ティアは実測ピークで≤60%。AZ1つの喪失とデプロイサージを同時に生き延びる。セル1つは常時避難可能」。そして稼働率ではなく残り余裕にアラートを — 「現在の成長で膝まで何週間」が、まだ平穏なうちに調達とシャーディングのプロジェクトを起動するメトリクスです。
- リードタイムを尊重する。 オートスケールは分を扱います。クォータ引き上げ、新シャード(リシャーディングはマイグレーション)、GPU容量、新リージョンは数週間〜数か月。計画の仕事は、その時計を早く始めることです。
- 膝を四半期ごとに再検証する — コードの変更は膝を動かします。去年の負荷テストは去年のシステムの記述です。
チートシート
86,400 s/day ≈ 10⁵ 1M/day ≈ 12 RPS 1B/day ≈ 12K RPS
RAM 100ns · NVMe 50µs · DC RTT 0.5ms · region RTT 1ms · continent 80ms
concurrency = RPS × latency (Little) pool ≈ λ×W + headroom
W ≈ S/(1−ρ): 80% → 5×, 90% → 10× ceiling ≈ 70–80%
peak = 2–5× average (events: 10×+) provision peak, pay average
open-loop load tests; correct coordinated omission; test past the knee + recovery参考文献
- Latency Numbers Every Programmer Should Know — Dean/Norvigの表。最新化されたインタラクティブ版
- The SRE Workbook, ch. 12: Non-Abstract Large System Design — Googleが教える見積もり
- How NOT to Measure Latency — Gil Tene; coordinated omissionの正典トーク
- Open Versus Closed: A Cautionary Tale — NSDI '06; 生成器のループモデルがすべてを変える理由
- Systems Performance (Brendan Gregg) — USEメソッドと、この全体の下にある測定の規律
- wrk2 / k6 arrival-rate executors — オープンループ・omission補正済みの負荷生成