Azure App Service の信頼性

2025-05-20

この記事では、 Azure App Service での信頼性のサポートについて説明します。可用性ゾーン、複数リージョンのデプロイ、一時的な障害処理によるリージョン内の回復性について説明します。

Azure App Service は、Web アプリケーション、REST API、およびモバイルバックエンドをホストするための HTTP ベースのサービスです。 Azure App Service は、セキュリティ、負荷分散、自動スケーリング、自動管理の機能を提供して、アプリケーションで Microsoft Azure の力を活用できるようにします。 Azure App Service でアプリケーションワークロードの信頼性と回復性を強化する方法については、App Service の概要に関するページを参照してください。

Azure App Service をデプロイするときに、アプリケーションコードを実行するコンピューティングワーカーを表す App Service プランで複数のインスタンスをプロビジョニングできます。詳細については、「Azure App Service プラン」を参照してください。プラットフォームは、異なる障害ドメイン間にインスタンスをデプロイしようとしますが、インスタンスは可用性ゾーン間で自動的に分散されません。

運用環境デプロイに関する推奨事項

Premium v3/v4 App Service プランを使用します。
ゾーン冗長性を有効にします。これには、Premium v3、Premium v4、または Isolated v2 App Service プランを使用し、プランのインスタンスが少なくとも 2 つ必要です。詳細を表示するには、このページの上部にある適切なレベルを選択してください。

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

一時的な障害

一時的な障害は、コンポーネントにおける短い断続的な障害です。これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、短期間経過すると、自然に修正されます。アプリケーションが、通常は影響を受ける要求を再試行することにより、一時的な障害を処理することが重要です。

クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。詳細については、一時的なエラーへの対処に関するレコメンデーションを参照してください。

Microsoft 提供の SDK は、通常、一時的な障害を処理します。 Azure App Service では独自のアプリケーションをホストするため、次のことを確実に行って、一時的な障害の発生を回避する方法を検討してください。

プランに複数のインスタンスをデプロイします。 Azure App Service は、プラン内のインスタンスに対して自動更新やその他の形式のメンテナンスを実行します。インスタンスが異常になると、サービスは、そのインスタンスを新しい正常なインスタンスに自動的に置き換えることができます。置き換えプロセス中、前のインスタンスが使用できなくなり、しかも新しいインスタンスはトラフィックを処理する準備がまだ整っていないという状態が短時間発生する可能性があります。 App Service プランの複数のインスタンスをデプロイすると、この動作の影響を軽減できます。
デプロイスロットを使用する。 Azure App Service のデプロイスロットを使用すると、ダウンタイムなしでアプリケーションをデプロイできます。デプロイスロットを使用すると、デプロイと構成変更がユーザーに与える影響が最小限に抑えられます。また、デプロイスロットを使用すると、アプリケーションの再起動が行われる可能性も低減します。再起動すると、一時的な障害が発生します。
スケールアップまたはスケールダウンを回避します｡ 代わりに、典型的な負荷の下でパフォーマンス要件を満たすサービスレベルとインスタンスサイズを選びます。トラフィックボリュームの変更を処理するインスタンスのみをスケールアウトします。スケールアップとスケールダウンにより、アプリケーションの再起動がトリガーされることがあります。

可用性ゾーンのサポート

可用性ゾーンとは、各 Azure リージョン内にある、物理的に分離されたデータセンターのグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

詳細については、「可用性ゾーンとは」を参照してください。

Azure 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 プランの場合、基になる仮想マシンインスタンスは可用性ゾーンの障害に対する回復性がありません。そのリージョン内のどのゾーンで障害が発生しても、ダウンタイムが発生する可能性があります。

サポートされているリージョン

ゾーン冗長 App Service プランでは、Premium v2 または v3 レベルを使用する必要があり、可用性ゾーンをサポートする任意のリージョンにデプロイできます。詳細を表示するには、このページの上部にある適切なレベルを選択してください。

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

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

必要条件

Premium v2、Premium v3、または Premium v4 プランの種類を使用する必要があります。

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

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

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

可用性ゾーンのサポートを設定する

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

ゾーン冗長性を持つ新しい 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 以上の容量を使用する必要があります。
```
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
    name: appServicePlanName
    location: location
    sku: {
        name: sku
        capacity: 2
    }
    kind: 'linux'
    properties: {
        reserved: true
        zoneRedundant: true
    }
}
```
移動。 ゾーン冗長性をサポートする既存の 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 プランを作成します。 新しいゾーン冗長 App Service Environment をデプロイするには、「App Service Environment を作成する」を参照してください。

