はじめに
Azure Web Appsは、フルマネージドなWebアプリケーションホスティングのPaaSです。WebアプリケーションのコードをWeb Appへデプロイするだけで、すぐにホスティングが可能です。
このAzure Web AppsはAzureのリージョンにデプロイして使うサービスなので、ディザスターリカバリーの観点で複数のリージョンにデプロイし、地理的分散冗長を構成することが多くあります。今回はそのようなシナリオで使用されるAzure Web Appsに対するカオス挿入の方法などについて説明します。
Chaos ToolkitでWeb Appに挿入できるカオス
Web Appsに対して、Chaos Toolkitで挿入可能なカオスは、以下の4つのアクションになります。
# | アクション名 | 内容 |
---|---|---|
1 | delete_webapp | Web Appを削除する。 |
2 | restart_webapp | Web Appを再起動する。 |
3 | start_webapp | Web Appを開始する。 |
4 | stop_webapp | Web Appを停止する。 |
Azure Web Appsはフルマネージドであることを売りとしたWebアプリケーションホスティングサービスのため、その内部で稼働しているVM自体の停止、削除といった操作用のインターフェースは公開していません。
そのため、Chaos Toolkitから行えるカオス挿入は、Web Appリソースの開始/停止/再起動/削除に限られます。
Web Appsに対する実験
カオスを挿入するシステム
今回は、Web Appを東日本と西日本にそれぞれデプロイすることで地理的に冗長な構成にしたうえで、通常は東日本のWeb Appでリクエストを処理し、東日本のWeb Appが停止した時は、西日本のWeb Appに自動でリクエストをルーティングする実験を考えてみます。
東西へのルーティング制御には、DNSベースのトラフィックロードバランサーであるTraffic Managerを使用します。その他Azure FrontDoor、Azure Load Balancerなどを使用した場合でも、地理的分散を構成することは可能です。
Traffic Managerを使った場合、下図のようにDNSでの名前解決で得られるIPアドレスが、東日本か西日本、どちらかのWeb Appのものとなるので、この名前解決の時点で2つのWeb Appに対するロードバランシングが行われます。
Traffic Managerには、東西2つのWeb Appをエンドポイントとして登録しておきます。
また、今回は、通常は東日本のWeb Appへルーティングするため、優先順位によるルーティング設定を採用します。
なおTraffic Managerでは、優先順位付け以外(例えば、バックエンドの応答時間など)でのルーティングも可能です。詳細については下記ドキュメントをご参照ください。