App Service Environment を使用する高可用性エンタープライズ展開

可用性ゾーン は、特定のリージョン内のデータセンターの物理的に分離されたコレクションです。 ゾーン間でリソースをデプロイして、ゾーンに限定された停止がアプリケーションの可用性に影響しないようにすることができます。 このアーキテクチャでは、ゾーン冗長アーキテクチャにデプロイすることで、App Service Environment デプロイの回復性を向上させる方法について説明します。 これらのゾーンは近接性とは関係ありません。 サブスクリプションごとに異なる物理的な場所にマッピングできます。 アーキテクチャは、単一のサブスクリプション デプロイを前提としています。

可用性ゾーンをサポートする Azure サービスは、ゾーン、ゾーン冗長、またはその両方にすることができます。 ゾーン サービスは特定のゾーンにデプロイでき、ゾーン間でゾーン冗長サービスを自動的にデプロイできます。 詳細については、「 可用性ゾーンのサポート」を参照してください。 App Service Environment では、 ゾーン冗長デプロイがサポートされています。

ゾーン冗長性のために App Service Environment を構成すると、プラットフォームは、選択したリージョンで使用可能なゾーンの最大数に Azure App Service プランのインスタンスを自動的にデプロイします。 ゾーンの冗長性を有効にするには、リージョンで少なくとも 2 つのゾーンを使用できる必要があります。 その結果、App Service プランの最小インスタンス数は常に 2 になります。 プラットフォームによって、App Service Environment で使用できるゾーンの数が決まります。

Architecture

このアーキテクチャの Visio ファイル をダウンロードします。

このアーキテクチャの参照実装は、 GitHub で入手できます。

この参照実装の App Service Environment サブネット内のリソースは、 標準の App Service Environment デプロイ アーキテクチャのリソースと一致します。 このリファレンス実装では、App Service Environment v3 と Azure Managed Redis のゾーン冗長機能を使用して、高可用性を実現します。 この参照アーキテクチャのスコープは、1 つのリージョンに制限されます。

Components

• App Service Environment v3 は、 ゾーンの冗長性をサポートする分離された高パフォーマンスホスティング オプションです。 ゾーンの冗長性をサポートするリージョンでは、App Service Environment のライフ サイクル中にいつでもゾーンの冗長性を構成できます。 ゾーン冗長 App Service Environment の各 App Service プランには、2 つ以上のゾーンにデプロイできるように、少なくとも 2 つのインスタンスが含まれている必要があります。 同じ App Service 環境内でゾーン冗長プランと非ゾーン冗長プランを組み合わせることができます。 インスタンスが 1 つしかないプランを構成するには、まず、そのプランのゾーン冗長を無効にします。 ゾーン冗長では、追加料金は発生しません。 お支払いは、使用中の Isolated v2 インスタンスに対してのみ行います。 詳細については、「 App Service Environment の価格 と 信頼性」を参照してください。 このアーキテクチャでは、App Service Environment v3 は、Web アプリ、API、および関数用の分離された高パフォーマンスホスティング プラットフォームを提供します。

• Azure Virtual Network は、1 つのリージョン内のすべての可用性ゾーンにまたがるレイヤー 3 の IP ベースのネットワークです。 仮想ネットワーク内のサブネットも、可用性ゾーン間で拡張されます。 詳細については、「仮想ネットワークの App Service 環境と信頼性のネットワーク要件」を参照してください。 このアーキテクチャでは、Virtual Network は、すべてのリソースに対してセキュリティで保護された分離されたネットワークを提供します。

• Azure Application Gateway v2 は、ゾーンの冗長性をサポートするクラウドネイティブの Web トラフィック ロード バランサーです。 このアーキテクチャでは、各リージョンの複数の可用性ゾーンにまたがっています。 その結果、参照アーキテクチャに示すように、1 つのアプリケーション ゲートウェイで高可用性が提供されます。 参照アーキテクチャでは、Application Gateway の Web アプリケーション ファイアウォール SKU を使用します。これによって、一般的な脅威や脆弱性に対する保護が強化されます。 この保護は、Open Web Application Security Project (OWASP) のコア ルール セット (CRS) の実装に基づいています。 詳細については、「 Application Gateway v2 の信頼性」を参照してください。 Application Gateway v2 は、ゾーン冗長 Web トラフィック ロード バランサーとして機能します。

• Azure Firewall は、高可用性の組み込みサポートを含む、クラウドネイティブのマネージド ネットワーク セキュリティ サービスです。 追加の構成なしで複数のゾーンを使用できます。 このアーキテクチャでは、Azure Firewall は、仮想ネットワーク内のリソースの送信トラフィックを制御および監視するための、管理された高可用性ネットワーク セキュリティを提供します。

  ファイアウォールをデプロイするときに、特定の可用性ゾーンを構成することもできます。 詳細については、 Azure Firewall 可用性ゾーンのサポートに関するページを参照してください。 参照アーキテクチャでは、この構成は使用されません。

• Microsoft Entra ID は、可用性ゾーンとリージョンにまたがる高可用性の高冗長グローバル サービスです。 詳細については、「 Microsoft Entra ID の可用性の向上」を参照してください。 このアーキテクチャでは、Microsoft Entra ID は、すべてのコンポーネントで認証と承認を行う高可用性の冗長 ID およびアクセス管理サービスを提供します。

• GitHub Actions は、継続的インテグレーションと継続的デプロイ (CI/CD) 機能をサポートするオートメーション プラットフォームです。 このアーキテクチャでは、GitHub Actions によって仮想ネットワークの外部にアプリがビルドされ、App Service Environment でホストされている App Service プランにデプロイされます。

