フォールトインジェクションとゲームデイの原理

なぜ「壊してみる」のが正攻法なのか

分散システムの信頼性を、設計レビューとユニットテストだけで保証することはできません。理由は単純で、本番の障害は 想定の組み合わせ から生まれるからです。1つのコンポーネントの故障率は分かっても、依存先のタイムアウトが切れずスレッドが枯渇し、リトライが負荷を増幅し、フェイルオーバが想定どおり発火しない——こうした 創発的（emergent）な振る舞い は、各部品を個別に見ても予測できません。システムが複雑になるほど、「動くはず」という心象モデルと実際の挙動の乖離は広がります。

カオスエンジニアリング は、この乖離を 実験 で測ります。意図的に故障を注入（フォールトインジェクション）し、システムが本当に想定どおり耐えるかを観測する。重要なのは、これがデバッグでも障害再現でもなく、仮説検証 だという点です。「この依存先が落ちても、サービスのエラー率は変わらないはずだ」という反証可能な仮説を立て、実験でそれを覆そうと試みる。覆らなければ自信が深まり、覆れば本番障害になる前に弱点を発見できます。本記事では、この実験を安全かつ意味あるものにする4つの設計原則——定常状態仮説、実環境、最小爆風半径、自動停止——と、人と手順までを含めて検証するゲームデイの学習ループを原理から解説します。

原則1：定常状態仮説——「正常」を出力で定義する

実験には、何が「正常」かの定義が要ります。ここで素朴に「CPU使用率」や「内部のキュー長」のような システム内部の指標 を正常さの基準にすると、本質を外します。ユーザーから見て大事なのは、内部がどう動いているかではなく、システムが期待どおりの出力を出し続けているか だからです。

カオスエンジニアリングは正常さを 定常状態（steady state） として定義します。これは、システムが正常に機能しているときに観測される 出力指標の安定した分布 です。典型的には、スループット（毎秒の成功リクエスト数）、エラー率、レイテンシのパーセンタイルといった、ユーザー影響に直結する指標を使います。

定常状態の例：
  - 注文確定の成功率が 99.9% 以上
  - p99 レイテンシが 300ms 未満
  - 毎分の正常リクエスト数が 平常帯（移動平均±2σ）の内側

仮説（反証可能な形）：
  「依存先 X を落としても、上記の定常状態は維持される」

この定義の利点は二つあります。第一に、内部がどう壊れていても、出力指標が定常状態を保っているなら ユーザーから見れば耐えている ——フォールトトレランスの本質を正しく捉える。第二に、仮説を 反証可能 にする。実験中に定常状態が崩れれば「仮説は棄却された＝弱点がある」と明確に判定でき、崩れなければ「この故障に対する耐性がある」という証拠が積み上がります。

原則2：実環境で実験する——なぜ本番に近づけるのか

次の原則は、できるだけ本番に近い環境で実験する ことです。直感に反して聞こえますが、根拠があります。システムの実際の振る舞いは、本番特有の条件——実トラフィックの分布、実データのサイズ、本番の構成・スケール、実際の依存関係——に強く依存します。ステージング環境はこれらを近似するだけで、しばしば決定的な差を持ちます。

ステージングでは再現しにくい本番固有の要因：
  - 実トラフィックの量とバースト（合成負荷では出ない相関）
  - 実データの分布（ホットキー、巨大テナント、歪んだ偏り）
  - 本番の構成ドリフト（手動変更、想定外のフラグ状態）
  - サードパーティ依存の実レイテンシとレート制限
  - オートスケールやキャッシュの実際のウォーム状態

ステージングでだけ検証された耐性は、「ステージングは耐える」という限定的な証拠にしかなりません。私たちが本当に知りたいのは「本番が耐えるか」であり、それを最も正確に答えられるのは本番そのものです。だからこそ、後述する最小爆風半径と自動停止という安全装置が 不可欠 になります。本番で実験する許可は、これらの安全装置とセットでのみ正当化されます。

原則3：最小爆風半径——影響を有界化する

本番で実験する以上、万一仮説が棄却された（システムが耐えられなかった）ときの 被害を限定 しなければなりません。これが 爆風半径（blast radius）の最小化 です。実験は最小の影響範囲から始め、自信が深まるにつれて段階的に範囲を広げます。

爆風半径を段階的に広げる：
  1. まず1台のインスタンス、1%のトラフィック、1リクエストに限定して注入
  2. 定常状態が維持されることを確認
  3. 範囲を拡大（数%→1セル→1リージョン……）し、各段で再確認
  4. 異常が出た段で停止し、それ以上広げない

最小爆風半径の思想は、セル型アーキテクチャ（/devops/cell-based-architecture/）が障害を 1/N に封じ込めるのと同じです。違いは、セル型が 本物の障害 を構造で封じ込めるのに対し、カオス実験は 意図的な障害 を運用で封じ込める点。実験の被害が全ユーザーに波及すれば、それは実験ではなく自作自演のインシデントです。注入の対象を絞る（特定のインスタンス・特定のテナント・特定の割合のトラフィック）ことで、最悪でも影響を「制御された小さな一部」に留めます。

ここで注入できる故障の種類を整理します。リソース・ネットワーク・状態・依存の各層で、本番に起きうる現実の障害を模します。

