カオスエンジニアリング

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

カオスエンジニアリング は、本番に近い環境でわざと障害を起こし、システムがその障害に耐えられるかを実験で確かめる 実践です。Netflix が有名な「Chaos Monkey」（本番のインスタンスをランダムに落とすツール）で広めました。

発想の転換が肝です。分散システム（/architecture/microservices/）は複雑すぎて、「どこがどう壊れると何が起きるか」を机上で完全には読めません。そこで 「いつか必ず起きる障害」を、こちらが主導権を持って・安全な状況で先に起こし、システムの本当の反応を観測する。「落ちないこと」を祈るのではなく、「落ちても大丈夫」を確かめる わけです。

4つの原則

カオスエンジニアリングの実験は、次の流れで設計します（principlesofchaos.org が示す枠組み）。

1. 定常状態を定義する：「正常」を 計測可能な指標 で表す。例：注文成功率、レイテンシ、スループット。CPU 等の内部値より ユーザー体験を表す指標（/devops/sre-slo/ の SLI）が望ましい。
2. 仮説を立てる：「この障害を入れても、定常状態は維持されるはず」と予想する。
3. 現実に起こりうる障害を注入する：サーバ停止、ネットワーク遅延、依存サービスの応答不能など、実際に起きうる事象 を再現する。
4. 仮説を検証する：定常状態が崩れたか観測する。崩れたら そこが弱点。学びを設計や対応手順に反映する。

ポイントは「システムを反証しにいく」姿勢です。仮説が崩れた（＝弱点が見つかった）ときこそ、本番障害になる前に直せる最大の収穫になります。

注入する障害の例

「現実に起こりうること」を再現するのが原則です。代表的なものを挙げます。

• リソース系：CPU・メモリ・ディスクを枯渇させる。
• ネットワーク系：遅延（レイテンシ）注入、パケットロス、特定サービスへの通信遮断。
• インスタンス系：仮想マシンやコンテナ、Pod を突然停止させる。
• 依存先の異常：DB や外部 API が エラーを返す／遅くなる 状況を模す。

これらを通じて「再試行は効くか」「タイムアウトは適切か」「フォールバックは動くか」「監視は気づけるか」を一度に試せます。サービスメッシュ（/devops/service-mesh/）を使うと、遅延やエラーの注入をアプリ改変なしで行えます。

進め方：小さく安全に始める

いきなり本番で大暴れさせるのは禁物です。爆発半径（blast radius）を最小から広げていく のが鉄則です。

段階	環境	爆発半径	狙い
1	ステージング	最小	実験設計と安全装置の検証
2	本番（ごく一部）	1インスタンス等に限定	現実の挙動を低リスクで観測
3	本番（徐々に拡大）	段階的に増やす	実運用規模での耐性確認

各段階で 「異常を検知したら即時に実験を中止し、元に戻す」アボート条件 を必ず先に決めます。定常状態の指標が閾値を割ったら自動で停止する、という安全弁です。

前提条件：先に整えるもの

カオスエンジニアリングは、それ単体では成立しません。先に揃えるべき土台があります。

• オブザーバビリティ：障害を入れた影響を 観測できなければ意味がありません。メトリクス・ログ・トレースが整っていることが前提（/devops/observability/）。
• すぐ戻せる仕組み：実験を即中止し、健全な状態へ戻せること。
• 障害対応の体制：万一実験が想定外に波及したときに対応できること。

まとめ

• カオスエンジニアリングは 意図的な障害注入でシステムの耐性を実験的に検証・改善 する手法。
• 定常状態の定義 → 仮説 → 現実的な障害の注入 → 検証 のループを回す。
• 目的は破壊ではなく、本番が暴れる前に未知の弱点を見つける こと。
• 爆発半径を絞り・即中止できる安全装置・観測基盤 を前提に、小さく始めて広げる。