冗長構成やフェイルオーバーを設計しても、それが本番で本当に効くかは、実際に何かが壊れるまで分かりません。
カオスエンジニアリングは、その「壊れたときに耐えられるか」を、障害を待たずに自分たちから確かめにいく方法です。
想定している読者は、「本番をわざと壊すのは危なくないのか」「何から始めればよいのか」と感じている中堅エンジニアです。
読み終えるころには、実験の組み立て方と、本番に近づけるときの安全策の取り方が分かります。
私も SRE を学んでいる途中なので、Netflix・Google・AWS が公開している一次情報を土台にしています。
カオスエンジニアリングは障害を使った実験
Principles of Chaos Engineering は、カオスエンジニアリングを「本番環境の荒れた状況に耐えられるという確信を築くために、システムに対して実験する分野」と定義しています。
鍵になる言葉は「実験」です。
壊すこと自体が目的なのではなく、仮説を立てて確かめ、システムへの確信を少しずつ積み上げることが目的です。
源流としてよく挙がるのが、Netflix の技術ブログ記事「The Netflix Simian Army」（2011 年 7 月）で紹介された Chaos Monkey です。
Chaos Monkey は本番のインスタンスを無作為に止めるツールで、平日の日中に、エンジニアが待機して見守る中で動かしていたと書かれています。
ねらいは、夜中や休日に本物の障害が起きても、誰も気づかないくらい自動で復旧できる仕組みを先に作っておくことでした。
同じ記事では、AWS のアベイラビリティーゾーン全体の停止を模す Chaos Gorilla や、通信にわざと遅延を入れる Latency Monkey も紹介されています。
Google にも、SRE が本番システムを限界まで追い込み、実際に障害を起こす年次の訓練 DiRT（Disaster and Recovery Testing）があります。
Google の SRE 本の第 33 章によると、目的は想定どおりに反応するかの確認、予想外の弱点の発見、制御できない障害を防ぐための改善の 3 つです。
AWS はシステムだけでなくチームの対応まで確かめる訓練をゲームデーと呼び、障害注入の実験をその一部に位置づけています。
実験は四つの手順で組み立てる
Principles of Chaos Engineering は、実験の進め方を次の 4 つの手順にまとめています。
定常状態を外から測れる数字で決める
最初に、システムが正常に動いているときの状態を、外から測れる出力で決めます。
原則の文書は、システム内部の属性よりも、測定できる出力に注目するよう勧めています。
AWS の解説では、スループット、エラー率、レイテンシのパーセンタイルがその例に挙がっています。
Netflix の論文「Automating chaos experiments in production」では、動画の再生開始に成功した回数を毎秒数える SPS（stream starts per second）を指標にしていました。
外から見た良し悪しを数字で決めるこの作業は、SLI と SLO を決める作業とよく似ています。
仮説を一文で書く
次に、「障害を入れても定常状態は続く」という仮説を立てます。
AWS Well-Architected フレームワークの信頼性の柱は、「{障害}が起きても、{ワークロード}は{緩和策}によって{指標}を保つ」という型を示しています。
例の一つは、EC2 インスタンスが 1 台落ちる場面です。
ロードバランサーが正常なインスタンスだけに振り分け、Auto Scaling が台数を戻すので、サーバー側の 5xx エラーの増加は 0.01% 未満に収まる、という仮説を立てます。
AWS は、障害の種類と、それを吸収するはずの仕組みを仮説の中で名指しするよう求めています。
名指ししておけば、定常状態が崩れたときに、どの仕組みが効かなかったのかを追いやすくなるでしょう。
現実に起きる出来事を入れる
入れる障害には、サーバーの停止、ディスクの故障、ネットワークの切断のように、現実に起きる出来事を選びます。
故障だけでなく、急なトラフィックの増加のような「故障ではない出来事」も対象に含まれます。
どれから試すかは、影響の大きさか起きる頻度で優先度を付けるのが原則です。
AWS は、過去のインシデントの振り返りを、その判断の材料に使うよう勧めています。
差を探して仮説を崩しにいく
最後に、障害を入れた実験群と入れていない対照群を比べ、定常状態に差が出ないかを探します。
原則の文書によれば、定常状態を崩しにくいほど、システムのふるまいへの確信は強まります。
逆に弱点が見つかれば、それは広い範囲で表に出る前に手を打てる改善の目標です。
AWS はこの流れを、改善して再実験し、仮説が成り立つようになったら CI/CD に組み込んで回帰テストとして回し続ける輪として描いています。
爆発半径を絞って本番に近づける
原則の文書は、本番のトラフィックで実験することを強く勧めています。
同時に、爆発半径（実験の影響が及ぶ範囲）を最小にして封じ込めるのは、実験する側の責任だとも書いています。
とはいえ、いきなり本番から始めるわけではありません。
AWS Fault Injection Service（AWS FIS）のドキュメントは、本番で使う前に計画を立て、本番前の環境で実験するよう強く勧めています。
FIS には停止条件という仕組みがあり、CloudWatch アラームで決めたしきい値に達すると実験が止まります。
Well-Architected も、停止条件が実際に作動するかを、まず本番以外の環境で確かめる方法を挙げていました。
本番に持ち込んだ後の絞り方は、先ほどの Netflix の論文が具体的です。
- 実験群と対照群に、同じ大きさの小さなトラフィックを割り当てる（論文の例ではどちらも利用者の 1%）
- 顧客への影響が大きすぎると検知したら、実験を早めに止める
- 実験は平日の 9 時から 17 時だけに走らせる
- 同時に走る実験の合計で、どのリージョンでもトラフィックの 5% を超える影響を出さない
どこまでの影響なら許容できるかは、SLO で決めた目標とエラーバジェットの残りが判断の手がかりになる、と私は理解しています。
実験の前に、運用チームやサポート窓口など関係する人へ、いつ何をするかを伝えておくことも AWS の手順に含まれています。
終わったら、システムを実験前の正常な状態へ確実に戻すところまでが実験です。
つまずきやすい落とし穴
公開資料を読み比べると、避けたい失敗にはいくつか共通の形があります。
一つ目は、壊れると分かっている所で実験することです。
AWS は、失敗すると分かっているなら実験せず、先に直すよう書いています。
カオスエンジニアリングで探したいのは、気づいてはいても理解しきれていない弱点や、存在にすら気づいていない弱点だからです。
二つ目は、内部の数字だけを見て判断することです。
データベースのエラー数は障害の直接の結果を示しますが、AWS は利用者側の失敗リクエストのような顧客への影響の測定で補うよう勧めています。
利用者の代わりに外から API を叩き続ける合成監視を置く方法も挙げられていました。
三つ目は、一度やって終わりにすることです。
原則の文書は、手動の実験は手間がかかって続かないので、自動化して継続的に回すよう求めています。
AWS も、実験をコードとして扱わず、開発サイクルの中で保守しないことを、よくある失敗に数えています。
四つ目は、安全装置のない自作スクリプトで始めることです。
AWS は、状態の把握、ログの出力、ロールバックと停止条件を備えていない自作スクリプトでの実験を勧めていません。
結果の記録も欠かせず、時刻・対象・条件をそろえて残しておかないと、後から傾向を比べられません。
実験で見つかった弱点の直し方には、縮退運転やリトライの設計など別の論点が続くので、ここでは深入りしないでおきます。
最後に
カオスエンジニアリングは、障害を待たずに、自分たちの仮説を本番に近い条件で確かめにいく実験の方法です。
定常状態を測れる数字で決め、仮説を立て、爆発半径を絞って崩しにいくという順番を押さえれば、本番前の環境からでも始められます。
定常状態の指標づくりは SLI と SLO の記事、許容できる影響の考え方はエラーバジェットの記事とつながっているので、あわせて読むと全体像がつかみやすくなります。
まずは自分のシステムで「何が落ちても、どの数字が保たれるべきか」を一文で書くところから試してみてください。
以上です。
コメントを残す