カオスエンジニアリングとは何か?
カオスエンジニアリングとは、システムに意図的に障害を注入し、実際の停止を引き起こす前に弱点を発見するための、規律ある実践です。
分散システムは驚くような形で障害を起こし、テストされるまで自分のレジリエンスを理解できることはめったにありません。カオスエンジニアリングは、制御された実験の中で意図的にそれをテストするため、最悪のタイミングでの実際のインシデント中ではなく、自分の条件でギャップを見つけられます。
中核となる考え方
カオスエンジニアリングは、レジリエンスを実験的に検証すべきものとして扱います。システムが故障したノードや遅い依存関係に耐えると仮定するのではなく、意図的にその状態を引き起こし、システムが対処できるかを観察します。そこで見つかる意外な事実こそが、事前に修正できる弱点です。
実験の実施
カオス実験は、定常状態の挙動に関する仮説から始まります - 「1つのインスタンスが停止しても、ユーザーはエラーを見ない」。次に障害を注入し、仮説が成り立つかを観察し、あらゆる逸脱から学びます。これはシステムのレジリエンスに適用された科学的手法です。
一般的な障害の注入
- インスタンスやコンテナをランダムに終了させる。
- ネットワークのレイテンシを追加したり、パケットを破棄したりする。
- CPU、メモリ、ディスクを枯渇させる。
- 依存関係を遅くしたり、利用不能にしたりする。
影響範囲と安全性
責任あるカオスエンジニアリングは影響範囲を制限します。小さく始め、制御された環境やごく一部のトラフィックで行い、常に中止スイッチを用意します。目的は学習であり、実際の停止を引き起こすことではないため、実験は安全に失敗するようスコープが設定されます。
なぜ意図的に壊すのか
意図的に障害を発生させることで、復旧メカニズムへの本物の自信が生まれ、対応スキルが鈍らないように保たれます。フェイルオーバー、リトライ、ランブックが実際に機能することを検証し、実際のインシデント中にセーフティネットが正しく接続されていなかったと気づくような事態を防ぎます。
重要なポイント
- カオスエンジニアリングは、制御された障害を注入して、問題化する前に弱点を見つけます。
- 実験は定常状態に関する仮説から始まり、それをテストします。
- 影響範囲を制限し、中止スイッチを用意する - 目的は学習であり、停止を起こすことではありません。
関連ガイド
What Is a Runbook?A runbook is a documented procedure for an operational task or incident. Learn what a runbook is, what makes…
What Is Time to Restore Service?Time to restore service measures how quickly a team recovers from a failure. Learn what it is, what shortens…
What Is Mean Time to Recovery (MTTR)?Mean time to recovery is the average time to restore service after a failure. Learn what MTTR is, its related…
What Is Site Reliability Engineering (SRE)?Site reliability engineering applies software engineering to operations. Learn what SRE is, how it differs fr…