なぜ Chaos Engineering は本番を触るのか

Gremlin・Steadybit・AWS FIS に代表される Chaos Engineering ツールは、実際のサーバーにネットワーク遅延やプロセス Kill を仕込むことで障害耐性を検証する。「本番環境で意図的に壊す」という逆説的アプローチは、Netflix がゼロ年代後半に普及させた。

しかし、EU DORA (Digital Operational Resilience Act, 2022/2554) が全面施行された今、金融機関・保険会社・決済サービス事業者にとってこの手法は難題だ。本番に手を入れれば顧客への影響を制御しきれない。かといって、障害耐性を証明できなければ規制当局への説明責任を果たせない。

FaultRay はこのジレンマに対して別解を提示する。

「実障害を注入しなくても、依存グラフをトラバースするだけでカスケードを再現できる」

FaultRay の基本アーキテクチャ

インフラ定義 (YAML / Terraform plan)
        ↓
  依存グラフ G = (C, E, dep, w, τ, cb)
        ↓
  ┌────────────────────────────┐
  │  LTS カスケードエンジン     │  ← メモリ内で全実行
  │  Availability Model (5L)   │
  └────────────────────────────┘
        ↓
  シミュレーション結果
  (blast radius / severity / 可用性上限)

コンポーネント C、依存エッジ E、依存タイプ dep（requires / optional / async）、重み w、タイムアウト τ、Circuit Breaker 閾値 cb をパラメータとして持つグラフを構築し、そのグラフ上でのみ演算する。ネットワーク疎通ゼロ、本番プロセスへの接触ゼロ。

コア技術 ① LTS カスケードエンジン

形式仕様

カスケード伝播を Labeled Transition System (LTS) として定義する。

M = (S, s₀, Act, →, F)

状態 S は 4-tuple:
  H: Component → HealthStatus  (health map)
  L: Component → float          (latency map, ms)
  T: float                      (elapsed time, seconds)
  V: set[Component]             (visited set — 単調増加)

8 つの遷移規則が fault injection、依存タイプ別伝播、Circuit Breaker トリップ、タイムアウトカスケード、終了を支配する。

ASCII 図解：カスケード伝播の様子

初期状態                     故障注入後
─────────────────────────    ──────────────────────────────────
  [API GW] 🟢                  [API GW] 🟢
      |                             |
  [App Server] 🟢              [App Server] 🔴 ← DOWN
      |                          ↗↘
  [DB] 🟢                  [Cache] 🟡    [Queue] 🟡
      |                    DEGRADED      DEGRADED
  [Cache] 🟢
      |
  [Queue] 🟢


  BFS で V に追加済み: {DB, App Server, Cache, Queue}
  H[App Server] = DOWN → requires エッジ先を DOWN に伝播
  H[Cache]      = DEGRADED (optional エッジ → 緩和)
  H[Queue]      = DEGRADED (async エッジ → さらに緩和)

証明済みのプロパティ

プロパティ	内容
Termination	visited set V が単調増加かつ \|C\| で有界 → 必ず停止
O(\|V\|+\|E\|)	各コンポーネントは最大 1 回訪問、各エッジは最大 1 回検査
Monotonicity	一度 DOWN になったコンポーネントは回復しない（1 run 内）
Bounded blast radius	影響範囲はフォールト起点からの逆可達集合に限定

循環グラフに対しては depth limit D_max=20 で強制終了を保証。

Circuit Breaker と依存タイプの扱い

現実のインフラでは、すべての依存関係が「落ちたら即死」ではない。FaultRay は 3 種の依存タイプを区別する。

依存タイプ	親コンポーネントへの影響
`requires`	子が DOWN → 親も DOWN（強依存）
`optional`	子が DOWN → 親は DEGRADED（機能低下）
`async`	子が DOWN → 親は DEGRADED（非同期、遅延劣化）

また、Circuit Breaker が設定されているエッジでは、しきい値を超えた時点でカスケードの伝播がそのエッジで止まる。「CB が有効なら実際どこまで落ちるか」を事前検証できるのが、in-memory シミュレーションの強みだ。

3 つのシミュレーションモード

engine = CascadeEngine(graph)

# モード 1: 単一コンポーネント故障 (Rules 1-5)
chain = engine.simulate_fault(Fault("primary_db", FaultType.FAILURE))

# モード 2: レイテンシカスケード (Rules 6-7)
chain = engine.simulate_latency_cascade("primary_db", latency_multiplier=10.0)

# モード 3: トラフィックスパイク (Rule 1 per-component)
chain = engine.simulate_traffic_spike(multiplier=3.0)

コア技術 ② N-layer min-composition 可用性モデル

"SLA 99.99% の嘘"

「うちのシステムは 99.99% のアップタイムを保証している」という主張を聞いたとき、実際に達成可能かどうか計算したことがあるだろうか。

従来の Reliability Block Diagram (RBD) は可用性を直列積で合成する。

A_sys = ∏ A_i    (独立性を仮定)

この式では、コンポーネントが互いに独立して故障すると仮定する。単一のサービスが独立したサーバー1台で動いていた時代ならそれで十分だった。

クラウドインフラはこの仮定を破る。2021 年 10 月の Meta BGP 障害を振り返ろう。BGP 設定ミスひとつで、DNS・CDN・バックエンド API が同時に落ちた。AWS us-east-1 障害（2021 年 12 月）でも、ネットワーク・ストレージ・コンピュートが連動して劣化した。各レイヤーを独立として掛け合わせた数字は、この現実を反映しない。

FaultRay は代わりに min-composition を採用する。

A_sys = min(A_L1, A_L2, A_L3, A_L4, A_L5)

