カオスエンジニアリング

概要

カオスエンジニアリングは、本番相当の環境に意図的に障害を注入し、「システムは想定どおり耐えられるか」を実験で確かめる手法です。サーバを突然落とす、ネットワークに遅延を差し込む、依存サービスからのレスポンスをエラーに差し替える — こうした「わざと壊す」操作を計画的に行い、システムが自動復旧するか、ユーザー影響が想定範囲に収まるかを観察します。

「壊すこと」自体が目的ではありません。目的は、障害が起きたときの挙動を本番事故の前に知り、弱点を平時のうちに直しておくことです。分散システムでは構成要素の一部が落ちることは避けられない以上、「落ちない」ことを祈るのではなく「落ちても大丈夫」を実験で証明する — この発想の転換がカオスエンジニアリングの核心です。防災訓練を、建物ではなくソフトウェアシステムに対して行うもの、と言い換えられます。

なぜ生まれたか

起源は2010年前後の Netflix です。同社が自社データセンターから AWS へ移行した際、クラウドでは仮想サーバが予告なく落ちることが日常であると気づきました。テスト環境でどれだけ検証しても、本番の規模・トラフィック・構成の複雑さは再現できず、「テストは通ったのに本番で想定外の壊れ方をする」ことが避けられません。そこで Netflix は発想を逆転させ、本番環境で営業時間中に仮想サーバをランダムに強制終了するツール「Chaos Monkey」を動かし始めました。サーバがいつ落ちてもおかしくない状況を常態化させれば、エンジニアは最初から「1台落ちても平気な設計」を選ばざるを得なくなるからです。

背景にはマイクロサービス化の進行もあります。サービスが数十〜数百の部品に分かれ、部品間の依存が網の目になると、「どこか1つの遅延が連鎖して全体を止める」ような創発的な障害は、個々の部品のテストでは決して見つかりません。全体を対象に、実際に壊して観察するしかない — この認識が、Chaos Monkey を「カオスエンジニアリング」という原則ある学問的手法へと育てました。2010年代半ばには Netflix のチームが「カオスエンジニアリングの原則」を公開し、単なる破壊行為と一線を画す方法論として定着しています。

詳細

仮説→実験→検証のサイクル

カオスエンジニアリングは科学実験の型に従います。出発点は「定常状態」の定義です。リクエスト成功率やレイテンシなど、システムが健全なときのメトリクスの姿を数値で押さえます。次に「サーバを1台落としても、成功率は99.9%を下回らないはずだ」のような反証可能な仮説を立て、障害を注入する実験を行い、定常状態が保たれたかをモニタリングで検証します。仮説どおりなら耐障害性への信頼が1つ増え、崩れたなら本番事故の前に弱点が見つかったことになります。修正して再実験する — このループを回し続けるのが実践の姿です。

爆発半径の制御

本番で障害を起こすと聞くと無謀に思えますが、実践の要は「爆発半径（blast radius）」の制御にあります。最初は開発環境やごく一部のユーザーだけに影響が及ぶ最小構成で実験し、確信が得られるにつれて対象を広げていきます。カナリアリリースがリリースの影響範囲を絞るのと同じ発想で、実験の影響範囲を絞るのです。加えて、定常状態からの逸脱が閾値を超えたら実験を即座に中止して元に戻す「緊急停止ボタン」を必ず用意します。実験そのものが重大障害に発展したら本末転倒であり、被害を限定できない実験はカオスエンジニアリングではなくただの破壊です。

注入する障害の種類は段階的に広げます。単一サーバの停止に始まり、ネットワークの遅延やパケットロス、依存サービスのエラー応答、CPU・メモリの枯渇、さらにはリージョン全体の喪失まで。Netflix はリージョン障害を模擬する Chaos Kong まで整備し、実際の AWS リージョン障害の際にトラフィックを別リージョンへ退避して乗り切った実績で手法の価値を示しました。

ツールとゲームデー

代表的なツールには、元祖 Chaos Monkey のほか、Kubernetes 上で Pod の強制終了やネットワーク障害を宣言的に注入する Chaos Mesh や LitmusChaos、商用サービスの Gremlin、AWS のマネージドサービスである AWS Fault Injection Service などがあります。Kubernetes のように「落ちたら再作成する」自己修復を前提としたプラットフォームは、カオス実験と特に相性が良い土壌です。

また、ツールによる自動実験と並ぶ重要な実践が「ゲームデー」です。チームが集まり、時間を区切って計画的に障害シナリオを実行し、システムの挙動だけでなく人間側の対応 — アラートは適切に飛ぶか、手順書は使えるか、インシデント対応の役割分担は機能するか — を訓練します。カオスエンジニアリングが鍛えるのはシステムの耐障害性だけではなく、組織の対応能力でもあるのです。ゲームデーで見つかった課題はポストモーテムと同じ形式で振り返り、改善につなげます。

実務での位置づけ

導入の前提条件として、オブザーバビリティが確保されていることが挙げられます。障害を注入しても、システムの反応を観測できなければ実験になりません。また、既知の弱点が放置されたままなら、実験するまでもなく先に直すべきです。カオスエンジニアリングは「たぶん大丈夫だと思っているが証明されていない」領域を検証する手段であり、SRE の文脈では、SLO を守れる自信を平時に積み上げる投資として位置づけられます。テストが「仕様どおり動くこと」の確認だとすれば、カオスエンジニアリングは「仕様外の事態でも壊滅しないこと」の確認 — 両者は補完関係にあります。