App Service Environment は仮想ネットワーク内に存在するため、仮想マシン (VM) は、デプロイを容易にするために仮想ネットワーク内のジャンプ ボックスを提供します。 セキュリティとリモート デスクトップ プロトコル (RDP) と Secure Shell (SSH) の接続を強化するには、ジャンプ ボックスに Azure Bastion を使用することを検討してください。

• Azure Managed Redis はゾーン冗長サービスです。 ゾーン冗長キャッシュは、複数の可用性ゾーンにまたがってデプロイされた VM 上で実行されます。 このアーキテクチャでは、Azure Managed Redis により、より高い回復性と可用性が提供されます。

考慮事項

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「 Well-Architected Framework」を参照してください。

Reliability

信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。

ジャンプ ボックス

この参照実装では、標準デプロイと同じ運用レベルの CI/CD パイプラインを使用します。ジャンプ ボックス VM は 1 つだけです。 ただし、3 つのゾーンごとに 1 つのジャンプ ボックスを使用できます。 ジャンプ ボックスはアプリの可用性に影響しないため、このアーキテクチャではジャンプ ボックスが 1 つだけ使用されます。 ジャンプ ボックスでは、デプロイとテストがサポートされます。

App Service Environment

App Service Environment を可用性ゾーン間にデプロイして、ビジネスクリティカルなワークロードの回復性と信頼性を提供できます。 この構成は、ゾーン冗長とも呼ばれます。

ゾーンの冗長性を実装すると、プラットフォームは選択したリージョン内の 2 つ以上のゾーンに App Service プランのインスタンスを自動的にデプロイします。 その結果、App Service プランの最小インスタンス数は常に 2 になります。

• App Service Environment を作成するとき、または環境のライフ サイクルの任意の時点で 可用性ゾーンを構成 できます。

• その App Service 環境で作成するすべての App Service プランでは、ゾーンの冗長性を有効にするために少なくとも 2 つのインスタンスが必要です。 環境がゾーン冗長である場合は、個々の App Service プランのゾーン冗長を選択的に有効または無効にすることができます。 App Service プランを 1 つのインスタンスにスケールインするには、そのプランのゾーン冗長性を無効にしてから、スケールイン操作に進みます。

• 可用性ゾーンをサポートするのは 、リージョンのサブセット のみです。

詳細については、「 App Service の信頼性」を参照してください。

Resiliency

App Service Environment で実行されるアプリケーションは、Application Gateway の バックエンド プール を形成します。 アプリケーションへの要求がパブリック インターネットから送信されると、ゲートウェイは App Service Environment で実行されているアプリケーションに要求を転送します。 この参照アーキテクチャでは、と呼ばれるメイン Web フロントエンド内にvotingAppを実装します。 この正常性プローブは、Web API と Redis Cache の正常性状態を確認します。

var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionEndpoints:VotingDataAPIBaseUri"))
{
    Path = "/health"
};

services.AddHealthChecks()
    .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
    .AddRedis(Configuration.GetValue<string>("ConnectionEndpoints:RedisConnectionEndpoint"));

Web フロントエンド、API、キャッシュなどのコンポーネントが正常性プローブに失敗した場合、Application Gateway は要求をバックエンド プール内の他のアプリケーションにルーティングします。 この構成により、要求は常に完全に使用可能な App Service Environment サブネット内のアプリケーションにルーティングされます。

標準の参照実装では、正常性プローブも使用されます。 その実装では、正常性プローブが失敗した場合、ゲートウェイからエラーが返されます。 しかし、高可用性の実装により、アプリケーションの回復性とユーザー エクスペリエンスの品質が向上します。

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。

高可用性アーキテクチャのコストに関する考慮事項は、標準のデプロイと似ています。

次の違いがコストに影響する可能性があります。

• 可用性ゾーンのサポートでは、追加料金は発生しません。 お支払いは、使用するインスタンスに対してのみ行います。 詳細については、App Service Environment の価格を参照してください。

• Azure Managed Redis は、高可用性が有効になっているときに、複数の可用性ゾーンを持つリージョンでゾーン冗長サービスになります。 ゾーン冗長キャッシュは、リージョン内の複数の可用性ゾーンにデプロイされたノードで実行され、より高い回復性と可用性を提供します。

高可用性、回復性、安全性の高いシステムのトレードオフには、一部の Azure サービスのコストの増加が含まれます。 要件を評価し、コストを見積もるために、 Azure 料金計算ツールを使用します。

このシナリオのデプロイ

このアーキテクチャの参照実装をデプロイするには、 GitHub の readme を参照してください。 高可用性のデプロイには、スクリプトを使用します。

貢献者達

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

主要な著者:

• Deep Bhattacharya | クラウド ソリューション アーキテクト
• Suhas Rao | クラウド ソリューション アーキテクト

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

このアーキテクチャを変更するには、予想されるピーク時の負荷容量に基づいて、同じリージョン内または複数のリージョン間でアプリケーションを水平方向にスケーリングできます。 複数のリージョンにアプリケーションをレプリケートすると、地震やその他の自然災害による障害など、より広範な地理的データセンター障害のリスクを軽減するのに役立ちます。

• 水平スケーリングの詳細については、「 App Service Environment を使用した地理的分散スケール」を参照してください。
• グローバルで高可用性のルーティング ソリューションを使用する場合は、Azure Front Door を使用することを検討してください。