システムデザイン完全ガイド ⑤｜壊れないシステムを作る

[LB 99.99%] → [API 99.9%] → [DB 99.95%]
可用性 = 0.9999 × 0.999 × 0.9995 = 99.84%   ← 一番弱い所より悪くなる

可用性 99% のサーバー 3 台（どれか 1 台生きていれば OK）
可用性 = 1 - (0.01)^3 = 99.9999%

✅ ユーザー体験に直結するもの
   可用性 : 成功レスポンス数 / 全リクエスト数
   レイテンシ: p99 が閾値以内のリクエストの割合
   品質    : 検索結果の適合率、動画の再生開始時間
   鮮度    : データの遅延が N 秒以内である割合

❌ 内部指標だけ（CPU 使用率、メモリ使用量）
   → これらはアラートの原因調査には使うが、SLO にはしない

SLO = 99.9% → エラーバジェット = 0.1%
月間 10 億リクエストなら → 100 万リクエストまで失敗してよい

【使い方】
バジェットが残っている → 新機能を積極的にリリースしてよい（リスクを取る）
バジェットを使い切った → 機能開発を止め、信頼性の改善に専念する

□ ロードバランサ自体      → 複数 AZ、Anycast、DNS フェイルオーバー
□ DB のプライマリ         → 自動フェイルオーバー（Raft or マネージド）
□ キャッシュ              → 落ちても DB で耐えられるか（レート制限で保護）
□ メッセージキュー        → レプリケーション、min.insync.replicas
□ 認証サービス            → キャッシュされたトークンで一定時間は動くか
□ 設定サーバー / 秘密管理  → 起動時のみ依存 or ローカルにフォールバック
□ DNS                     → 複数プロバイダ
□ 証明書                  → 自動更新の失敗が全断を招く（監視必須）
□ デプロイパイプライン    → 壊れると「直せない」状態になる
□ 人間（1 人しか知らない） → ドキュメントと訓練

障害ドメイン（同時に壊れる単位）
  プロセス ⊂ ホスト ⊂ ラック ⊂ AZ（データセンタ）⊂ リージョン ⊂ 地球

全ユーザーを 1 つのシステムで捌く → 障害は全ユーザーに影響
       ↓
ユーザーを 10 個のセルに分け、各セルが独立したフルスタックを持つ
       ↓
1 セルの障害 = 10% のユーザーだけが影響を受ける

8 台のワーカーから 2 台をランダムに選んで各顧客に割り当てる
  → 組み合わせは 8C2 = 28 通り
  → 悪意ある顧客 A が 2 台を殺しても、完全に重なる顧客は 1/28 だけ
  → 他の顧客は少なくとも 1 台が生き残る

スレッドプール・コネクションプールを依存先ごとに分ける
  → 遅い依存先 A がプールを食い潰しても、B への呼び出しは影響を受けない

① 定常状態を定義する（成功率 99.9%、注文数 1000/分）
② 仮説を立てる（「1 台落としても定常状態は維持される」）
③ 実験する（ランダムに 1 台停止、レイテンシ注入、ネットワーク分断）
④ 差分を検証し、修正する

① 指数バックオフ: 100ms → 200ms → 400ms → 800ms
② ジッタ（ランダム化）: sleep(random(0, min(cap, base * 2^attempt)))
   ← これがないと全クライアントが同じタイミングで再送し、波が同期する
③ リトライ回数の上限（3 回程度）
④ 冪等な操作のみリトライ（第 18 章）
⑤ リトライ予算（Retry Budget）: 全リクエストの 10% までしかリトライに使わない
⑥ リトライ可能なエラーだけリトライ
   （冪等性、429/5xx、接続失敗、Retry-After を総合判断）

        失敗率が閾値超え
 [Closed] ──────────────► [Open]
 通常通り                  即座に失敗を返す（下流を呼ばない）
    ▲                         │ 一定時間後
    │  成功                    ▼
    └──────────────────── [Half-Open]
                          少数のリクエストだけ通して様子を見る

❌ 共有スレッドプール 100 本
   サービス A が遅くなる → 100 本全部が A の待機に使われる → B も C も死ぬ

✅ 分離
   A 用 30 本 / B 用 30 本 / C 用 40 本
   → A が死んでも B, C は動き続ける

【実装】
① キューの長さ or レイテンシを監視
② 閾値を超えたら、低優先度のリクエストから 503 で即座に拒否
③ ヘルスチェックと重要な管理系は必ず通す

【優先度の例】
  最優先: 決済完了、ヘルスチェック
  高    : ログイン、商品購入フロー
  中    : 商品閲覧
  低    : 推薦、アナリティクス、プリフェッチ、バッチ

① サーバー 10 台のうち 2 台が高負荷でダウン
② 残り 8 台に負荷が集中（1.25 倍）
③ 8 台のレイテンシが悪化 → タイムアウト増加
④ クライアントがリトライ → さらに負荷が 2〜3 倍に
⑤ 8 台のうち 3 台がヘルスチェックに失敗して LB から外れる
⑥ 残り 5 台に全負荷 → 即死
⑦ 全滅。しかもここで再起動しても、待っていた全リクエストが殺到して再び即死

【正常】負荷 = 処理能力の 60%
   │ 一時的なスパイクやデプロイなどのトリガー
   ▼