既存の App Service 環境で新しいゾーン冗長 App Service プランを作成するには:
1. App Service Environment でゾーン冗長が有効になっていることを確認します。ゾーン冗長は、App Service Environment がゾーン冗長である場合にのみ、Isolated v2 App Service プランで有効にすることができます。
2. Azure portal でプランをデプロイするときに ゾーン冗長 オプションを選択するか、App Service プランの zoneRedundant プロパティを Azure CLI コマンド、Azure PowerShell コマンド、Bicep ファイル、または Azure Resource Manager テンプレートで 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 以上の容量を使用する必要があります。
```
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
    name: appServicePlanName
    location: location
    hostingEnvironmentProfile: {
        id: '...'
    }
    sku: {
        name: sku
        capacity: 2
    }
    kind: 'linux'
    properties: {
        reserved: true
        zoneRedundant: true
    }
}
```
移動。 ゾーンの冗長性をサポートする既存の 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
```
```
resource asev3 'Microsoft.Web/hostingEnvironments@2020-12-01' = {
    name: aseName
    location: location
    kind: 'ASEV3'
    dependsOn: [
        virtualnetwork
    ] 
    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 以上の容量を使用する必要があります。
```
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
    name: appServicePlanName
    location: location
    hostingEnvironmentProfile: {
        id: '...'
    }
    sku: {
        name: sku
        capacity: 2
    }
    kind: 'linux'
    properties: {
        reserved: true
        zoneRedundant: true
    }
}
```
ゾーン冗長を無効にします。 ゾーン冗長を無効にするには、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 プランの容量 を過剰にプロビジョニング することを検討してください。オーバープロビジョニングにより、ソリューションは、ある程度の容量損失を許容でき、パフォーマンスが低下することなく引き続き機能できます。過剰プロビジョニングの詳細については、「過剰プロビジョニングによる容量の管理」を参照してください。

通常の運用

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

ゾーン間のトラフィックルーティング: 通常の操作中、すべての可用性ゾーンにわたって、使用可能なすべての App Service プランインスタンス間でトラフィックがルーティングされます。
ゾーン間のデータレプリケーション: 通常の操作中、アプリケーションのファイルシステムに格納されている状態はすべてゾーン冗長ストレージに格納され、可用性ゾーン間で同期的にレプリケートされます。

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

このセクションでは、Azure App Service プランがゾーン冗長用に構成されていて、可用性ゾーンの停止が発生した場合に想定される内容について説明します。

検出と対応: App Service プラットフォームは、可用性ゾーンの障害を検出し、対応する役割を担います。ゾーンのフェールオーバーを開始するために何もする必要はありません。
アクティブな要求: 可用性ゾーンが使用できない場合、障害が発生した可用性ゾーン内の App Service プランインスタンスに接続されているすべての要求が終了します。再試行する必要があります。
トラフィックの再ルーティング: ゾーンが使用できなくなると、Azure App Service は、そのゾーンから失われたインスタンスを検出し、新しい置換インスタンスの検出を自動的に試みます。その後、トラフィックは、必要に応じて、新しいインスタンス間に分散されます。

自動スケーリングを構成しており、さらに多くのインスタンスが必要と判断された場合、自動スケーリングから App Service に対してインスタンス追加の要求も発行されます。詳しくは、「Azure App Service でアプリをスケールアップする」を参照してください。

注記

自動スケーリングの動作は、App Service プラットフォームの動作から独立しています。指定する自動スケーリングインスタンス数は、3 の倍数である必要はありません。

重要

ゾーンダウンシナリオでは、追加インスタンスの要求が成功する保証はありません。失われたインスタンスの補填はベストエフォートで実行されます。可用性ゾーンが失われたときに容量を保証する必要がある場合は、ゾーンが失われることを考慮して、App Service プランを作成して構成する必要があります。そのためには、App Service プランの容量をオーバープロビジョニングします。
実行時間以外の動作: ゾーン冗長 App Service プランにデプロイされたアプリケーションは、可用性ゾーンで障害が発生した場合でも、引き続き実行され、トラフィックを処理します。ただし、可用性ゾーンの停止中に、実行時以外の動作が影響を受ける可能性があります。これらの動作には、App Serviceプランのスケーリング、アプリケーションの作成、アプリケーションの構成、およびアプリケーションの発行が含まれます。

フェールバック

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

ゾーン障害のテスト

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

マルチリージョンサポート

Azure App Service は、単一リージョンサービスです。リージョンが使用できなくなった場合、アプリケーションも使用できなくなります。

代替のマルチリージョンソリューション

アプリケーションを、単一リージョンの障害による影響を受けにくくするには、アプリケーションを次の複数のリージョンにデプロイする必要があります。

アプリケーションを各リージョンのインスタンスにデプロイします。
負荷分散とフェールオーバーのポリシーを構成します。
データをリージョン間でレプリケートして、アプリケーションの最後の状態を回復できるようにします。

このアプローチを示すアーキテクチャの例については、以下を参照してください。

マルチリージョンアプリを作成するチュートリアルに従って作業を行うには、「チュートリアル: Azure App Service で高可用性のマルチリージョンアプリを作成する」を参照してください。

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

バックアップ

Basic レベル以上を使用する場合は、App Service のバックアップと復元の機能を使用して、App Service アプリをファイルにバックアップできます。詳細については、「Azure App Service でアプリをバックアップおよび復元する」を参照してください。

この機能は、コードの再デプロイが難しい場合、または状態をディスクに格納する場合に役立ちます。ほとんどのソリューションでは、App Service のバックアップに依存する必要はありません。この記事で説明する他の方法を使用して回復性要件をサポートします。

サービスメンテナンス中の信頼性

Azure App Service では、通常のサービスアップグレードと、その他の形式のメンテナンスが実行されます。アップグレード中に予想される容量が確実に使用可能になるように、プラットフォームはアップグレードプロセス中に App Service プランのインスタンスを自動的に追加します。

ゾーン冗長を有効にします。 App Service プランでゾーン冗長を有効にすると、App Service プラットフォームがロールアウトする更新に対する回復性も向上します。 更新ドメインは、更新 時にオフラインになる仮想マシン (VM) のコレクションで構成されます。更新ドメインは可用性ゾーンに関連付けられています。 App Service プランに複数のインスタンスをデプロイし、プランのゾーン冗長性を有効にすると、インスタンスまたはゾーンが異常になった場合に、アップグレード中に回復性のレイヤーが追加されます。

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

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

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

サービスレベルアグリーメント (SLA)

Azure App Service のサービスレベルアグリーメント (SLA) では、このサービスの期待される可用性について説明しています。また、その可用性に対する期待を達成するために満たす必要がある条件についても説明しています。これらの条件を理解するには、「オンラインサービスのサービスレベルアグリーメント (SLA)」を確認します。

ゾーン冗長 App Service プランをデプロイすると、SLA で既定されたアップタイムの割合が増加します。

Azure での信頼性