キャパシティと信頼性設計｜クラウドインフラ

🎓 レベル：発展　|　重要度：B（推奨）

📎 前提：SREとは・SLI/SLO/エラーバジェット　|　関連：責任共有モデルとリージョン/AZ・スケーリングと自己修復

要点（BLUF）

信頼性設計の前提は「障害は必ず起きる」。壊れない事を目指すのでなく、壊れても影響が出ない/小さいように冗長化・縮退で備える。
単一障害点（SPOF）の排除が出発点。どこか1つの故障で全体が止まる箇所を見つけて二重化する。
キャパシティ計画で余裕（ヘッドルーム）を持ち、カオステストで「本当に冗長か」を平時に確かめる。希望的観測でなく実証で。

概念 ── 壊れる前提で設計する

完璧な部品は存在せず、サーバもネットワークもいつか壊れます。だから信頼性は「壊れないこと」でなく「壊れても続くこと」で作ります。鍵は3つ——冗長化（予備を持つ）、フェイルオーバー（自動で予備へ）、縮退（一部を諦めて全体を守る）。

flowchart TB
    spof["単一障害点（SPOF）を洗い出す"] --> redun["冗長化（複数AZ・複数レプリカ）"]
    redun --> failover["フェイルオーバー（故障を検知し予備へ自動切替）"]
    failover --> degrade["縮退運転（重要機能だけ残す）"]

仕組み ── 冗長化・フェイルオーバー・縮退

冗長化（redundancy）：同じ役割を複数用意し、1つ落ちても残りで継続。前提は「独立に壊れる」こと——だから物理的に分けた複数AZ（責任共有モデルとリージョン/AZ）に配置する。同じ電源・同じラックに固めた「冗長」は、まとめて落ちて意味がない。

フェイルオーバー（failover）：故障をヘルスチェックで検知し、自動で予備へ切り替える。K8s の probe／ReplicaSet（スケーリングと自己修復）や LB のヘルスチェック（Service・Ingress）がこれを担う。

縮退運転（graceful degradation）：全機能を維持できないとき、重要機能だけ残して軽い機能を切る。例：レコメンドが落ちても商品購入は通す。全部落とすより、コア機能を守る。

flowchart LR
    user["ユーザー"] --> lb["ロードバランサ（ヘルスチェック）"]
    lb -->|"健全"| a["AZ-1 のレプリカ群"]
    lb -.->|"AZ-1 障害時に切替"| b["AZ-2 のレプリカ群"]

仕組み ── キャパシティとカオステスト

キャパシティ計画：ピーク需要＋成長＋障害時の肩代わりを見込んで余裕を持つ。「N+1 / N+2」——1〜2台落ちても捌ける台数を確保。オートスケール（スケーリングと自己修復）と組むが、急増には限界があるので下限の余裕も要る。

カオステスト（カオスエンジニアリング）：平時にわざと壊して、冗長やフェイルオーバーが本当に効くかを検証する。「冗長にしたつもり」が机上の空論でないと確かめる唯一の方法。本番に近い環境で、影響範囲を絞って計画的に行う。

なぜ壊れる前提なのか

100%は不可能だから：部品はいつか壊れる（SREとは・SLI/SLO/エラーバジェットの前提）。壊れない努力より、壊れても続く設計に投資する方が費用対効果が高い。
冗長は実証しないと幻だから：設定上は冗長でも、切替手順のバグ・容量不足で実際には切り替わらないことが多い。カオステストで平時に炙り出す。
過剰冗長はコストだから：冗長は金もデータ同期の遅延も増やす（コストとスケーリングの考え方）。SLOに見合う水準で。重要度で配分する。

⚠️ よくある誤解・落とし穴

「冗長化したから安心」→ 同一AZ・同一電源に固めると相関故障でまとめて落ちる。独立性（複数AZ）を担保。
「フェイルオーバーを試したことがない」→ いざという時に切り替わらない定番事故。定期的に切替訓練（カオス/DR演習）。
「キャパシティに余裕ゼロで運用」→ 1台落ちた瞬間に残りが過負荷で連鎖ダウン（カスケード障害）。N+1 以上の余裕を。
「全障害に完全冗長」→ コスト過剰。SLO（SREとは・SLI/SLO/エラーバジェット）に見合う冗長度に絞る。
「ステートフルな部分の冗長を後回し」→ DB の冗長・バックアップ・フェイルオーバーは最難関かつ最重要。状態の冗長を軽視しない。

対応ラボ

なし（設計トピック）。自己修復・フェイルオーバーの実挙動はスケーリングと自己修復（probe・HPA）、マルチAZ配置はモジュール化と環境分離のIaCで体験できる。