カオスという言葉についてどのような印象をお持ちでしょうか？無秩序でごちゃごちゃした様子をカオスで表現することがありますが、古くはギリシャ神話では万物が発生する以前の秩序なき状態を指していたそうです。同時に万物を生み出す根源ともされており、カオスという言葉はとてもスケールが大きいと感じます。
カオスエンジニアリングとは？
カオスエンジニアリングについては、下記サイトがもっとも有名で、そこでは以下のように定義されています。
「カオスエンジニアリングは、システムが本番環境における不安定な状態に耐える能力へ自信を持つためにシステム上で実験を行う訓練方法です。」
Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production.
カオスエンジニアリングは方法論です。例えば、停電であったり、一部サービスの停止、トラフィックの急増など、不測のイベントがシステムに重大な影響を及ぼさないようにするために行います。
カオスエンジニアリングをどのように行うかご紹介したいと思いますが、その前になぜ今これが注目されているのでしょうか。その理由として、マイクロサービスや分散クラウドアーキテクチャといった複雑なシステムが近年採用されるようになってきたことが挙げられます。このようなITシステムではあるサービスでの障害が相互作用によって別のサービスに波及する場合があり、それを事前に予測することがこれまでより遥かに難しくなっているためです。
ITシステムの障害は企業に大きな損失をもたらしますが、それを防ぐためには難しい課題に立ち向かう必要があります。それがカオスエンジニアリングが求められている背景です。
4つのステップ
カオスエンジニアリングにおいてシステムの脆弱性を明らかにするための検証手順は、以下の4つの手順で行います。
- 通常の動作を示すシステムの測定可能な出力として「定常状態」を定義する
- この定常状態は、対照群および実験群の両方で継続すると仮定する
- サーバのクラッシュ、ハードドライブの誤作動、ネットワーク接続の切断など、現実世界のイベントを反映する変数を導入する
- 対照群と実験群との間の定常状態の違いを調べることによって仮説を反証する
（PRINCIPLES OF CHAOS ENGINEERINGより引用）
ここで重要なことは可観測性です。障害を注入した際にどのような影響があったのか観測して詳しく分析できるようにする必要があります。これによって影響をより深く理解し、効果的な復旧や防止といった対策につなげることができるからです。
5つの原則
カオスエンジニアリングでは以下の原則に沿って行うことが推奨されています。
- 定常状態における振る舞いの仮説を立てる
- 実世界の事象は多様である
- 本番環境で検証を実行する
- 継続的に実行する検証の自動化
- 影響範囲を局所化する
（PRINCIPLES OF CHAOS ENGINEERINGより引用）
なんとなく行うのではなく、より効果的・安全に行うために十分な検討と準備をした上で実践することが重要とされています。なんの準備もなく障害を本番環境に注入して大きな問題を発生させてしまったり、学びにつながる情報が得られなかったではメリットがありません。
ただ、本番環境での実施については議論があるところだと思います。検証環境ではシステム構成やトラフィックパターンなどについて細かな条件まで同じにすることは難しいため場合によっては十分な効果が得られない懸念があります。もちろん、本番環境で実施するリスクを限定するために障害の注入による影響を限定したり、影響度合いに応じて緊急停止する仕組みを用意するなど準備をしておく必要があります。一方で医療や金融などミッションクリティカルな環境で実施することのリスクを無視することはできないため、できる限り本番環境に近づけた検証環境を利用することも選択肢になるはずです。
導入前に必要なこと
ある海外の対談では以下2つが必要と言われていました。
- システム、サービスアーキテクチャの理解。
- 構築・運用・保守チームでの協力関係。
カオスエンジニアリングは理解されていないシステムで実践することはリスクが大きすぎます。ある程度理解が進んでいるシステムに対して行うからこそ観測データの分析や結果に対する考察ができて新たな学びが得られるためです。そのため、成熟しつつあるシステムにこそ効果的といえます。
また、チーム間で同じ使命をもって一緒に協力していくことを共有することが求められます。システムの課題が明らかになった際に誰がこの部分の設計したのかとつい個人攻撃をしてしまいがちですが、個人の責任で片づけるのではなく全体の問題ととらえて前向きな学びの機会ととらえる文化があるからこそカオスエンジニアリングの効果的な実践につながるというのは確かに納得できます。
さいごに
カオスエンジニアリングを実践する企業が増えています。私がはじめてカオスエンジニアリングについて話を聞いた時は、本番環境で実験なんてできるわけないという思い込みから理論上の話と受け止めていました。しかし、同時に本番環境でなければ実際のところはどう動くかわからないということも技術者として感じていました。
本番環境での実験は無視できないリスクですが、十分なコントロール下で行うことができればそのリスクは限定的なものになります。カオスエンジニアリングは損して得取れの非常に論理的なアプローチだと思います。このコラムが管理するシステムの信頼性を向上させる一助になれば幸いです。
著者
CTCテクノロジー株式会社
テクニカルサポート本部
テクニカルサポート第3部
小川 辰夫
2003年CTCテクノロジー株式会社に入社。
ネットワーク系のポストサポートエンジニアとして主にセキュリティー関連製品に携わる。
無線LANに関しては2005年から現在まで複数ベンダーの製品を担当。
