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