Azure Chaos Studio の Network Isolation Fault Action を使って Azure VM からのアウトバウンド通信を遮断してみよう

いわさです。

この記事は Microsoft Azure Advent Calendar 2024 の 14 日目の記事です。

https://qiita.com/advent-calendar/2024/azure

みなさん Azure Chaos Studio は使ってますか。Azure のカオスエンジニアリングサービスです。
DevelopersIO だと AWS 有識者の方が多そうなので補足しておくと、AWS では Fault Injection Service と同じような位置づけのサービスです。

この Azure Chaos Studio、定期的にアップデートされていまして、最近ネットワーク周りの障害が追加されて充実してきています。
これまでも Network Latency、Network Packet Loss など使いやすいアクションが提供されていましたが、2024 年 8 月ごろには一定期間の全てのパケットをドロップさせる Network Isolation アクションが追加されていました。

https://azure.microsoft.com/en-us/updates?id=generally-available-azure-chaos-studio-supports-a-new-network-isolation-fault-for-virtual-machines

これらのアクションではネットワーク障害を起因に仮想マシン上で問題が生じた場合に、ワークロード全体の挙動がどうなるのか確認することが出来ます。
アラートをトリガーする場合もあれば、自動復旧する場合など、耐障害性を高めるために様々なことをされている方が多いと思いますが、それらが正しく稼働するのか評価することが出来ます。

検証環境

今回は仮想マシンからハートビートパケットを送信する何かしらのモニタリング環境用意したので、アクションが正しく動作するのか確認してみます。
Azure Virtual Machine 上の Windows と Linux どちらもサポートされていますが、Windows については双方向のトラフィック、Linux についてはアウトバウンドトラフィックのみ作用させることが出来ます。

今回は Ubuntu 仮想マシンで適当な外部エンドポイントに 5 秒ごとにアウトバウンド通信を発生させました。

watch -n 5 'curl -X POST -H "Content-Type: application/json" -d "{\"status\":\"active\"}" https://1oo08l7hp0.execute-api.ap-northeast-1.amazonaws.com/hoge/'

Azure Chao Studio での実験前はモニタリングサービス側では次のように定期的にリクエストが発生していることが確認出来ています。

実験の用意

実験の構成時にはターゲットを指定する必要があります。
なので事前に仮想マシンを Chaos Studio のターゲットとして有効化しておく必要があります。
さらに、今回のアクションのターゲットはエージェントになります。Chaos Studio のターゲットはエージェントベースとサービス直の 2 種類があるので注意が必要です。VM 内部で動作するものはほぼエージェントベースです。

また、エージェント作成時にマネージド ID を設定する形になると思いますが権限に注意してください。
以下を見ながら設定すると良いですが、適切な権限が割り当てられていない場合、実験開始後に失敗します。

https://learn.microsoft.com/en-us/azure/chaos-studio/chaos-studio-tutorial-agent-based-portal

ターゲットとマネージド ID の準備が出来たら実験を作成します。

Fault アクションで「Network Isolation」を選択しましょう。
デフォルトの時間は 10 分です。注意点として Chaos Studio のエージェント通信自体も遮断されてしまうので、ポータルからターゲットに対してキャンセル指示が出来ないです。指定した期間まで実行されるのでご注意ください。

設定するのは時間くらいで、オプションでスケールセットの指定も出来ますが今回は直接仮想マシンをターゲットにしているので割愛します。

開始

実験が構成出来たら実験を開始しましょう。

2 回ほど失敗した履歴がありますが、これはマネージド ID の権限不足で発生したものです。
ステータスが Running になれば実験は開始出来ている状態です。

しばらく経過してモニタリングツールを見てみると、該当期間のアウトバウンド通信が一切発生してないことが確認出来ました。

SSH などリモート接続している場合も当然切断されますのでアプリケーションの再復旧などは自動構成しておくと良いです。

さいごに

本日は Azure Chaos Studio の Network Isolation Fault Action を使って Azure VM からのアウトバウンド通信を遮断してみたいということで、非常に単純なパターンですが、Ubuntu 仮想マシンからのアウトバウンド通信を遮断しその様子をモニタリングツール側で観察してみました。

エージェントベースの実行になるので、マネージド ID をはじめ、いくつか注意点や制限事項がありますが概ね基本的なシナリオは実行出来るのではないかなと思います。
今後はエージェントベースではなく VNET 全体に作用するような、そういったアクションも導入されるとよりおもしろいシミュレーションが出来そうですね。