App Service Environment を使用した高可用性エンタープライズ デプロイ

Azure Active Directory
Application Gateway
ファイアウォール
Virtual Network
App Service

可用性ゾーンは、特定のリージョン内の物理的に分離されたデータセンターです。 デプロイを複数のゾーンにわたってレプリケートすると、ローカルの停止がゾーンに限定されても、アプリケーションの可用性に悪影響を与えません。 本アーキテクチャでは、複数の可用性ゾーンにデプロイすることにより、ASE デプロイの回復性を向上させる方法を示します。 これらのゾーンは、近接に関連していません。 サブスクリプションごとに異なる物理的な場所にマッピングできます。 このアーキテクチャは、単一のサブスクリプション デプロイを前提としています。

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

アーキテクチャ

高可用性 ASE のデプロイのためのリファレンス アーキテクチャ

このリファレンス実装で使用されている ASE サブネットの内容は、ここで説明されている標準 ASE デプロイ アーキテクチャの内容と同じです。 このリファレンス実装では、2 つの ASE サブネットにデプロイをレプリケートします。 各サブネットには、個別の App Service プランで実行されるそれ自体の Web アプリケーション、API、関数インスタンスがあります。 アプリケーションに必要な Redis キャッシュ も、パフォーマンス向上のためにレプリケートされます。 このリファレンス アーキテクチャの範囲は、1 つのリージョンに限定されます。

ワークフロー

次のセクションでは、このアーキテクチャで使用されるサービスの可用性の性質について説明します。

App Services Environment は、内部または ILB モードでのみ、複数の可用性ゾーンにデプロイできます。 このリファレンス実装では、それぞれ異なる可用性ゾーンに 2 つの ASE サブネットをデプロイします。 アプリケーションのエンドツーエンドの回復性を確保するには、少なくとも 2 つの可用性ゾーンを使用することをお勧めします。 すべてのランタイム ILB ASE リソースは、指定されたゾーンに配置されます。このゾーンには、ASE の内部ロードバランサーの IP アドレス、コンピューティング リソース、および ASE がその ASE にデプロイされたすべてのアプリを実行するために必要な基になるファイル ストレージが含まれます。 詳細なガイダンスと推奨事項については、Availability Zones の App Service Environment サポートを参照してください。

Azure Virtual Network または Vnet は、1 つのリージョンに制限されているすべての可用性ゾーンにまたがります。 VNet 内のサブネットも可用性ゾーンにまたがります。 このリファレンス アーキテクチャでは、可用性ゾーン用に作成された各 ASE デプロイのサブネットを作成します。 詳細については、App Service Environment のネットワーク要件を参照してください。

Application Gatewayv2ゾーン冗長です。 仮想ネットワークと同様に、リージョンあたり複数の可用性ゾーンにまたがります。 つまり、このリファレンス アーキテクチャで示すように、可用性の高いシステムには単一のアプリケーション ゲートウェイで十分です。 v1 SKU は、これをサポートしていません。 詳細については、「自動スケーリングとゾーン冗長 Application Gateway v2」を参照してください。

Azure Firewall には、組み込みの高可用性のサポートがあります。 追加の構成なしで複数のゾーンにまたがることができます。 これにより、このリファレンス アーキテクチャのように、複数のゾーンでデプロイされたアプリケーションに対して 1 つのファイアウォールを使用できます。 このアーキテクチャでは使用されませんが、必要に応じて、ファイアウォールをデプロイするときに特定の可用性ゾーンを構成することもできます。 詳細については、Azure Firewall と Availability Zones を参照してください。

Azure Active Directory は、可用性ゾーンとリージョンにまたがる高可用性で、高冗長性のグローバル サービスです。 詳細については、「Azure Active Directory の可用性の進化」を参照してください。

Azure Pipelines では、CI/CD アクティビティの並列処理がサポートされています。 複数のジャンプボックス VM または Azure Bastion サブネットを通じて、構築されたアプリケーションを複数の ASE サブネットに同時にデプロイするには、デプロイ フェーズでこの並列処理を使用します。 このアーキテクチャでは、2 つのジャンプボックス仮想マシンを使用して、同時デプロイを支援します。 並列ジョブの数は、価格レベルに関係しています。 Microsoft がホストする CI/CD の基本無料レベルでは、最大 10 個のタスクを並列化できます。各タスクは最大 6 時間実行されます。

Azure Cache for Redis は、ゾーン対応のサービスではありません。 このアーキテクチャでは、Redis Cache を保持する 2 つのサブネットを作成し、それぞれが ASE サブネットの可用性ゾーンに繋ぎ止められます。 アプリケーションにキャッシュを近づけるほど、アプリのパフォーマンスが向上するため、これをお勧めします。 これはプレビュー 機能であり、Premium レベルでのみ使用できることに注意してください。

考慮事項

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

可用性

App Service Environment

ILB を使用する App Service 環境は、特定の可用性ゾーンにデプロイすることができます。 可用性ゾーンは、同じリージョンで、地理的に離れた場所にある自己完結型のデータセンターです。 1 つのデータセンターがダウンし、アーキテクチャでサポートされている場合は、その他のデータセンターにデプロイされたアプリケーションで可用性を確保できます。

この機能は次の方法によって使用できます。

  • 2 つの異なるゾーンに 2 つ以上の環境をデプロイし、各 ASE でアプリケーションが複製されるようにする。
  • ゾーン冗長 Application Gateway を使用して、トラフィックを ASE に負荷分散します。このリファレンス アーキテクチャについては、こちらを参照してください。

