こんばんは。最近、Azureのアーキテクチャセンターの記事をちょこちょと読みつまんでクラウドアーキテクチャについて勉強をしています。
今日は、Azure App Serviceの可用性を高めるプラクティスについて学びたいと思います。
Contents
本日の教材
可用性の高い複数リージョンの Web アプリケーション：
前提：Azure App Serviceの可用性
Azure App Serviceは、Webアプリケーションを稼働させるためのプラットフォーム（OS～ミドル）をAzureが提供する、AzureのPaaSサービスです。
話の前提として、このAzure App Serviceを例にとり、その可用性について復習しておきましょう。
Microsoft Azureでは、サービス毎に可用性の宣言が公開されていますが、App Serviceでは、2021/06/20現在、99.95%の可用性が約束されています。
https://azure.microsoft.com/ja-jp/support/legal/sla/app-service/v1_4/
そして、こんなところに早見表がありますが、99.95%ということは、週間5分、月間21分、年間4.4時間のダウンタイムが発生しうることになります。
https://qiita.com/Aida1971/items/9ea3d3bcf29c906c7971
ミッションクリティカルでないアプリであれば、許容できるかもしれませんが、クリティカルなアプリでは、このダウンタイムでも許容できないでしょう。
こういった場合にとりうる対策を、アーキテクチャセンターの記事を元に整理しておきたいと思います。
アーキテクチャ
このアーキテクチャのポイントは以下。
- App Serviceはじめ、関連リソースをそれぞれ複数リージョンにデプロイし、プライマリリージョン/セカンダリリージョンを作る
- ペアにするリージョンは、Azureが定めるペアリージョンをベースに決定すると良い（参考）
- Azureのペアリージョンには、同じ”地域”（リージョンの一つ上の概念）内の複数のリージョンが選ばれる。プラットフォームの更新が行われる場合や、複数リージョンに障害が発生した場合に、片方が優先して復旧されるようにAzure側で考慮される（例えば、日本”地域”の場合は東日本リージョンと西日本リージョンがペア）
- リクエストの振り分けのため、リージョン間の振り分けが可能なAzure Front Doorを配置する
- Front Doorが単一障害点となる可能性は残るが、Front DoorのSLAは99.99%とApp Serviceよりも高いため、App Service単体で運用するよりは高い可用性が実現できる
- Azure Front Doorでは、振り分け優先順位の機能によりActive/Active (Hot Standby/Cold Standby), Active/Passiveのトポロジを実現するためのルーティング構成が可能。（参考）
- SQL Databsase/CosmosDBなどのデータベースは、それぞれが持つレプリケーション機能を利用することで複数リージョンデプロイを実現する
- 管理の効率性のため、リージョン毎にリソースグループを分けると良い。
確かに、日本で提供するサービスでは、Front Door + ペアリージョンデプロイ（東日本・西日本）は、鉄板かもしれないですね。App Serviceのネットワーク機能でも、Froot Doorとの統合機能が提供されていますが、こういう構成を想定して用意されたものなのでしょうね・・！勉強になりました！
今日も最後までご覧いただきありがとうございました！
おしまい
