カオスエンジニアリングで本当にカオスにならないための進め方をグラレコで解説

「カオスエンジニアリング」という言葉を聞いたことがある方は「EC2 インスタンスをランダムに止めて、テストするやつでしょ ?」と考えたかもしれません。これには少し誤解があります。

確かに、初期には仮想マシンをランダムに停止していたようで、OSS の “Chaos Monkey“ もそのような機能を保持していました。しかし、その後の様々な改善や学びを得て、現在ではそのような方法は主流ではなく、きちんと影響範囲 (”Blast Radius : 爆発半径“と呼ばれます) をコントロールした上で実験を行うようになっています。Netflix のエンジニアがリードして記述した、「カオスエンジニアリングの原則」でも、”カオスエンジニアリングは、分散システムにおいてシステムが不安定な状態に耐えることの出来る環境を構築するための検証の規律です“ と書かれているように、制御下においてシステムの挙動を実験するプラクティスです。

まず最初に「定常状態 (Steady State) 」と呼ばれる、システムが通常の動作をしていることを示す指標を定義します。この時、定常状態には測定可能な具体的な数値を定義する必要がありますが、CPU やメモリの使用率のような単純なシステムのメトリクスではなく、「システム全体としてサービスを正しく提供できているか」を計測できる指標を定義しましょう。

例えば EC サイトであれば、“一定期間中のカートに商品が入った数” などビジネス的な KPI に関連する値が良いでしょう。ここで重要なのは、お客様にサービスが正しく提供されていることを確認でき、また、問題発生時にお客様へ影響が出てしまっていることを確認できる値であることです。例えば “CPU の使用率が 90 % 以下である“ という指標は、CPU の使用率が一時的に高くなっていてもユーザーに直接的な影響が発生していないことは十分に考えられますし、逆に CPU 使用率には関係のない理由により、ユーザに意図しない影響を与えてしまっていても気づけない可能性もあります。

定常状態が定義できたら、次は実験対象の事象が発生した時にもその定常状態が継続できる、という仮説を立てます。即ち「何らかのトラブルが発生しても正常にサービス提供を継続できる」ことを説明します。この仮説は関係者とよく協議することをお勧めします。

この仮説を立てる中で考慮不足や問題が見つかることもあります。その際は実験に進まず、先に問題を解決していきましょう。これもシステムの改善への貢献になるはずです。

仮説を構築したら、実験を行います。

ここで言う「変数」とはサーバーのクラッシュやソフトウェア的な障害など、現実世界に発生するイベントを反映したものです。サービスを構成するシステムを対照群と実験群にわけ、実験群にのみ変数 (Chaos) を注入します。この際、変数の導入作業を自動化して人的ミスを極力排除したり、致命的な問題が発生したときにすぐに実験を停止できるような仕組みを用意し、実験自体を安全に実施できるようにすることが重要です。後述する、AWS Fault Injection Simulator はこのような実験を簡単に実施できるようにお客様を支援するマネージドサービスです。

実験結果に対して、対照群と実験群の間で定常状態に差異があるかを確認し、構築した仮説の反証を試みます。

ここで、仮説が反証される挙動が発見された場合、それを「学び」としその問題点が現実にお客様に影響を与える前に対応できるようにシステムの改善を検討します。反証されないということはシステムが仮説通り安定した挙動を示したということなので、システムの可用性や信頼性に対する自信を深めることができます。一般にシステムの定常状態を崩しずらいほど、安定したシステムということができます。また、仮説が完全に反証されなくても、運用手順の見直しなど改善できるポイントが見つかることもあります。

このプロセスを繰り返し、システムの理解を深めながら改善を繰り返していくことによって、様々な問題が起こり得る本番環境においても安定した運用が可能であるという自信を構築していく方法が、カオスエンジニアリングです。

AWS Fault Injection Simulator (AWS FIS) は AWS が提供するフルマネージドの障害注入サービスです。AWS の各種サービスと統合されており、Agent のインストールなどをせずに実験を開始することが可能です。事前に定義されたアクションに基づいた実験だけでなく、AWS Systems Manager (AWS SSM) の Run Command とも統合されており、障害注入用に事前に定義した Document を実行することで、さまざまな実験が可能になっています。

もう一つ、AWS FIS の強力な機能として、「停止条件」という機能があります。これは実験を安全に実行するためのガードレールとして利用できる機能で、事前に設定した Amazon CloudWatch アラームにより、サービスが定常状態を逸脱した場合などに自動的に実験を停止できます。これにより、実験中に想定外の問題が発生した際に、ユーザーへの影響を最低限に抑えて実験を停止することが可能になります。

AWS FIS のより詳しい利用方法については ドキュメント をご確認ください。