ストーリー

カオスエンジニアリングとは

カオスエンジニアリングは、本番環境で制御された実験を行い、システムの弱点を事前に発見する手法です。

仮説: 「Payment Serviceが障害を起こしても、注文システムは
       タイムアウトしてエラーを返し、他のサービスには影響しない」

実験: Payment Serviceを意図的に停止

結果A（良い）: サーキットブレーカーが作動し、注文は適切なエラーで応答
結果B（悪い）: Order Serviceがハングし、API Gateway全体に影響が伝搬
  → 対策が必要！

カオスエンジニアリングの原則

1. 定常状態の仮説を立てる

// 実験前に「正常な状態」を定義
interface SteadyStateHypothesis {
  metric: string;
  expectedRange: { min: number; max: number };
  description: string;
}

const steadyState: SteadyStateHypothesis[] = [
  { metric: 'error_rate', expectedRange: { min: 0, max: 0.5 }, description: 'エラー率 0.5%以下' },
  { metric: 'p99_latency_ms', expectedRange: { min: 0, max: 500 }, description: 'P99レイテンシ 500ms以下' },
  { metric: 'orders_per_minute', expectedRange: { min: 30, max: 60 }, description: '注文数 30-60件/分' },
];

2. 実世界のイベントを反映する変数を導入

// 障害注入の種類
enum ChaosExperiment {
  ServiceDown = 'サービスの停止',
  NetworkLatency = 'ネットワーク遅延の注入',
  NetworkPartition = 'ネットワーク分断',
  DiskFull = 'ディスク容量の枯渇',
  CPUStress = 'CPU負荷の増加',
  MemoryLeak = 'メモリリークのシミュレーション',
  DependencyFailure = '外部依存の障害',
  ClockSkew = '時計のずれ',
}

3. 本番環境で実験する

本番でこそ、真のシステムの振る舞いがわかります（ただし段階的に）。

4. 継続的に自動実行する

一度きりではなく、定期的に実行して回帰テストとします。

カオス実験の計画テンプレート

interface ChaosExperimentPlan {
  name: string;
  hypothesis: string;
  steadyState: SteadyStateHypothesis[];
  experiment: {
    target: string;
    action: string;
    duration: string;
    blastRadius: string;  // 影響範囲
  };
  rollback: {
    trigger: string;      // ロールバック条件
    procedure: string;    // ロールバック手順
  };
  schedule: string;
}

const experiment: ChaosExperimentPlan = {
  name: 'Payment Service Failure',
  hypothesis: 'Payment Serviceが停止しても、Order Serviceはタイムアウトして適切なエラーを返し、他の機能は影響を受けない',
  steadyState: [
    { metric: 'order_error_rate', expectedRange: { min: 0, max: 5 }, description: '注文エラー率 5%以下' },
    { metric: 'api_gateway_p99', expectedRange: { min: 0, max: 1000 }, description: 'API Gateway P99 1s以下' },
    { metric: 'notification_success_rate', expectedRange: { min: 95, max: 100 }, description: '通知成功率 95%以上' },
  ],
  experiment: {
    target: 'payment-service',
    action: 'Pod の 50% を強制停止',
    duration: '5分間',
    blastRadius: '決済を伴う注文のみ（全体の40%）',
  },
  rollback: {
    trigger: 'API Gateway全体のエラー率 > 10% or P99 > 5秒',
    procedure: 'Payment Service の Pod を即座に復旧（kubectl rollout undo）',
  },
  schedule: '毎月第2水曜日 14:00-14:30（低トラフィック帯）',
};

主要なカオスエンジニアリングツール

段階的な導入

Level 0: 開発環境でのカオス実験
  │  リスクなし、学習目的
  ▼
Level 1: ステージング環境でのカオス実験
  │  本番に近い環境でテスト
  ▼
Level 2: 本番環境での制限付きカオス実験
  │  低トラフィック帯、限定的な影響範囲
  ▼
Level 3: 本番環境での定常的なカオス実験
     自動化、CI/CDパイプラインに組み込み

まとめ

チェックリスト

• カオスエンジニアリングの目的と原則を説明できる
• カオス実験の計画を作成できる
• 主要なカオスエンジニアリングツールを把握した
• 段階的な導入アプローチを理解した

次のステップへ

次は「ポストモーテムと継続的改善」を学びます。障害から学び、チームを成長させる方法を見ていきましょう。

推定読了時間: 30分