Azure App Service の信頼性

• Premium v3/v4 App Service プランを使用します。

• ゾーン冗長を有効にします。 ゾーンの冗長性を有効にするための要件については、 可用性ゾーンのサポート要件に関する参照してください。

ゾーンの冗長性を有効にします。そのためには、App Service プランで少なくとも 2 つのインスタンスを使用する必要があります。

ゾーン冗長 App Service プランは、可用性ゾーンをサポートする任意のリージョンにデプロイできます。

App Service Environment v3 の可用性ゾーンをサポートするリージョンについては、「リージョン」を参照してください。

Premium v2-4 プランの種類を使用する必要があります。 詳細を表示するには、このページの上部にある適切なレベルを選択してください。

• Premium v2-4 または Isolated v2 プランの種類を使用し、プランのインスタンスが少なくとも 2 つ必要です。

• 可用性ゾーンは、新しい App Service スケール ユニットでのみサポートされます。 サポートされているリージョンのいずれかを使用している場合でも、使用するスケール ユニットで可用性ゾーンがサポートされていない場合は、ゾーン冗長 App Service プランを作成するときにエラーが発生します。

  割り当てられているスケール ユニットは、App Service プランをデプロイするリソース グループに基づいています。 ワークロードが可用性ゾーンをサポートするスケール ユニットに確実に配置されるようにするには、新しいリソース グループを作成し、新しいリソース グループ内に新しい App Service プランと App Service アプリを作成することが必要になる場合があります。

  App Service プランが可用性ゾーンをサポートするスタンプ上にあるかどうかを確認するには、App Service プランの maximumNumberOfZones プロパティを確認します。 値が 1 より大きい場合、スタンプはゾーンをサポートし、プランでゾーンの冗長性を有効にすることができます。 値が 1 の場合、スケール ユニットは可用性ゾーンをサポートしていないため、ゾーンの冗長性を有効にするために新しいプランをデプロイする必要があります。

  az appservice plan show -n <app-service-plan-name> -g <resource-group-name> --query properties.maximumNumberOfZones
  

• プランには、少なくとも 2 つのインスタンスをデプロイする必要があります。

考慮事項

可用性ゾーンの停止中に、アプリケーションがトラフィックを処理し続ける場合でも、Azure App Service の一部の側面が影響を受ける可能性があります。 これらの動作には、App Serviceプランのスケーリング、アプリケーションの作成、アプリケーションの構成、およびアプリケーションの発行が含まれます。

App Service プランでゾーン冗長を有効にすると、App Service プラットフォームがロールアウトする更新に対する回復性も向上します。詳細については、 サービスメンテナンス中の信頼性に関するページを参照してください。

ゾーン冗長デプロイでのインスタンス配布は、特定の規則に従います。 これらのルールは、アプリのスケールインとスケールアウトに適用されます。

• 最小インスタンス数: App Service プランには、ゾーン冗長性のために少なくとも 2 つのインスタンスが必要です。

• プランでサポートされる最大可用性ゾーン: Azure は、プランで使用できる可用性ゾーンの数を決定します。 プランで使用できる可用性ゾーンの数を表示するには、App Service プランの maximumNumberOfZones プロパティを参照してください。 これは読み取り専用プロパティです。 この値が 1 の場合、App Service プランではゾーンの冗長性はサポートされません。 maximumNumberOfZones の値が 1 より大きい場合は、App Service プランをゾーン冗長用に構成できます。

  az appservice plan show -n <app-service-plan-name> -g <resource-group-name> --query properties.maximumNumberOfZones
  

• インスタンスの配布: ゾーン冗長が有効になっている場合、プラン インスタンスは複数の可用性ゾーンに自動的に分散されます。 ディストリビューションは、次の規則に基づいています。

  • maximumNumberOfZones より大きい容量 (インスタンスの数) を指定し、インスタンスの数が maximumNumberOfZones で割り切れる場合、インスタンスは均等に分散されます。
  • 残りのインスタンスは、残りのゾーンに分散されます。
  • App Service プラットフォームは、ゾーン冗長 App Service プランにインスタンスを割り当てるときに、基になる Azure 仮想マシン スケール セットが提供するベスト エフォート ゾーン分散を使用します。 App Service プランは、各ゾーンに同じ数の VM がある場合、または他のすべてのゾーンと比較して、VM が 1 台多いか、1 台少ない場合にバランスがとれています。 詳細については、「ゾーン バランス」を参照してください。

