1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ymaeda_it

本番を壊さずにインフラ障害をシミュレーション — FaultRay の LTS カスケードエンジン解説

1
Last updated at Posted at 2026-04-10

なぜ 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 情報 / 引用

@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

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?