編集

次の方法で共有

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

Microsoft Entra ID
Azure Application Gateway
Azure Firewall
Azure Virtual Network
Azure App Service

Note

App Service Environment バージョン 3 は、このアーキテクチャの主要なコンポーネントです。 バージョン 1 と 2 は、2024 年 8 月 31 日に。

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

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

App Service Environment をゾーン冗長になるように構成した場合、プラットフォームは、選択されたリージョン内の 3 つのゾーンで Azure App Service プランのインスタンスを自動的にデプロイします。 したがって、App Service プラン インスタンスの最小数は常に 3 です。

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

Architecture

App Service Environment の高可用性デプロイのための参照アーキテクチャを示す図。

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

このリファレンス実装での App Service Environment サブネット内のリソースは、標準的な App Service Environment のデプロイのアーキテクチャのリソースと同じです。 このリファレンス実装では、App Service Environment v3 と Azure Cache for Redis のゾーン冗長機能を使用して、可用性を向上させます。 このリファレンス アーキテクチャの範囲は、1 つのリージョンに限定されます。

ワークフロー

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

  • App Service Environment v3 はゾーン冗長用に構成できます。 ゾーン冗長は、App Service Environment の作成時のみ、App Service Environment v3 のすべての依存関係をサポートするリージョンでのみ構成できます。 ゾーン冗長 App Service Environment の各 App Service プランには、3 つのゾーンにデプロイできるように、少なくとも 3 つのインスタンスが必要です。 最小料金は 9 つのインスタンスに対して行われます。 詳細については、価格ガイダンスを参照してください。 詳細なガイダンスと推奨事項については、Availability Zones の App Service Environment サポートを参照してください。

  • Azure Virtual Network は、1 つのリージョンにあるすべての可用性ゾーンにまたがります。 仮想ネットワーク内のサブネットも可用性ゾーンをまたがっています。 詳細については、App Service Environment のネットワーク要件を参照してください。

  • Application Gateway v2 は、ゾーン冗長です。 仮想ネットワークと同様に、リージョンあたり複数の可用性ゾーンにまたがります。 したがって、参照アーキテクチャで示すように、可用性の高いシステムには単一のアプリケーション ゲートウェイで十分です。 参照アーキテクチャでは、Open Web Application Security Project (OWASP) のコア ルール セット (CRS) の実装に基づいて、一般的な脅威と脆弱性に対する保護を強化する、Application Gateway の WAF SKU を使用します。 詳細については、Application Gateway v2 と WAF v2 のスケーリングに関するページを参照してください。

  • Azure Firewall には、組み込みの高可用性のサポートがあります。 追加の構成なしで複数のゾーンにまたがることができます。

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

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

  • GitHub Actions は、このアーキテクチャの継続的インテグレーションと継続的デプロイ (CI/CD) 機能を提供します。 App Service Environment は仮想ネットワークの内部にあるため、仮想マシンを仮想マシンのジャンプボックスとして使用して、App Service プランにアプリケーションをデプロイします。 このアクションにより、仮想ネットワークの外部にアプリがビルドされます。 セキュリティを強化し、RDP/SSH 接続をシームレスにするには、Azure Bastion をジャンプボックスとして使用することをご検討ください。

  • Azure Cache for Redis はゾーン冗長サービスです。 ゾーン冗長キャッシュは、複数の可用性ゾーンにまたがってデプロイされた VM 上で実行されます。 このサービスにより、回復性と可用性が向上します。

考慮事項

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

可用性

App Service 環境

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

ゾーン冗長を実装する場合、プラットフォームによって、選択されたリージョン内の 3 つのゾーンに対して Azure App Service プラン インスタンスが自動的にデプロイされます。 したがって、App Service プラン インスタンスの最小数は常に 3 です。 3 を超える容量を指定し、インスタンスの数が 3 で割り切れる場合は、インスタンスが均等にデプロイされます。 それ以外の場合、残りのインスタンスは残りのゾーンに追加されるか、残りの 2 つのゾーンにまたがってデプロイされます。

  • App Service Environment を作成するときに可用性ゾーンを構成します。
  • その App Service Environment で作成されたすべての App Service プランには、少なくとも 3 つのインスタンスが必要です。 これらは自動的にゾーン冗長になります。
  • 可用性ゾーンは、新しい App Service Environment を作成するときにのみ指定できます。 既存の App Service Environment は、可用性ゾーンを使用するように変換できません。
  • 可用性ゾーンは、リージョンのサブセットでのみサポートされます。

詳細については、「Azure アプリ サービスでの責任」を参照してください。

回復性

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

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"));

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

# Generates parameters file for appgw script
cat <<EOF > appgwApps.parameters.json
[
  {
    "name": "votapp",
    "routingPriority": 100,
    "hostName": "${APPGW_APP1_URL}",
    "backendAddresses": [
      {
        "fqdn": "${INTERNAL_APP1_URL}"
      }
    ],
    "probePath": "/health"
  }
]

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

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

コストの最適化

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

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

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

  • ゾーン冗長 App Service Environment では、少なくとも 9 つの App Service プラン インスタンスで課金されます。 詳細については、App Service Environment の価格を参照してください。
  • Azure Cache for Redis もゾーン冗長サービスです。 ゾーン冗長キャッシュは、複数の可用性ゾーンにまたがってデプロイされる VM 上で実行され、回復性と可用性を向上させます。

高可用性、回復性、安全性の高いシステムのトレードオフにより、コストが増加します。 料金計算ツールを使用して、価格に関するニーズを評価します。

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

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

このシナリオのデプロイ

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

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

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

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

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