この記事では、 Azure App Service での信頼性のサポートについて説明します。 可用性ゾーンと複数リージョンのデプロイによるリージョン内の回復性について説明します。 App Service は、Web アプリケーション、REST API、モバイル バックエンドをホストするための HTTP ベースのサービスです。 App Service は Microsoft Azure と統合され、アプリケーションのセキュリティ、負荷分散、自動スケーリング、および自動管理が提供されます。
App Service Environment での信頼性のサポートの詳細については、「App Service Environment の信頼性」をご覧ください。
Azure を使用する場合、 信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービス内でこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を満たすために必要な機能を選択する責任があります。
運用環境デプロイに関する推奨事項
ソリューションの信頼性要件をサポートするために App Service をデプロイする方法と、信頼性がアーキテクチャの他の側面にどのように影響するかについては、「Azure Well-Architected Framework での App Service (Web Apps) のアーキテクチャのベスト プラクティス」をご覧ください。
信頼性アーキテクチャの概要
App Service Web アプリを作成するときは、アプリを実行する App Service プランを指定します。
App Service プランでは、Web アプリを実行するコンピューティング リソースのセットを定義します。 すべての Web アプリは、プラン内で実行する必要があります。 複数の VM インスタンス (worker とも呼ばれます) で実行するようにプランをスケーリングできます。 これらのインスタンスは、アプリ コードを実行するコンピューティング リソースを提供します。 1 つの App Service プランで複数のアプリをホストできます。 すべてのアプリは、同じ VM インスタンスの共有セットで実行されます。
App Service には、次の冗長機能があります。
障害ドメイン間の分散: プラットフォーム レベルでは、Azure は App Service プランの VM インスタンスを Azure リージョン内の障害ドメインに自動的に分散します。 このディストリビューションでは、共通の電源とネットワーク スイッチを共有する VM をグループ化することで、ローカライズされたハードウェア障害のリスクを最小限に抑えます。
可用性ゾーン間の分散: サポートされている App Service プランでゾーン冗長を有効にした場合、Azure はリージョン内の可用性ゾーン間でインスタンスを分散します。 この構成では、ゾーンの停止が発生した場合の回復性が向上します。 ゾーン冗長の詳細については、「可用性ゾーンのサポート」をご覧ください。
アプリのスケーリング: 複数の VM インスタンスを実行するように App Service プランを構成すると、プラン内のすべてのアプリが既定ですべてのインスタンスで実行されます。 自動スケーリング用にプランを構成した場合、すべてのアプリは自動スケーリング設定に基づいてまとめてスケールアウトされます。 ただし、 アプリごとのスケーリングを使用して、特定のアプリを実行するプラン インスタンスの数をカスタマイズできます。
スケール ユニット:内部的には、App Service は、スタンプまたは Web スペースとも呼ばれるスケール ユニットと呼ばれるプラットフォーム インフラストラクチャで実行されます。 スケール ユニットには、コンピューティング、ストレージ、ネットワーク、負荷分散など、App Service のホストと実行に必要なすべてのコンポーネントが含まれます。 Azure はスケール ユニットを管理して、バランスの取れたワークロードの分散を確保し、定期的なメンテナンスを実行し、プラットフォーム全体の信頼性を維持します。
一部の機能は、特定のスケール ユニットにのみ適用される場合があります。 たとえば、一部の App Service スケール ユニットではゾーン冗長がサポートされますが、同じリージョン内の他のスケール ユニットではサポートされない場合があります。
一時的な障害
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションが一時的な障害に対処できることが重要です。これは通常、影響を受けた要求を再試行することで対処します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
Microsoft 提供の SDK は、通常、一時的な障害を処理します。 App Service で独自のアプリケーションをホストするため、一時的な障害の可能性を減らす手順を実行します。
プランに複数のインスタンスをデプロイします。 App Service では、プラン内のインスタンスに対して、自動更新やその他の形式のメンテナンスが実行されます。 インスタンスが異常になると、サービスは、そのインスタンスを新しい正常なインスタンスに自動的に置き換えることができます。 置換プロセス中に、前のインスタンスが使用できず、新しいインスタンスがトラフィックを処理する準備ができていない場合、短期間が発生する可能性があります。 これらの影響を軽減するには、App Service プランの複数のインスタンスをデプロイします。
デプロイ スロットを使用する。 App Service デプロイ スロット を使用すると、アプリケーションのダウンタイムなしのデプロイが可能になります。 デプロイ スロットを使用して、ユーザーのデプロイと構成の変更の影響を最小限に抑えます。 デプロイ スロットを使用すると、アプリケーションが再起動する可能性も低くなります。 アプリケーションを再起動すると、一時的なエラーが発生します。
スケールアップやスケールダウンは避けてください。 これらの操作により、各インスタンスに割り当てられている CPU、メモリ、その他のリソースが変更され、アプリケーションの再起動をトリガーできます。 代わりに、典型的な負荷の下でパフォーマンス要件を満たすサービス レベルとインスタンス サイズを選びます。 スケールアウトとスケールインを行うには、トラフィック量の変化を処理するインスタンスを動的に追加および削除します。
可用性ゾーンのサポート
可用性ゾーン は、各 Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
Premium v2 から v4 レベルの場合は、App Service をゾーン冗長として構成できます。つまり、リソースは複数の可用性ゾーンに分散されます。 複数のゾーンに分散することで、運用ワークロードで回復性と信頼性を実現できます。 App Service プランでゾーン冗長を構成すると、そのプランを使用するすべてのアプリがゾーン冗長になります。
リージョンのサポート
App Service Premium v2 および v3 プランの場合、ゾーンの冗長性は、 可用性ゾーンをサポートするすべてのリージョンでサポートされます。
App Service Premium v4 プランのゾーン冗長を有効にするには:
必要条件
ゾーン冗長を有効にするには、次の要件を満たす必要があります。
プランの種類:Premium v2 から v4 プランの種類を使用します。
インスタンスの最小数: プランに少なくとも 2 つのインスタンスをデプロイします。
スケール ユニット: アプリは、可用性ゾーンをサポートするスケール ユニットにデプロイする必要があります。 プランで使用するスケール ユニットは直接制御しません。 代わりに、App Service プランを作成すると、プランのリソース グループに基づいてスケール ユニットにプランが割り当てられます。 App Service プランのスケール ユニットがゾーン冗長をサポートしているかどうかを確認するには、「App Service プランのゾーン冗長サポートを確認する」をご覧ください。
App Service プランがゾーン冗長をサポートしていないスケール ユニット上にある場合、プランでゾーン冗長を有効にすることはできません。 代わりに、 別のスケール ユニットの新しいプランにアプリを再デプロイする必要があります。
ゾーン間でのインスタンスの分散
ゾーン冗長 App Service プランを作成すると、Azure はプランのインスタンスをリージョン内の可用性ゾーンに分散します。 この分散により、1 つのゾーンで障害が発生した場合でも、アプリを引き続き使用できるようになります。
ゾーン冗長デプロイでのインスタンス配布は、特定の規則に従います。 これらのルールは、アプリのスケール インとスケールアウトにも適用されます。
最小インスタンス数: App Service プランには、ゾーン冗長性のために少なくとも 2 つのインスタンスが必要です。
プランでサポートされる最大可用性ゾーン: Azure は、プランで使用できる可用性ゾーンの数を決定します。これは maximumNumberOfZones と呼ばれます。 特定のプランで使用できる可用性ゾーンの数を表示するには、「App Service プランのゾーン冗長サポートを確認する」をご覧ください。
インスタンスの分散: ゾーン冗長が有効になっている場合、Azure はプラン インスタンスを複数の可用性ゾーンに自動的に分散します。 ディストリビューションは、次の規則に基づいています。
インスタンスの数が maximumNumberOfZones を超えて均等に分割された場合、Azure はインスタンスをゾーン間で均等に分散します。
インスタンスの数が均等に分割されない場合、Azure は残りのインスタンスを残りのゾーンに分散します。
App Service プラットフォームは、ゾーン冗長 App Service プランにインスタンスを割り当てるときに、基になる Azure 仮想マシン スケール セットが提供するベスト エフォート ゾーン分散を使用します。 プランがバランスしているとは、各ゾーンに配置されている VM の数がすべて同じであるか、または他のゾーンとの差が最大でも 1 台以内である状態を指します。 詳細については、「ゾーン バランス」を参照してください。
物理ゾーンの配置: 各 App Service プラン インスタンスに使用されている 物理可用性ゾーン を表示できます。 詳細については、「 App Service プランの物理ゾーンを表示する」を参照してください。
考慮事項
Premium v2 から v4 プランの場合、可用性ゾーンの停止は、アプリケーションが引き続きトラフィックを処理する場合でも、Azure App Service の一部の側面に影響を与える可能性があります。 これらの動作には、App Serviceプランのスケーリング、アプリケーションの作成、アプリケーションの構成、およびアプリケーションの発行が含まれます。
App Service Premium v2 から v4 プランでゾーン冗長を有効にすると、プラットフォームの更新時の回復性も向上します。 詳細については、「サービス メンテナンス中の信頼性」をご覧ください。
ゾーン冗長として構成されていない App Service プランの場合、基になる仮想マシン (VM) インスタンスは、可用性ゾーンの障害に対して回復性がありません。 そのリージョン内のどのゾーンで障害が発生しても、ダウンタイムが発生する可能性があります。
コスト
App Service Premium v2 から v4 プランを使用する場合、2 つ以上のインスタンスがある場合、可用性ゾーンを有効にしてもコストは追加されません。 料金は、App Service プラン SKU、指定した容量、自動スケーリング条件に基づいてスケーリングする任意のインスタンスに基づきます。
可用性ゾーンを有効にしたが、容量が 2 未満を指定した場合、プラットフォームは最小インスタンス数を 2 に設定します。 プラットフォームでは、これら 2 つのインスタンスに対して課金されます。
可用性ゾーンのサポートを設定する
新しいゾーン冗長のアプリサービスプランを作成してください。 詳細については、「ゾーン冗長を含む新しい App Service プランを作成する」をご覧ください。
既存の App Service プランでゾーン冗長を有効または無効にします。 詳細については、「既存の App Service プランのゾーン冗長を設定する」をご覧ください。
容量の計画と管理
可用性ゾーンの障害に備えて、App Service プランの容量 を過剰にプロビジョニング することを検討してください。 このアプローチにより、ソリューションは容量損失を許容し、パフォーマンスが低下することなく機能し続けられます。 詳細については、「過剰プロビジョニングを使用して容量を管理する」をご覧ください。
通常の運用
次の一覧では、App Service プランがゾーン冗長用に構成され、すべての可用性ゾーンが運用可能な場合に想定される内容について説明します。
ゾーン間のトラフィック ルーティング: 通常の操作中、トラフィックは、すべての可用性ゾーンにわたるすべての使用可能な App Service プラン インスタンス間でルーティングされます。
ゾーン間のデータ レプリケーション: 通常の操作中、アプリケーションのファイル システムに格納されている状態はすべてゾーン冗長ストレージに格納され、可用性ゾーン間で同期的にレプリケートされます。
ゾーンダウン エクスペリエンス
可用性ゾーンの停止は、アプリケーションが引き続きトラフィックを処理する場合でも、App Service の一部の側面に影響を与える可能性があります。 これらの動作には、App Serviceプランのスケーリング、アプリケーションの作成、アプリケーションの構成、およびアプリケーションの発行が含まれます。
次の一覧では、App Service プランがゾーン冗長用に構成され、1 つ以上の可用性ゾーンが使用できない場合に想定される内容について説明します。
検出と応答: App Service プラットフォームは、可用性ゾーンのエラーを自動的に検出し、応答を開始します。 ゾーンのフェールオーバーを開始するために手動による介入は必要ありません。
通知: ゾーン障害イベントは、Azure Service Health と Azure Resource Health を使用して監視できます。 これらのサービスにアラートを設定して、ゾーン レベルの問題に関する通知を受け取ります。
アクティブな要求: 障害のある可用性ゾーン内の App Service プラン インスタンスに接続する進行中の要求はすべて終了します。 これらの要求を再試行します。
トラフィックの再ルーティング: App Service は、そのゾーンから失われたインスタンスを検出し、新しい置換インスタンスの検索を試みます。 App Service は、置換を見つけた後、必要に応じて新しいインスタンス間でトラフィックを分散します。
自動スケーリングが構成され、さらに多くのインスタンスが必要であると判断された場合は、App Service からインスタンスを要求します。 自動スケーリングの動作は、App Service プラットフォームの動作とは無関係に動作します。 そのため、インスタンス数の指定は、2 つの倍数である必要はありません。 詳細については、 App Service でのアプリのスケールアップ と 自動スケールの概要に関するページを参照してください。
重要
Azure では、ゾーンダウン シナリオで、より多くのインスタンスの要求が成功することを保証しません。 プラットフォームは、失われたインスタンスをベストエフォート方式でバックフィルしようとします。 可用性ゾーンの障害時に保証された容量が必要な場合は、容量を過剰にプロビジョニングして、ゾーン損失を考慮するように App Service プランを作成して構成します。
実行時間以外の動作: ゾーン冗長 App Service プランのアプリケーションは、可用性ゾーンで障害が発生した場合でも、引き続き実行され、トラフィックを処理します。 ただし、可用性ゾーンの停止中に、実行時以外の動作が影響を受ける可能性があります。 これらの動作には、App Serviceプランのスケーリング、アプリケーションの作成、アプリケーションの構成、およびアプリケーションの発行が含まれます。
ゾーンの回復
可用性ゾーンが復旧すると、App Service によって、復旧された可用性ゾーンにインスタンスが自動的に作成され、他の可用性ゾーンで作成された一時インスタンスが削除され、インスタンス間のトラフィックが通常どおりにルーティングされます。
ゾーンエラーのテスト
App Service プラットフォームは、ゾーン冗長 App Service プランのトラフィック ルーティング、フェールオーバー、フェールバックを管理します。 この機能はフル マネージドであるため、可用性ゾーンの障害プロセスを開始または検証する必要はありません。
複数リージョンのサポート
App Service は単一リージョン のサービスです。 リージョンが使用できなくなった場合、アプリケーションも使用できなくなります。
代替の複数リージョン アプローチ
アプリケーションに影響を与える単一リージョンの障害のリスクを軽減するために、複数のリージョンにプランをデプロイできます。 次の手順は、回復性の強化に役立ちます。
- アプリケーションを各リージョンのプランにデプロイします。
- 負荷分散とフェールオーバーのポリシーを構成します。
- 最後のアプリケーションの状態を回復できるように、リージョン間でデータをレプリケートします。
次の関連リソースについて考えてみましょう。
バックアップ
Basic レベル以上を使用する場合は、App Service のバックアップと復元の機能を使用して、App Service アプリをファイルにバックアップできます。
これらの機能は、コードの再デプロイが困難な場合や、ディスクに状態を格納する場合に役立ちます。 ほとんどのソリューションでは、バックアップのみに依存しないでください。 代わりに、このガイドの他の機能を使用して回復性の要件をサポートしてください。 ただし、バックアップでは、他の方法では行わないリスクから保護されます。
重要
2028 年 3 月 31 日以降、Azure App Service のカスタム バックアップでは、リンクされたデータベースのバックアップはサポートされなくなります。 詳細については、「 リンクされたデータベース バックアップの非推奨化 」を参照してください。
代わりに、リンクされたデータベースのネイティブ バックアップおよび復元ツールを使用してください。 詳細については、「 App Service でのアプリのバックアップと復元」を参照してください。
サービスメンテナンス中の信頼性
App Service では、通常のサービス アップグレードやその他のメンテナンス タスクが実行されます。 アップグレード中に予想される容量を維持するために、プラットフォームはアップグレード プロセス中に App Service プランのインスタンスを自動的に追加します。
ゾーン冗長を有効にします。 App Service プランでゾーン冗長を有効にすると、プラットフォームの更新時の回復性も向上します。 更新ドメインは、更新中にオフラインになる VM のコレクションで構成され、可用性ゾーンにマップされます。 App Service プランに複数のインスタンスをデプロイし、プランのゾーン冗長を有効にすると、アップグレード中にインスタンスまたはゾーンが異常になった場合に、回復性のレイヤーが追加されます。
詳細については、「App Service の定期的な計画メンテナンス」と「App Service の定期的なメンテナンス、再起動、ダウンタイム」をご覧ください。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) には、各サービスの期待される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について記載されています。 詳細については、 オンライン サービスの SLA を参照してください。
ゾーン冗長 App Service プランをデプロイすると、SLA で既定されたアップタイムの割合が増加します。