PaaSでカオスエンジニアリング～Azure Web Appsにカオス挿入してみよう

クラウドネイティブ時代の実践カオスエンジニアリング　第4回

　前回は、Azure Virtual Machine Scale Set（VMSS）に対するカオス挿入を紹介しました。今回は、PaaSであるAzure Web Appsを活用して、地理的に冗長な構成にしたシステムに対してカオスを挿入し、一部のWeb Appにカオスを挿入しても、定常状態が維持できることを確認します。

はじめに

　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をエンドポイントとして登録しておきます。

Traffic Managerの設定

　また、今回は、通常は東日本のWeb Appへルーティングするため、優先順位によるルーティング設定を採用します。

ルーティング方法の設定

　なおTraffic Managerでは、優先順位付け以外（例えば、バックエンドの応答時間など）でのルーティングも可能です。詳細については下記ドキュメントをご参照ください。

• Traffic Manager のルーティング方法
• Azure Traffic Manager による Azure App Service トラフィックの制御