【メタスタブル】リトライで負荷が増幅 → キャッシュミス増加 → さらに遅くなる
   → 原因を取り除いても、増幅ループが自己維持する
   → 抜け出すには回復能力を下回るまで負荷を絞り、
     キュー・リトライ・キャッシュを段階的に回復させる

Counter    : 単調増加（総リクエスト数）→ rate() で秒あたりに変換して使う
Gauge      : 上下する値（メモリ使用量、キューの長さ）
Histogram  : 分布（レイテンシ）→ パーセンタイルが計算できる
Summary    : クライアント側で計算済みのパーセンタイル（集約できないので注意）

Trace ID: abc123（1 リクエスト全体で共通）
├─ Span: API Gateway        [0ms ────────────────── 250ms]
   ├─ Span: Auth Service       [5ms ── 15ms]
   ├─ Span: User Service       [20ms ───── 60ms]
   │   └─ Span: PostgreSQL       [25ms ── 55ms]  ← ここが遅い！
   └─ Span: Recommend Service  [65ms ─────────── 240ms]
       └─ Span: Redis            [70ms ─ 75ms]

ERROR: 人間の対応が必要。アラートの対象になりうる
WARN : 異常だが自動回復した（リトライ成功など）
INFO : 業務上の重要イベント（注文作成、ログイン）
DEBUG: 開発時のみ。本番では通常オフ（サンプリングで一部だけ有効化も可）

【Phase 1: Expand（拡張）】新カラムを追加する。旧カラムはそのまま
   ALTER TABLE users ADD COLUMN first_name TEXT, ADD COLUMN last_name TEXT;
   → 旧コードは影響を受けない（NULL 許容で追加する）

【Phase 2: Dual Write（両書き）】新コードをデプロイ。両方に書く
   INSERT/UPDATE で name も first_name/last_name も更新する
   読み取りはまだ name を使う

【Phase 3: Backfill（埋め戻し）】既存データを変換する
   バッチで少しずつ（1000 行ずつ、スロットリングしながら）変換
   → 一括 UPDATE はロックとレプリケーションラグを引き起こすので厳禁

【Phase 4: 読み取り切替】新カラムから読むようにデプロイ。検証期間を置く

【Phase 5: Contract（収縮）】両書きをやめる → 十分な期間を置いて旧カラムを削除
   ALTER TABLE users DROP COLUMN name;

✅ 安全な変更:
   - 任意フィールドの追加
   - 新しいエンドポイントの追加
   - enum の値を追加（クライアントが未知の値を無視できる設計なら）

❌ 破壊的変更:
   - フィールドの削除・改名
   - 型の変更、必須化
   - デフォルト値の変更、意味の変更
   - エラーコードの変更

□ 自動ロールバック（カナリア中のメトリクス悪化を検知）
□ デプロイの段階展開（1 ゾーン → 1 リージョン → 全体）。
  リージョン間に待ち時間を置く
□ フリーズ期間（大型セール前、年末年始はデプロイしない）
□ 設定変更もコードと同じレビュー・段階展開を通す
□ 「壊れた状態でデプロイパイプラインが動かない」状況を作らない（緊急パスの用意）
□ デプロイイベントをメトリクスに重ねて表示（因果の特定が一瞬でできる）

① 現在の実測値を取る（ピーク QPS、1 台あたりの処理能力、リソース使用率）
② 成長率を予測する（前年比、プロモーション、新機能）
③ ピーク倍率を掛ける（平均の 3 倍、セール時は 10 倍）
④ 冗長性を加える（N+2、AZ 障害時に残り 2 AZ で全負荷を捌けるか）
⑤ 余裕率を掛ける（使用率 50〜60% を目標に）
⑥ リードタイムを考慮（GPU や専用ハードは数ヶ月かかることもある）

CPU 使用率     → 汎用的。ただし I/O バウンドなワークロードでは反応しない
QPS / 同時接続 → 直接的で良い
キューの長さ   → 非同期ワーカーの候補指標。
                 古いメッセージの年齢、到着率、処理率、可視性タイムアウトも併用する
レイテンシ     → 遅行指標なので単独では危険（もう手遅れ）

① 検知    : アラート、ユーザー報告、監視ダッシュボード
② 招集    : インシデントコマンダー (IC) を立てる
③ 影響緩和: 原因究明より先に、まず止血する
④ 原因究明: 変更履歴を最初に見る（デプロイ・設定変更・フラグ）
⑤ 復旧    : 段階的にトラフィックを戻す
⑥ 記録    : タイムラインを残す
⑦ ポストモーテム: 再発防止

1. サマリ（何が起きたか、1 段落）
2. 影響（何人のユーザーが、何分間、何ができなかったか。金額換算できれば尚良い）
3. タイムライン（分刻み。検知・エスカレーション・緩和・復旧の各時刻）
4. 根本原因（技術的な連鎖。「なぜ」を 5 回）
5. うまくいったこと / いかなかったこと / 運が良かったこと
6. アクションアイテム（担当者と期限つき。優先度も明記）

□ すべてのアラートに Runbook（対応手順書）がある
□ オンコール担当が明確で、ローテーションが持続可能（燃え尽きない）
□ 過去のポストモーテムが検索でき、読まれている
□ アクションアイテムの完了率が追跡されている
□ 障害訓練（ゲームデー）を定期実施している
□ 新メンバーが 1 週間以内にオンコールに入れる（ドキュメントの質）
□ 「切り戻し」が誰でも 5 分でできる