いくつかの追加のポイントも考慮してください。

  • ILB ASE をゾーンにデプロイすると、既にデプロイされているアプリケーションとリソースのアップタイムが保証されます。 ただし、App Service プランのスケーリング、アプリケーションの作成、およびアプリケーションのデプロイは、他のゾーンの停止によって影響を受ける可能性があります。
  • ARM テンプレートは、ILB ASE を可用性ゾーンに最初にデプロイするときに使用する必要があります。 その後、ポータルまたはコマンド ラインを使用してアクセスできます。 ゾーン プロパティは、論理ゾーンを示す 1、2、または 3 に設定する必要があります。
  • 既定では、仮想ネットワークはゾーン冗長であるため、ASE サブネットをデプロイされたすべてのゾーンは同じ仮想ネットワーク内に配置できます。
  • 外部向け ASE は、可用性ゾーンにピン留めすることはできません。

詳細については、「Availability Zones に対する App Service Environment サポート」を参照してください。

回復性

両方の ASE サブネット内のアプリケーションは、Application Gateway のバックエンド プールを形成します。 アプリケーションへの要求がパブリック インターネットから行われる場合、ゲートウェイは 2 つのアプリケーション インスタンスのいずれかを選択できます。 Application Gateway は、Application Gateway による正常性監視の概要に説明されているように、既定ではバックエンド プール リソースの正常性を監視します。 リファレンス セットアップでは、既定の正常性プローブは Web フロントエンドのみを監視できます。 この Web フロントエンドでは他のコンポーネントを使用するため、そのゾーン内のデータセンターの部分的な障害によって依存関係が失敗した場合でも正常に動作しますが、エラーが発生する可能性があります。 このようなエラーを回避するには、カスタム プローブを使用して、アプリケーションの正常性が実際に意味するところを制御します。 このリファレンス アーキテクチャでは、メインの Web フロントエンドである votingApp 内に正常性チェックが実装されます。 この正常性プローブは、Web API と Redis キャッシュが正常であるかどうかを確認します。 Startup.cs で、このプローブを実装するスニペットを参照してください。

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

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

次のスニペットは、deploy_ha sh スクリプトが、どのように Application Gateway のバックエンド プールと正常性プローブを構成するかを示しています。

# Generates parameters file for appgw arm script
cat <<EOF > appgwApps.parameters.json
[
  { 
    "name": "votapp", 
    "hostName": "${APPGW_APP1_URL}", 
    "backendAddresses": [ 
      { 
        "fqdn": "${INTERNAL_APP1_URL1}" 
      },
      { 
        "fqdn": "${INTERNAL_APP1_URL2}" 
      } 
    ], 
    "certificate": { 
      "data": "${CERT_DATA_1}", 
      "password": "${PFX_PASSWORD}" 
    }, 
    "probePath": "/health" 
  },
...

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

正常性プローブは、標準のリファレンス実装にも実装されています。 正常性プローブが失敗した場合、ゲートウェイは、単にエラーを返します。 ただし、高可用性の実装では、アプリケーションの回復性とユーザー エクスペリエンスの品質が向上します。

コストの最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

高可用性アーキテクチャのコストに関する考慮事項は、標準のデプロイとほとんど同じです。

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

  • App Service 環境の複数のデプロイ。
  • Azure Cache for Redis の Premium レベル インスタンスの複数のデプロイ。 このリファレンス アーキテクチャでは、次の理由から Premium レベルを使用します。
    • 仮想ネットワーク内から使用できるのは、Premium レベルの Azure Cache for Redis のみです。
    • パブリック プレビュー機能である Redis Cache のゾーン固定は、Premium レベルのでのみ使用できます。

高可用性、回復力、およびセキュリティで保護されたシステムためのトレードオフには追加のコストがかかります。 料金計算ツールを使用して、価格に関する企業のニーズを評価します。

デプロイに関する考慮事項

このリファレンス実装は、可用性ゾーンごとに 1 つのジャンプボックス仮想マシンを使用して、標準のデプロイで使用される運用レベルの CI/CD パイプラインを拡張します。 これは、次の 2 つの目的があります。

  • ASE リソースによって使用されるのと同じ可用性ゾーンに仮想マシンをピン留めし、1 つまたは 2 つのゾーンに制限された障害が発生した場合に備えて、デプロイの稼働時間を確保します。
  • また、仮想マシンを Azure Pipelines エージェントのプールとして使用することで、デプロイの並列化にも役立ちます。

このリファレンス実装の azure-pipelines.yml ファイルは、各ゾーン ASE に対して個別のデプロイ ステージを作成することで、この並列デプロイを示します。

このシナリオのデプロイ

このアーキテクチャのリファレンス実装をデプロイするには、GitHub の readme を参照し、高可用性デプロイのためのスクリプトに従ってください。

次のステップ

このリファレンス アーキテクチャに示されている学習を拡張し、予想されるピーク時の負荷容量に基づいて、アプリケーションを同じリージョン内または複数のリージョンで水平方向にスケールできます。 アプリケーションを複数のリージョンにレプリケートすることは、地震やその他の自然災害などによって、より広範囲に広がるデータ センターの障害のリスクを軽減するのに役立ちます。 水平スケーリングの詳細については、App Service Environment を使用した Geo 分散スケールを参照してください。 グローバルで高可用性のルーティング ソリューションを使用する場合は、Azure Front Door を使用することを検討してください。