カオスエンジニアリング
Chaos Engineering ・ かおすえんじにありんぐ
本番相当の環境に意図的に障害を注入し、定常状態が保たれるかを実験で確かめて弱点を先に見つける手法。
✦ 30秒で試す — 航海わざと本番のサーバーを壊して、事故を減らす会社がある決済が「止まる」のと「極端に遅くなる」の、被害が広いのは？予想してみる概要
カオスエンジニアリングは、本番相当の環境に意図的に障害を注入し、「システムは想定どおり耐えられるか」を実験で確かめる手法です。サーバを突然落とす、ネットワークに遅延を差し込む、依存サービスからの応答をエラーに差し替える — こうした「わざと壊す」操作を計画的に行い、システムが自動で回復するか、利用者への影響が想定の範囲に収まるかを観察します。
「壊すこと」自体が目的ではありません。目的は、障害が起きたときの挙動を本番の事故の前に知り、弱点を平時のうちに直しておくことです。分散システムでは構成要素の一部が落ちることは避けられない以上、「落ちない」ことを祈るのではなく「落ちても大丈夫」を実験で確かめる — この発想の転換がカオスエンジニアリングの核心です。防災訓練を、建物ではなくソフトウェアのシステムに対して行うもの、と言い換えられます。
なぜ生まれたか
起源は 2010年前後の Netflix です。同社は 2008年にデータベースの破損で数日間 DVD の発送が止まる障害を経験し、自社のデータセンターから AWS への移行を進めました。クラウドでは仮想サーバが予告なく落ちることが日常です。テスト環境でどれだけ検証しても、本番の規模・トラフィック・構成の複雑さは再現できず、「テストは通ったのに本番で想定外の壊れ方をする」ことが避けられません。そこで Netflix は発想を逆転させ、本番環境で営業時間中に仮想サーバをランダムに強制終了するツール「Chaos Monkey」を動かし始めました（2012年にオープンソース化）。サーバがいつ落ちてもおかしくない状況を常態化させれば、エンジニアは最初から「1台落ちても平気な設計」を選ばざるを得なくなるからです。
背景にはマイクロサービス化の進行もあります。サービスが数十〜数百の部品に分かれ、部品間の依存が網の目になると、「どこか1つの遅延が連鎖して全体を止める」ような障害は、個々の部品のテストでは決して見つかりません。壊れ方は部品の中ではなく、部品と部品のあいだ — タイムアウトの長さ、リトライの重なり、依存の張り方 — から生まれるからです。全体を対象に、実際に壊して観察するしかない。この認識が Chaos Monkey を、原則をもった手法へと育てました。2010年代半ばには Netflix のチームが「カオスエンジニアリングの原則」を公開し、単なる破壊行為と一線を画す方法論として定着しています。
詳細
仮説 → 実験 → 検証のサイクル
カオスエンジニアリングは科学実験の型に従います。出発点は「定常状態」の定義です。リクエストの成功率やレイテンシなど、システムが健全なときのメトリクスの姿を数値で押さえます。内部の CPU 使用率のような値ではなく、利用者から見た振る舞いを選ぶのが要点です。次に「サーバを1台落としても、成功率は 99.9% を下回らないはずだ」のような反証できる仮説を立て、障害を注入する実験を行い、定常状態が保たれたかを監視で確かめます。仮説どおりなら耐障害性への信頼が1つ増え、崩れたなら本番の事故の前に弱点が見つかったことになります。直して再実験する — このループを回し続けるのが実践の姿です。
故障はどう広がるか — 見つけたいのは経路
実験で見つかる弱点の多くは、1つの部品の故障が依存の網をたどって上流へ広がる経路です。特に怖いのは停止より遅延です。止まったサービスはすぐにエラーを返すので呼び出し元も素早く失敗できますが、遅くなったサービスをタイムアウトなしで呼ぶと、呼び出し元のスレッドや接続が応答待ちのまま埋まっていきます。埋まった呼び出し元は、遅いサービスを使わない要求まで処理できなくなり、その呼び出し元を呼ぶ側でも同じことが起きる。こうして詰まりが入口まで運ばれ、全面的な障害になります。逆に、呼び出しにタイムアウトと代替（おすすめが出せなければ人気商品を出す、など）を入れておけば、被害はその手前で止まります。サーキットブレーカーやグレースフルデグラデーションは、この広がりを止めるための部品です。
下の部品で確かめてください。サービスの箱を押すと障害を注入でき、タイムアウトのない経路（朱の破線）をたどって失敗が上流へ染まっていきます。エラー率が SLO を超えると実験は自動で緊急停止します。経路の中ほどの ⏱ を押して守りを入れ、同じ障害をもう一度注入すると、広がりがどこで止まるかが変わります。
仮説:「どれか1つのサービスが壊れても、エラー率は SLO の 5% 以内に収まる」。サービスの箱を押して障害を注入し、仮説が保たれるか確かめてください。
爆発半径の制御
本番で障害を起こすと聞くと無謀に思えますが、実践の要は「爆発半径（blast radius）」の制御にあります。最初は開発環境やごく一部の利用者・トラフィックだけに影響が及ぶ最小の構成で実験し、確信が得られるにつれて対象を広げていきます。カナリアリリースがリリースの影響範囲を絞るのと同じ発想で、実験の影響範囲を絞るのです。部品で「実験の対象」を 2% にすると、朱の広がり（弱点の経路）ははっきり見えるのに、エラー率は SLO の内側に収まります。弱点を見つけるのに、全員を巻き込む必要はありません。
加えて、定常状態からの逸脱が閾値を超えたら実験を即座に中止して元に戻す「緊急停止」を必ず用意します。実験そのものが重大な障害に発展したら本末転倒で、被害を限定できない実験はカオスエンジニアリングではなくただの破壊です。注入する障害の種類は段階的に広げます。単一サーバの停止に始まり、ネットワークの遅延やパケットの損失、依存サービスのエラー応答、CPU・メモリの枯渇、さらにはリージョン全体の喪失まで。Netflix はリージョンの障害を模擬する Chaos Kong まで整備し、実際に AWS のリージョンで大きな障害が起きたとき（2015年）に、トラフィックを別のリージョンへ退避して乗り切った実績で手法の価値を示しました。
ツールとゲームデー
代表的なツールには、元祖の Chaos Monkey のほか、Kubernetes 上で Pod の強制終了やネットワーク障害を宣言的に注入する Chaos Mesh や LitmusChaos、商用サービスの Gremlin、AWS のマネージドサービスである AWS Fault Injection Service などがあります。Kubernetes のように「落ちたら作り直す」自己修復を前提とした基盤は、カオス実験と特に相性のよい土壌です。
ツールによる自動実験と並ぶ重要な実践が「ゲームデー」です。チームが集まり、時間を区切って計画的に障害のシナリオを実行し、システムの挙動だけでなく人間側の対応 — アラートは適切に飛ぶか、手順書は使えるか、インシデント対応の役割分担は機能するか — を訓練します。カオスエンジニアリングが鍛えるのはシステムの耐障害性だけではなく、組織の対応能力でもあるのです。ゲームデーで見つかった課題はポストモーテムと同じ形式で振り返り、改善につなげます。
実務での位置づけ
導入の前提は、可観測性が確保されていることです。障害を注入しても、システムの反応を観測できなければ実験になりません。また、既知の弱点が放置されたままなら、実験するまでもなく先に直すべきです。カオスエンジニアリングは「たぶん大丈夫だと思っているが確かめていない」領域を検証する手段であり、SRE の文脈では、SLO を守れる自信を平時に積み上げる投資として位置づけられます。テストが「仕様どおり動くこと」の確認だとすれば、カオスエンジニアリングは「仕様の外の事態でも壊滅しないこと」の確認 — 両者は補い合う関係にあります。
試問
ネットショップのサービスが依存の網でつながっています。利用者の要求はゲートウェイから商品・カート・購入へ入り、その先の在庫・決済・おすすめを呼びます。サービスの箱を押すと障害（遅くする・止める）を注入でき、呼び出しの矢印の中ほどにある ⏱ を押すと、その呼び出しにタイムアウトと代替（守り）が入ります。エラー率が SLO の 5% を超えると、実験は自動で止まります。
仮説:「どれか1つのサービスが壊れても、エラー率は SLO の 5% 以内に収まる」。サービスの箱を押して障害を注入し、仮説が保たれるか確かめてください。