• 物理ゾーンの配置: 各 App Service プラン インスタンスに使用されている 物理可用性ゾーン を表示できます。 REST API を使用して、各インスタンスの physicalZone 値を返します。

  az rest --method get --url https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/sites/{appName}/instances?api-version=2024-04-01
  

ゾーン冗長として構成されていない App Service プランの場合、基になる VM インスタンスは可用性ゾーンの障害に対する回復性がありません。 そのリージョン内のどのゾーンで障害が発生しても、ダウンタイムが発生する可能性があります。

コスト

App Service Premium v2-v4 プランを使用する場合、App Service プランに 2 つ以上のインスタンスがある限り、可用性ゾーンの有効化に関連する追加コストは発生しません。 App Service プラン SKU、指定した容量、および自動スケーリング条件に基づいてスケーリングするインスタンスに基づいて課金されます。

可用性ゾーンを有効にしたが、容量が 2 未満を指定した場合、プラットフォームは最小インスタンス数を 2 に設定します。 プラットフォームでは、これら 2 つのインスタンスに対して課金されます。

App Service Isolated v2 プランを使用する場合、App Service プランに 2 つ以上のインスタンスがある限り、可用性ゾーンの有効化に関連する追加コストは発生しません。 App Service プラン SKU、指定した容量、および自動スケーリングの条件に基づいてスケーリングするインスタンスに基づいて課金されます。

可用性ゾーンを有効にしたが、容量が 2 未満を指定した場合、プラットフォームは最小インスタンス数を 2 に設定します。 プラットフォームでは、これら 2 つのインスタンスに対して課金されます。

新しいゾーン冗長 App Service プランをデプロイするには、 Premium v2-4 プランの種類を使用する必要があります。 詳細を表示するには、このページの上部にある適切なレベルを選択してください。

• ゾーン冗長性を持つ新しい App Service プランを作成します。 新しいゾーン冗長 App Service プランをデプロイするには、Azure portal でプランをデプロイするときにゾーン冗長オプションを選択するか、Azure CLI コマンド、Azure PowerShell コマンド、Bicep ファイル、または Azure Resource Manager テンプレートでzoneRedundantするように App Service プランのtrue プロパティを設定します。

  • Azure CLI
  • 二頭筋

  az appservice plan create -g MyResourceGroup -n MyPlan --zone-redundant --number-of-workers 2 --sku P1V3
  

  注記

  Azure CLI を使用して zone-redundant プロパティを変更する場合は、インスタンスの数である --number-of-workers プロパティを指定し、2 以上の容量を使用する必要があります。

• 既存の App Service プランをゾーン冗長に移行します。 ゾーン冗長性をサポートする既存の App Service プランがある場合 (使用可能なゾーンの最大数が 1 を超える場合)、App Service プランの zoneRedundant プロパティを Azure CLI、Bicep ファイル、または Resource Manager テンプレートで true するように設定することで、ゾーンの冗長性を有効にすることができます。

  az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=true sku.capacity=2
  

  注記

  Azure CLI を使用して zoneRedundant プロパティを変更する場合は、インスタンスの数である sku.capacity プロパティを指定し、2 以上の容量を使用する必要があります。

  可用性ゾーンをサポートしていないプランまたはスタンプを使用している場合は、新しいリソース グループに新しい App Service プランを作成して、ゾーンをサポートする App Service フットプリントに追加する必要があります。

  注記

  App Service プランのゾーン冗長状態の変更は、ほぼ瞬時に行われます。 プロセス中にダウンタイムやパフォーマンスの問題が発生することはありません。

