カオスエンジニアリングのプロセス
カオスエンジニアリングは大きく下記のプロセスで実践します。
- 定常状態を定義し、測定可能な状態にする
- 仮説を立てる
- 実験を計画する
- 実験を通して仮説を確認する
1. 定常状態を定義し、測定可能な状態にする
システムにとっての正常な状態を表す「定常状態」がどのような状態であるのかをシステムに関わるすべての関係者内で合意をとります。例えば、動画配信サービスであれば、1秒あたりのストリーミングされる動画数などになるかもしれません。オークションサイトであれば、入札完了までの時間が10ms以内にできたリクエストの割合といった指標になるかもしれません。
定常状態の定義には、唯一の解はなく、自分たちが提供するシステムのワークロードの種類によって異なります。自分のシステムにとっての定常状態とはいったい何なのかを関係者と話し合うことで、本当にコアとなる機能は何か、それがどのような状態を維持できていればよいのかについて関係者全員の共通の認識を持つことができます。これにより、システムが目指すべき方向性を再認識でき、開発機能の優先順位付けや障害対応の優先度付けなどに活かすことができます。
またこのプロセスでは、上記の活動を通して定義したシステムの定常状態を測定可能な状態にすることも求められます。
せっかく決めた定常状態があっても、システムの状態を示す指標を測定できなければ、実験の結果を適切に評価できません。また実験の結果、なんらか想定外の事象が見つかったとしても、どこが原因であったかが分からなければ、改善を行えなくなってしまいます。そのため、カオスエンジニアリングの前提として、システムに可観測性（Observability）を備えることが必要と言われています。可観測性とは、システム運用上必要な情報を把握できる状態を示ます。ログ／メトリクス／トレースの3つの柱を使って、システム内部の情報を表現します。
2. 仮説を立てる
定義した定常状態を害しそうな事象が起きたときのシステムの挙動について、システム開発／運用メンバーで話し合います。例えば「システムのキャッシュレイヤーに障害が起きたとしてもキャッシュ元のデータストアにデータを取りに行くはずなので、通常時よりもリクエストに時間がかかる可能性はあるが、利用者にエラーメッセージは返らずに、正常に利用できるはずである」といった内容です。その際には、現実的にありえそうな事象について仮説を立てることが重要です。例えば、急にシステムのピークリクエスト数が現在の100倍になるといった事象は起こりえないが、10倍ならありえそうだ、といった過去実績に基づいた判断を行うことがポイントです。このプロセスを経ることで、暗黙知化していたシステムの仕様や仕様不具合が見つかるかもしれません。例えば、先ほどのキャッシュレイヤーの障害について話をしているうち、アプリケーションでリトライ処理の実装漏れに気づく可能性があります。
3. 実験を計画する
前プロセスで立てた仮説のうち、実験対象の優先順位を検討します。優先順位は事象の発生頻度と発生した際の影響度で決めていくことが一般的ですが、その事象の発生しやすさを加味することもあります。
優先度を決めた後は、実験対象の検討を行います。実験の際には、実験群と定常群を決め、実験群に対してカオスの挿入を行います。2つの群の比較によって、仮説通りであるかを確認します。
また実験の影響範囲を最小化する方法についても検討を行います。これはカオスエンジニアリングのプロセスでも非常に重要なステップです。ネットワークやサーバーといったインフラに対するカオスの挿入は、一般的に影響範囲が大きくなりがちです。しかし、例えば加重ルーティングを利用してカオス挿入の対象となるサーバーが処理するリクエスト量を減らす、利用者が少ない時間帯で実験を行うなどの対策で影響範囲を小さくすることが可能です。
導入のハードルは高くなりますが、アプリケーションレイヤーで影響範囲を小さくする方法もあります。LinkedIn社のRest.liというアプリケーションフレームワークでは、Disruptor filterという機能によって、特定のリクエストのみエラーレスポンスを返したり、レスポンス時間を長くしたりというカオスを挿入することが可能です。これにより、カオス挿入時の影響をコントロールできます。
最後に実験の終了条件を決定します。正常終了の条件以上に重要となるのが、異常終了となる条件です。例えば、総リクエストのうち5XXのエラーレスポンスの占める割合が1％以上になったらカオス挿入を停止するなどの条件を明確化しておきます。さらに異常終了となった場合に復旧する方法についても明確化します。有事の際の迅速な対応とするために、復旧は自動化されていることを推奨します。
4. 実験を通して仮説を確認する
計画された実験はいきなり本番環境で実施するのではなく、まずステージング環境等の本番環境を模した環境で実施します。ステージング環境での実験時でも本番同様に、関係者に十分に事前周知を行います。実験時には、システムから出力された情報（ログ／メトリクス／トレース）はすべて記録しておきます。そして、仮説通り定常状態に影響を与えていないことを確認します。もし仮説と異なり、定常状態に影響が出た場合は、その原因を記録した情報から特定し、改善を行います。
ステージング環境でのカオス挿入が終わった後に、いよいよ本番環境での実験となります。本番環境での実験時は、関係者全員が対応できる時間帯である日中帯に実施することが推奨されています。また、Slack／Microsoft Teams等のチャットツールなどで情報共有を行いながら実験を進めることがよいと言われています。また実験の記録を確実に行うため、必要に応じてレコーディングを行い、抜け漏れがあっても後から振り返ることができるようにしておくこともオススメです。実験が完了したら、記憶が新鮮なうちに振り返りを実施します。いつ何を検知したか、いつ復旧をしたのかなどの具体的な時間の確認や想定外のことが起きたとしたらそれはどんなことだったのかなどを確認し、当日中に実験結果を関係者全員に向けてレポートします。
各プロセスで得られる効果
これまで説明してきたカオスエンジニアリングのプロセスで得られるチームにとってのプラス効果の例をまとめます。
| プロセス | プラス効果の例 |
|---|---|
| 定常状態を定義し、測定可能な状態にする |
|
| 仮説を立てる |
|
| 実験を計画する |
|
| 実験を通して仮説を確認する |
|
エンタープライズでのカオスエンジニアリングの導入
筆者は日本のエンタープライズでカオスエンジニアリングを導入するのであれば、まずはステージング環境までで十分だと考えています。これまで説明をしてきた通り、ここにいたるまでの各プロセスでシステムに関するさまざまな情報を棚卸され、設計のブラッシュアップやシステムに内包されていた問題点の洗い出しなど多くの効果を生み出したのではないかと考えています。もちろん本番環境でしか気づかない学びもあるのは間違いありませんが、システムのすべての関係者に本番環境でカオスを挿入することのメリットを説明して納得してもらうことはかなりの時間を要することになるでしょう。そのため、ステージング環境でのカオス挿入までのプロセスで改善できた実績を積み上げて、そののちに本番環境でのカオス挿入に進むというプロセスが適切と考えています。
次回予告
実際にChaos Toolkitを利用して、Azure環境へのカオス挿入の方法について紹介します。Chaos ToolKitのインストール方法や、実際にAzureのVirtual Machineへのカオス挿入方法について紹介します。