相関した障害モードを持つレイヤーでは、最弱リンクが全体の上限を決める。99.99% を保証したいなら、全 5 レイヤーがそれを上回らなければならない。

5 レイヤーの意味

Layer	計測対象	ボトルネックの例
L1 Software	デプロイ停止時間・設定ドリフト・ヒューマンエラー	月 2 回デプロイ × 5 分 = 99.98%
L2 Hardware	MTBF / MTTR × 冗長化 × フェイルオーバー時間	DB failover 30 秒で 99.994%
L3 Theoretical	パケットロス・GC pause・カーネルスケジューリングジッタ	到達不能な理論上限
L4 Operational	インシデント検知時間 × オンコール人数 × 対応速度	チーム 2 人・MTTD 5 分 → 99.95%
L5 External SLA	∏(外部依存の SLA)	AWS 99.99% × Cloudflare 99.99% × Stripe 99.99% = 99.97%

例: 「SLA 99.99% を約束したい」と言う構成が L4 (Operational) で 99.95% にキャップされていれば、FaultRay はその矛盾を検出して报告する。

18 インシデントのバックテスト

公開ポストモーテムから 18 件の実世界クラウド障害（2011〜2024: AWS、GCP、Azure、Meta、Cloudflare、CrowdStrike など）を再現し、LTS エンジンの精度を検証した。

指標	値
Precision (blast radius)	1.000
Recall (blast radius)	1.000
F1 Score	1.000
Severity Accuracy	0.819
平均ダウンタイム MAE	3,159 min

注意点を正直に: blast radius（どのコンポーネントが影響を受けるか）は完全再現できているが、ダウンタイム時間の推定誤差は大きい（MAE 約 2 日）。また、「障害の結果を知ってからトポロジーを構築した」という事後的検証であり、予測精度の保証ではない。Precision/Recall が 1.000 なのは、この事後構築バイアスの影響を受けている。

実際に試してみる

インストールとデモ

pip install faultray
faultray demo

Building demo infrastructure...
╭────────────────────────────────────────────────────╮
│ Metric           │ Value                           │
│ Components       │ 9                               │
│ Dependencies     │ 12                              │
│ Resilience Score │ 50.0/100                        │
╰────────────────────────────────────────────────────╯

Running chaos simulation...

╭────────── FaultRay Chaos Simulation Report ──────────╮
│ Resilience Score: 50/100                             │
│ Scenarios tested: 255                                │
│ Critical: 21  Warning: 84  Passed: 150               │
╰──────────────────────────────────────────────────────╯

独自インフラを定義してシミュレーション

# infra.yaml
components:
  - id: api-gateway
    type: load_balancer
    replicas: 2
  - id: trading-engine
    type: app_server
    replicas: 3
  - id: market-data
    type: database
    replicas: 1   # ← FaultRay が SPOF として検出する

dependencies:
  - source: api-gateway
    target: trading-engine
    type: requires
  - source: trading-engine
    target: market-data
    type: requires

faultray load infra.yaml
faultray simulate --html report.html

Terraform CI/CD ゲートとして使う

terraform show -json plan.out > plan.json
faultray tf-check plan.json --fail-on-regression --min-score 60

# .github/workflows/terraform.yml
- name: Resilience Gate
  uses: mattyopon/faultray@v1
  with:
    plan-file: plan.json
    min-score: 60
    fail-on-regression: true

性能特性

50 コンポーネントトポロジーを 10ms 未満で処理（Apple M1）
O(|V|+|E|) の線形計算量 — 数百コンポーネントでもスケール
ソースファイル 441 本、テスト 29,640 件（CI パス済み）

正直な限界

これは研究プロトタイプであり、コンプライアンスツールではない。

DORA・FISC・SOC 2 などの規制監査の証跡として FaultRay の出力を使ってはならない。独立した法務・技術レビューが必要。
バックテストはすべて事後的構築（障害の結果を知ってから）。前向き予測精度は未検証。
ダウンタイム時間の推定精度は低い（MAE 約 3,000 分）。「何が落ちるか」はわかるが「何分停止するか」の推定は信頼性が低い。
物理障害（ストレージ腐食・自然災害）や外部 DDoS 攻撃のフル再現は対象外。

OSS 情報 / 引用

GitHub: https://github.com/mattyopon/faultray
PyPI: https://pypi.org/project/faultray/
ライセンス: Apache 2.0（2026-04-08 に BSL 1.1 から移行）
論文: Maeda, Y. (2026). FaultRay: In-Memory Infrastructure Resilience Simulation. Zenodo. DOI: 10.5281/zenodo.19139911
特許: US Provisional Patent No. 64/010,200（2026-03-19 出願）
学会: ISSRE 2026 Fast Abstract 投稿予定

@misc{maeda2026faultray,
  author    = {Maeda, Yutaro},
  title     = {FaultRay: In-Memory Infrastructure Resilience Simulation},
  year      = {2026},
  doi       = {10.5281/zenodo.19139911},
  publisher = {Zenodo}
}

まとめ

観点	従来の Chaos Engineering	FaultRay
本番リスク	Medium〜High	ゼロ
形式的証明	なし	LTS 証明付き
可用性モデル	直列積（独立性仮定）	min-composition（相関考慮）
セットアップ	エージェント per ホスト	`pip install` のみ
研究プロトタイプ	—	Yes（コンプライアンスツールではない）

本番を触らずに「次の障害でどこが連鎖的に落ちるか」を事前に見える化したい SRE・インフラエンジニアのフィードバックをお待ちしています。Issue / Star はこちら → https://github.com/mattyopon/faultray