• ゾーン冗長を無効にします。 ゾーン冗長を無効にするには、App Service プランの zoneRedundant プロパティを false に設定するか、Azure CLI を使用します。

  az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=false sku.capacity=1
  

  注記

  Azure CLI を使用して zoneRedundant プロパティを無効にする場合は、 sku.capacity プロパティを指定する必要があります。それ以外の場合、値の既定値は 1 になります。

• ゾーン冗長性を持つ新しい App Service プランを作成します。

  1. 既存のゾーン冗長 App Service Environment がない場合は、新しいゾーン冗長 App Service Environment をデプロイします。 App Service 環境を作成する方法の詳細については、「 App Service Environment の作成」を参照してください。

  2. Azure portal で App Service プランを作成するには、[ ゾーン冗長] を選択します。 Azure CLI コマンド、Azure PowerShell コマンド、Bicep ファイル、または Resource Manager テンプレートを使用してプランを作成するには、次のサンプル コードのように、App Service プランの zoneRedundant プロパティを true に設定します。

  • Azure CLI
  • 二頭筋

  az appservice plan create -g MyResourceGroup -n MyPlan --app-service-environment MyAse --zone-redundant --number-of-workers 2 --sku I1V2
  

  注記

  Azure CLI を使用して zoneRedundant プロパティを変更する場合は、インスタンスの数である number-of-workers プロパティを指定し、2 以上の容量を使用する必要があります。

• 既存の App Service プランをゾーン冗長に移行 するゾーンの冗長性をサポートする既存の App Service Environment または Isolated v2 App Service プランがある場合は、いつでもゾーン冗長を有効にすることができます。 App Service Environment のゾーン冗長を有効にするには、 zoneRedundant プロパティを true に設定するか、Azure CLI を使用します。

  • Azure CLI
  • 二頭筋

  az resource update --ids /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/hostingEnvironments/{aseName} --set properties.zoneRedundant=true
  

  注記

  App Service Environment のゾーン冗長状態を変更すると、完了までに 12 から 24 時間かかるアップグレードが開始されます。 アップグレード プロセス中に、ダウンタイムやパフォーマンスの問題は発生しません。

  Isolated v2 App Service プランの場合、App Service Environment がゾーン冗長の場合、App Service プランをゾーン冗長にすることができます。 各 App Service プランには、独自の独立したゾーン冗長設定があります。つまり、App Service 環境でゾーン冗長プランと非ゾーン冗長プランを組み合わせることができます。 Isolated v2 App Service プランでゾーン冗長を有効にするには、App Service プランの zoneRedundant プロパティを true に設定するか、Azure CLI を使用します。

  • Azure CLI
  • 二頭筋

  az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=true sku.capacity=2
  

  注記

  Azure CLI を使用して zoneRedundant プロパティを変更する場合は、インスタンスの数である sku.capacity プロパティを指定し、2 以上の容量を使用する必要があります。

• ゾーン冗長を無効にします。 ゾーン冗長を無効にするには、App Service プランまたは App Service Environment zoneRedundant プロパティを false に設定するか、Azure CLI を使用します。

  az resource update --ids /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/hostingEnvironments/{aseName} --set properties.zoneRedundant=false
  
  az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=false sku.capacity=1
  

  注記

  Azure CLI を使用して zoneRedundant プロパティを無効にする場合は、 sku.capacity プロパティを指定する必要があります。それ以外の場合、値の既定値は 1 になります。

容量の計画と管理

可用性ゾーンの障害に備えて、App Service プランの容量 を過剰にプロビジョニング することを検討してください。 過剰プロビジョニングを使用すると、ソリューションはある程度の容量損失を許容し、パフォーマンスが低下することなく機能し続けられます。 詳細については、「 過剰プロビジョニングによる容量の管理」を参照してください。

通常の運用

次のセクションでは、App Service プランがゾーン冗長用に構成され、すべての可用性ゾーンが運用可能な場合に想定される内容について説明します。

• ゾーン間のトラフィック ルーティング: 通常の操作中、すべての可用性ゾーンにわたって、使用可能なすべての App Service プラン インスタンス間でトラフィックがルーティングされます。

