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