カオスエンジニアリングとは？障害注入実験の原則と実践手順を解説

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

カオスエンジニアリングとは、分散システムの耐障害性を検証するために、本番環境または本番に近い環境で計画的に障害を注入する実験手法です。障害が発生する前に弱点を発見し、システムの信頼性を向上させることを目的とします。

この手法はNetflixが2010年頃からAWSへの移行に伴い開発した「Chaos Monkey」が起源です。Casey Rosenthal、Nora Jonesらが2017年に「Chaos Engineering」を出版し、原則と方法論を体系化しました。Netflixの経験を基に策定された「Principles of Chaos Engineering」が、現在の業界標準となっています。

コンサルティングの現場では、クラウドネイティブなシステムの信頼性向上や、DR体制の実効性検証においてカオスエンジニアリングの導入が注目されています。

:::box-memo Casey Rosenthal、Nora Jonesらが体系化した「Principles of Chaos Engineering」では、定常状態の仮説構築、実世界イベントの導入、本番環境での実験、自動化による継続的実行の4原則が定義されています。 :::

構成要素

カオスエンジニアリングは以下の原則と実験カテゴリで構成されます。

4つの原則

原則	内容
定常状態の仮説構築	正常時のシステム挙動を定量的に定義する
実世界イベントの導入	サーバー停止、ネットワーク遅延など現実的な障害を注入
本番環境での実験	本番と同等の条件で実験し、真の挙動を確認する
自動化と継続的実行	実験を自動化し、定期的に繰り返す

障害注入のカテゴリ

• インフラ障害: サーバー停止、ディスク障害、リージョン障害
• ネットワーク障害: レイテンシー増大、パケットロス、DNS障害
• アプリケーション障害: 依存サービスの応答遅延、エラー率の増加
• リソース枯渇: CPU飽和、メモリ枯渇、ディスク容量不足

実践的な使い方

ステップ1: 定常状態の定義

実験前にシステムの正常な状態を定量的に定義します。レスポンスタイム、エラー率、スループットなどのメトリクスを基準値として記録し、実験中の比較対象とします。

ステップ2: 仮説の構築

「サービスAが停止しても、サーキットブレーカーによりシステム全体の応答時間は10%以内の増加に収まる」など、具体的な仮説を立てます。

ステップ3: 小規模な実験から開始

最初はステージング環境で、影響範囲の小さい障害から実験を始めます。単一インスタンスの停止やネットワーク遅延の注入など、制御可能な範囲で実施します。

ステップ4: ブラストラジアス（影響範囲）の管理

実験の影響範囲を制限し、安全に中止できる仕組みを用意します。自動ロールバック条件を定義し、予期せぬ影響が検出された場合は即座に実験を停止します。

ステップ5: 結果の分析と改善

実験結果を分析し、発見された弱点に対する改善策を実装します。改善後に再度実験を実施し、耐障害性が向上したことを検証します。

活用場面

マイクロサービスの耐障害性検証では、依存サービスの停止や応答遅延を注入し、サーキットブレーカーやフォールバック機構が正しく動作するかを検証します。

DR体制の実効性確認では、リージョン障害をシミュレートし、フェイルオーバーの自動化が想定通りに機能するかを定期的に検証します。

大規模イベント前の負荷耐性検証では、トラフィック増大とインフラ障害を組み合わせた実験により、ピーク時の耐障害性を事前に確認します。

注意点

:::box-warning 本番環境でのカオス実験は、組織の承認と適切なガバナンスの下で実施してください。ブラストラジアス（影響範囲）の制御と自動停止条件の整備なしに本番実験を行うことは、計画的な障害注入ではなく単なるインシデントの誘発です。 :::

段階を飛ばさない

いきなり本番環境での大規模実験を実施しないでください。ステージング環境での検証、本番環境での小規模実験、本番での段階的拡大という順序を厳守してください。

モニタリング基盤の不備

オブザーバビリティが不十分な環境でカオス実験を行うと、実験の影響を正確に観測できません。ログ、メトリクス、トレースの基盤が整備されていることが実験の前提条件です。

まとめ

カオスエンジニアリングは、計画的な障害注入によりシステムの弱点を事前に発見する手法です。Netflixが確立した原則に従い、定常状態の仮説構築と影響範囲の管理を徹底した上で、段階的に実験を拡大していくことが安全かつ効果的な導入の鍵です。