実験結果の確認
今回の実験では、インスタンスのCPU使用率が増加するアクションを実行するため、VMSSの自動スケールの機能により、スケールアウトが発動したことを確認できます。
実験中の監視状態として、Application Insightsの可用性テストの結果画面を確認してみます。
今回の場合は、インスタンスのCPU使用率が増加している時間帯、スケールアウトが発動した時間帯、スケールアウトが完了した時間帯のすべての時間帯で異常状態には至らず、アラート通知の発報も発生しない結果となりました。
図中の緑の点で示す散布図はレスポンスタイムを示しており、縦軸がレスポンスタイム、横軸が時間を示しています。実験中は、レスポンスタイムがやや劣化しているものの、定常状態として定義した範囲内（＝レスポンスタイムが3000ms以内）に収まっていることが確認できます。また、レスポンス結果もすべて成功（＝HTTP Statusが200）であることが確認できます。
そのため、今回の実験による障害に対しては、耐えることができるシステムであるという結果が得られます。
まとめ
今回、Azure Chaos Studioを利用してVMSSにカオスを挿入する方法を説明し、安全にカオスを挿入するためのポイントを紹介しました。今回は非常にシンプルな構成のシステムを例に説明しましたが、実際のエンタープライズ向けシステムでは、より複雑なシステム構成をとることになると思います。その場合、どのような状態を定常状態と定義し、定常状態をどのように確認するかがポイントになります。
今回のような実験を通じて、サーバーのCPU使用率やメモリ使用率といったリソース使用量のモニタリングだけでなく、スループットやレスポンスタイムといったサービスのパフォーマンスをモニタリングすることの重要性を体感でき、システムを運用する上で何をモニタリングするべきかを検討する材料になると考えます。
カオスエンジニアリングのもともとの考え方としては、本番環境のシステムにカオスを挿入することで耐障害性を検証する方法論とされています。しかし、システム停止時の影響が大きいエンタープライズのシステムで本番環境にカオスを挿入することは、ハードルが高いのが現実です。
そのような場合、テスト環境やステージング環境といった"本番相当"の環境でカオスを挿入する方針をとることは、筆者としては有効であると考えています。"本番相当"の環境での実験結果から、システムの課題を確認し、本番環境の改善を図るというサイクルを回すことで、カオスエンジニアリングを活用したシステム改善を図ることができると考えています。
また、本記事執筆時点でパブリックプレビューとなっているAzure Load Testingを使用した負荷テストとChaos Studioの実験を組み合わせると、エンタープライズ向けシステムにとって、より有益な検証が期待できると考えています。
次回予告
次回はAWS Fault Injection SimulatorによるAmazon Elastic Container Service（Amazon ECS）に対するカオス挿入方法を紹介します。昨今の主流となりつつあるコンテナサービスに対しては、どのようにカオス挿入するのかを見ていきたいと思います。