• ゾーン間のデータ レプリケーション: 通常の操作中、アプリケーションのファイル システムに格納されている状態はすべてゾーン冗長ストレージに格納され、可用性ゾーン間で同期的にレプリケートされます。

ゾーンダウン エクスペリエンス

可用性ゾーンの停止中に、アプリケーションがトラフィックを処理し続ける場合でも、Azure App Service の一部の側面が影響を受ける可能性があります。 これらの動作には、App Serviceプランのスケーリング、アプリケーションの作成、アプリケーションの構成、およびアプリケーションの発行が含まれます。

次のセクションでは、App Service プランがゾーン冗長用に構成されていて、1 つ以上の可用性ゾーンが使用できない場合に想定される内容について説明します。

• 検出と応答: App Service プラットフォームは、可用性ゾーンのエラーを自動的に検出し、応答を開始します。 ゾーンのフェールオーバーを開始するために手動による介入は必要ありません。

• アクティブな要求: 可用性ゾーンが使用できない場合、障害が発生した可用性ゾーン内の App Service プラン インスタンスに接続されているすべての要求が終了します。 再試行する必要があります。

• トラフィックの再ルーティング: ゾーンが使用できない場合、App Service はそのゾーンから失われたインスタンスを検出し、新しい代替インスタンスの検索を自動的に試みます。 置換が見つかると、必要に応じて新しいインスタンス間でトラフィックが分散されます。

  自動スケールが構成されていて、さらに多くのインスタンスが必要であると判断された場合は、App Service に要求を発行してそれらのインスタンスを追加します。 自動スケールの動作は、App Service プラットフォームの動作とは無関係に動作します。つまり、インスタンス数の指定は 2 つの倍数である必要はありません。 詳細については、 App Service でのアプリのスケールアップ と 自動スケールの概要に関するページを参照してください。

  重要

  ゾーンダウン シナリオでは、追加インスタンスの要求が成功する保証はありません。 失われたインスタンスのバックフィルは、ベスト エフォートベースで行われます。 可用性ゾーンが失われたときに保証された容量が必要な場合は、ゾーンの損失を考慮して App Service プランを作成して構成する必要があります。 これを実現するには、 App Service プランの容量を過剰にプロビジョニングします。

• 実行時間以外の動作: ゾーン冗長 App Service プランにデプロイされたアプリケーションは、可用性ゾーンで障害が発生した場合でも、引き続き実行され、トラフィックを処理します。 ただし、可用性ゾーンの停止中に、実行時以外の動作が影響を受ける可能性があります。 これらの動作には、App Serviceプランのスケーリング、アプリケーションの作成、アプリケーションの構成、およびアプリケーションの発行が含まれます。

フェールバック

可用性ゾーンが復旧すると、App Service によって、復旧された可用性ゾーンにインスタンスが自動的に作成され、他の可用性ゾーンで作成された一時インスタンスが削除され、インスタンス間のトラフィックが通常どおりにルーティングされます。

ゾーン障害のテスト

App Service プラットフォームは、ゾーン冗長 App Service プランのトラフィック ルーティング、フェールオーバー、フェールバックを管理します。 この機能は完全に管理されているため、可用性ゾーンの障害プロセスを開始または検証する必要はありません。

この方法に関連するリソースを次に示します。

• 参照アーキテクチャ: 高可用性マルチリージョン Web アプリケーション

• 検討する方法

• チュートリアル: App Service で高可用性マルチリージョン アプリを作成する

このアーキテクチャを示すアプローチの例については、「 App Service Environment を使用した高可用性エンタープライズデプロイ」を参照してください。

詳細については、 Azure App Service の定期的な計画メンテナンスに関するページを参照してください。

アップグレード サイクルをカスタマイズします。 App Service Environment のアップグレード サイクルをカスタマイズします。 ワークロードに対するアップグレードの影響を検証する必要がある場合は、変更が実稼働インスタンスにロールアウトされる前に非運用インスタンスで検証とテストを実行できるように、手動アップグレードを有効にすることを検討してください。

メンテナンス設定の詳細については、「 App Service Environment の計画メンテナンスのアップグレード設定」を参照してください。