とりわけレイテンシ注入は重要です。完全な停止よりも 遅い依存先 のほうが厄介で、タイムアウトが緩いとスレッドやコネクションが詰まり、リトライが負荷を増幅して、サーキットブレーカ（/devops/circuit-breaker-bulkhead/）が効かなければカスケード障害に至ります。レイテンシ注入は、こうした「遅延からの連鎖崩壊」を本番障害になる前にあぶり出します。

原則4：自動停止——実験を即座に止める

第4の原則は、実験を即座に・自動で止められること です。実験中に定常状態が想定外に崩れたら、人間の判断を待たずに注入を停止し、システムを元へ戻す。これは英語で abort conditions や stop conditions、あるいは「ビッグレッドボタン」と呼ばれます。

自動停止の論理：
  while 実験中:
      現在の定常状態指標を観測
      if 指標が許容しきい値を逸脱:   # 例: エラー率が定常帯を超過
          注入を即時停止
          注入前の状態へロールバック
          アラート発報・実験を中止

自動停止が必須である理由は、人間の検知・判断・操作には遅延がある からです。エラー率が跳ね上がってから人がダッシュボードに気づき、原因を判断し、停止操作をするまでの数分間に、爆風半径は実験の想定を超えて広がりえます。停止条件を 機械可読なしきい値 として事前に定義し、自動で発火させることで、被害を実験の制御下に保ちます。停止条件は定常状態仮説の裏返し——「これを超えたら仮説は棄却で、即停止」という線——として設計します。

ゲームデイ：人と手順まで含めた系を検証する

ここまでは主に システムの技術的耐性 を検証する話でした。ゲームデイ（GameDay） は対象をさらに広げ、人・プロセス・ツールまで含めた社会技術システム全体 を検証する計画的な演習です。あらかじめ日時を決め、関係者を集め、現実的な障害シナリオを注入して、検知から復旧までの一連の対応を実地で動かします。

カオス実験が「システムは耐えるか」を問うのに対し、ゲームデイが問うのはもっと広い問いです。

ゲームデイが検証する「系全体」：
  - 監視は障害を検知できるか（アラートは鳴るか、ノイズに埋もれないか）
  - 正しい人にエスカレーションが届くか（オンコールの経路は機能するか）
  - ランブックは最新で、実際に役立つか
  - 対応者は手順を理解し、ツールを操作できるか
  - 検知から復旧までの時間（MTTD/MTTR）は許容範囲か

ここで測るべきは技術指標だけではありません。検知までの時間（MTTD） と 復旧までの時間（MTTR） を実測し、想定SLOやエラーバジェット（/devops/error-budget-math/）の前提と突き合わせます。多くの組織で本番障害の対応を遅らせるのは、システムの欠陥そのものより、古いランブック、届かないアラート、不慣れな手順 といった人・プロセス側のギャップです。ゲームデイはこれらを、本物のインシデントの圧力下ではなく、制御された演習の中で安全に発見します。

学習ループ：仮説と現実の差分を還元する

カオスエンジニアリングもゲームデイも、本質は 一度きりのテストではなく継続的な学習ループ です。仮説を立て、実験で検証し、結果から学び、システムと心象モデルの両方を更新して、次の仮説へ進みます。

学習ループ：
  仮説 → 故障注入 → 観測（定常状態は保たれたか）
     ├─ 保たれた  : 耐性の証拠を得る。爆風半径を広げ次へ
     └─ 崩れた    : 弱点を発見。修正し、修正の有効性を再実験で検証
                    → ポストモーテムで根本原因と学びを共有

仮説が棄却された——システムが耐えられなかった——ときこそ、最大の価値が生まれます。それは本番インシデントになる前に発見された 無料の教訓 だからです。発見した弱点は、非難なきポストモーテム（/devops/incident-postmortem/）と同じ枠組みで分析し、根本原因と再発防止を学習へ還します。実インシデントのポストモーテムと違うのは、痛みを伴わずに 同じ学びが得られる点です。修正後は同じ故障を再注入し、修正が本当に効いたことを 回帰的に 確認する——これが実験を一過性で終わらせないための要です。

まとめ

• カオスエンジニアリングはデバッグや障害再現ではなく、反証可能な仮説の実験的検証 である。複雑系の創発的な振る舞いはレビューでは予測できないため、故障を注入して実際の耐性を測る。
• 正常さは内部指標ではなく 定常状態——スループット・エラー率・レイテンシなどユーザー影響に直結する出力指標の分布——で定義し、できればビジネス指標を選ぶ。これにより仮説が反証可能になる。
• 証拠の妥当性は 環境の現実性に比例する ため本番に近づける。ただしそれは 最小爆風半径（小さく始めて段階的に拡大）と 自動停止（逸脱検知で即時ロールバック）という安全装置とセットでのみ正当化される。両者が揃って被害が二重に有界化される。
• ゲームデイ はシステムだけでなく、検知・エスカレーション・ランブック・対応者まで含めた 社会技術システム全体 を検証する演習。MTTD/MTTRを実測し、人・プロセス側のギャップを圧力のない環境で発見する。
• いずれも一過性のテストではなく 継続的な学習ループ。仮説の棄却は本番前に得た無料の教訓であり、ポストモーテムで学びを還元し、修正後の再注入で回帰確認する閉ループを回し続けることに価値がある。