Azure App Service の信頼性
この記事では、可用性ゾーンによるリージョン内の回復性とマルチリージョン デプロイに関する情報の両方を含め、Azure App Service の信頼性のサポートについて説明します。
回復性は、お客様と Microsoft の間の共同責任であるため、この記事では、お客様が、ニーズに合った回復性があるソリューションを構築する方法についても説明します。
Azure App Service は、Web アプリケーション、REST API、およびモバイル バックエンドをホストするための HTTP ベースのサービスです。 Azure App Service は、セキュリティ、負荷分散、自動スケーリング、自動管理の機能を提供して、アプリケーションで Microsoft Azure の力を活用できるようにします。 アプリケーションのワークロードの信頼性と回復性を Azure App Service によって強化する方法については、「App Service を使用する理由」を参照してください。
Azure App Service をデプロイすると、App Service プラン (アプリケーション コードを実行するコンピューティング ワーカー) の複数のインスタンスを作成できます。 プラットフォームは、異なる障害ドメイン間にインスタンスをデプロイしようとしますが、インスタンスは可用性ゾーン間で自動的に分散されません。
運用環境デプロイに関する推奨事項
運用環境のデプロイの場合は、以下をお勧めします。
- Premium v3 App Service プランを使用します。
- ゾーン冗長を有効にします。このためには、少なくとも 3 つのインスタンスを使用する App Service プランが必要です。
- ゾーン冗長を有効にします。このためには、少なくとも 3 つのインスタンスを使用する App Service プランが必要です。
一時的な障害
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 短期間経過すると、自然に修正されます。 アプリケーションが、通常は影響を受ける要求を再試行することにより、一時的な障害を処理することが重要です。
すべてのクラウド ホステッド アプリケーションは、クラウド ホステッド API、データベース、その他のコンポーネントと通信するときに、Azure の一時的な障害処理ガイダンスに従う必要があります。 一時的な障害の処理の詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
通常、一時的な障害は、Microsoft が提供する SDK によって処理されますが、Azure App Service では独自のアプリケーションをホストするため、次のことを確実に行って、一時的な障害の発生を回避する方法を考慮する必要があります。
プランの複数のインスタンスをデプロイする。 Azure App Service では、プランのインスタンスに対して、自動更新やその他の種類のメンテナンスを実行します。 インスタンスが異常になると、サービスは、そのインスタンスを新しい正常なインスタンスに自動的に置き換えることができます。 置き換えプロセス中、前のインスタンスが使用できなくなり、しかも新しいインスタンスはトラフィックを処理する準備がまだ整っていないという状態が短時間発生する可能性があります。 App Service プランの複数のインスタンスをデプロイすると、この動作の影響を軽減できます。
デプロイ スロットを使用する。 Azure App Service のデプロイ スロットを使用すると、ダウンタイムなしでアプリケーションをデプロイできます。 デプロイ スロットを使用すると、デプロイと構成変更がユーザーに与える影響が最小限に抑えられます。 また、デプロイ スロットを使用すると、一時的な障害の原因となるアプリケーションの再起動が行われる可能性も低減します。
スケールアップまたはスケールダウンを回避します｡ 代わりに、典型的な負荷の下でパフォーマンス要件を満たすサービス レベルとインスタンス サイズを選びます。 トラフィック ボリュームの変更を処理するインスタンスのみをスケールアウトします。 スケールアップとスケールダウンにより、アプリケーションの再起動がトリガーされる可能性があることを考慮します。
可用性ゾーンのサポート
可用性ゾーンとは、各 Azure リージョン内にある、物理的に分離されたデータセンターのグループです。 1 つのゾーンで障害が発生した際には、サービスは残りのゾーンのいずれかにフェールオーバーできます。
Azure の可用性ゾーンの詳細については、「可用性ゾーンとは?」を参照してください。
Azure App Service は、"ゾーン冗長" として構成できます。つまり、リソースが複数の可用性ゾーン間に分散されます。 複数のゾーンに分散すると、運用ワークロードで回復性と信頼性を実現するのに役立ちます。 可用性ゾーンのサポートは、App Service プランのプロパティです。
ゾーン冗長デプロイでのインスタンスの分散は、アプリのスケールインとスケールアウトであっても、次のルール内で決定されます。
- App Service プランの最小インスタンス数は 3 つです。
- 3 を超える容量を指定し、インスタンスの数が 3 で割り切れる場合は、インスタンスが均等に分散されます。
- 3*N を超えたインスタンス数は、残りの 1 つまたは 2 つのゾーンに分散されます。
App Service プラットフォームによってインスタンスがゾーン冗長 App Service プランに割り当てられると、基になる Azure Virtual Machine Scale Sets によって提供されるベスト エフォートのゾーン負荷分散が使用されます。 各ゾーンの VM の数が、その App Service プランで使用される他のすべてのゾーンと同じである場合、または 1 個多いか、1 個少ない場合、App Service プランは "バランスが取れている" ことになります。
ゾーン冗長として構成されていない App Service プランの場合、VM インスタンスは、可用性ゾーンの障害に対して回復性がありません。 このようなプランでは、そのリージョン内のどのゾーンでも、停止中にダウンタイムが発生する可能性があります。
サポートされているリージョン
ゾーン冗長を構成するには、Premium v2 または Premium v3 プラン タイプのどちらかを使用する必要があります。
- 可用性ゾーンは、新しい App Service 占有領域でのみサポートされます。 使用しているのがサポートされているリージョンのいずれかであっても、ご利用のリソース グループで可用性ゾーンがサポートされていない場合はエラーが発生します。 ご利用のワークロードが、可用性ゾーンをサポートしているスタンプに確実に配置されるようにするには、新しいリソース グループ、App Service プラン、および App Service を作成することが必要になる場合があります。
- プランのインスタンスを少なくとも 3 つデプロイする必要があります。
App Service Environment v3 の可用性ゾーンをサポートするリージョンについては、「リージョン」を参照してください。
要件
::: zone-end
- 可用性ゾーンは、新しい App Service 占有領域でのみサポートされます。 使用しているのがサポートされているリージョンのいずれかであっても、ご利用のリソース グループで可用性ゾーンがサポートされていない場合はエラーが発生します。 ご利用のワークロードが、可用性ゾーンをサポートしているスタンプに確実に配置されるようにするには、新しいリソース グループ、App Service プラン、および App Service を作成することが必要になる場合があります。
- プランのインスタンスを少なくとも 3 つデプロイする必要があります。
考慮事項
ゾーン冗長 App Service プランにデプロイされたアプリケーションは、同じリージョン内の複数のゾーンで停止が発生した場合でも引き続き実行され、トラフィックを処理します。 ただし、ランタイム以外の動作 (App Service プランのスケーリング、アプリケーションの作成、アプリケーションの構成、アプリケーションの公開など) は依然として、可用性ゾーンの停止中に影響を受ける可能性があります。 App Service プランのゾーン冗長で確保されるのは、デプロイされたアプリケーションの継続的なアップタイムのみです。
コスト
App Service Premium v2 または Premium v3 プランを使用している場合、App Service プラン内に 3 つ以上のインスタンスがある限り、可用性ゾーンの有効化に関連する追加コストは発生しません。 ご利用の App Service プラン SKU、指定した容量、および自動スケーリング条件に基づいてスケーリングする任意のインスタンスに基づいて課金されます。 可用性ゾーンを有効にした場合、容量として 3 未満を指定すると、プラットフォームによって、最小インスタンス数として 3 が適用され、これらの 3 つのインスタンスに対して課金されます。
App Service Environment v3 には、ゾーン冗長のための特定の価格モデルがあります。 App Service Environment v3 の価格情報については、「価格」を参照してください。
可用性ゾーン構成のサポート
新しいゾーン冗長 Azure App Service プランをデプロイするには、プランをデプロイするときに、[ゾーン冗長] オプションを選択します。
新しいゾーン冗長 App Service Environment をデプロイするには、「App Service Environment を作成する」を参照してください。
ゾーン冗長は、新しい App Service プランを作成するときにのみ構成できます。 ゾーン冗長ではない既存の App Service プランがある場合、それを新しいゾーン冗長プランに置き換える必要があります。 既存の App Service プランを、可用性ゾーンを使用するように変換することはできません。 同様に、既存の App Service プランでゾーン冗長を無効にすることはできません。
容量の計画と管理
可用性ゾーンの障害に備えるためには、サービスの容量を過剰にプロビジョニングして、ソリューションが容量の 1/3 の損失を許容し、ゾーン全体の障害発生時にパフォーマンスを低下させることなく機能し続けられるようにする必要があります。 プラットフォームによって VM が 3 つのゾーンに分散されていて、少なくとも 1 つのゾーンの障害に対応できる必要がある場合は、ピーク ワークロードのインスタンス数にゾーン数/(ゾーン数 -1)、つまり 3/2 をかけます。 たとえば、通常のピーク ワークロードに 4 つのインスタンスが必要な場合、6 つのインスタンスをプロビジョニングする必要があります: (2/3 * 6 インスタンス) = 4 インスタンス。
ゾーン間のトラフィック ルーティング
通常の操作中、トラフィックは、すべての可用性ゾーンにわたるすべての使用可能な App Service プラン インスタンス間でルーティングされます。
ゾーンダウン エクスペリエンス
検出と対応: App Service プラットフォームは、可用性ゾーンの障害を検出し、対応する役割を担います。 ゾーンのフェールオーバーを開始するために何もする必要はありません。
アクティブな要求: 可用性ゾーンが使用できなくなると、障害のある可用性ゾーン内の App Service プラン インスタンスに接続されている進行中のすべての要求は終了されるため、再試行する必要があります。
トラフィックの再ルーティング: ゾーンが使用できなくなると、Azure App Service は、そのゾーンから失われたインスタンスを検出し、 新しい置換インスタンスの検出を自動的に試みます。 その後、トラフィックは、必要に応じて、新しいインスタンス間に分散されます。
自動スケーリングを構成しており、さらに多くのインスタンスが必要と判断された場合、自動スケーリングから App Service に対してインスタンス追加の要求も発行されます。
Note
自動スケーリングの動作は、App Service プラットフォームの動作から独立しています。 指定する自動スケーリング インスタンス数は、3 の倍数である必要はありません。
重要
ゾーンダウン シナリオでは、追加インスタンスの要求が成功する保証はありません。 失われたインスタンスの補填はベスト エフォートで実行されます。 可用性ゾーンが失われたときに容量を保証する必要がある場合は、ゾーンが失われることを考慮して、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 アプリをファイルにバックアップできます。 この機能は、コードの再デプロイが難しい場合、または状態をディスクに格納する場合に役立ちます。 ただし、ほとんどのソリューションでは、App Service のバックアップに依存せず、代わりに、この記事で説明する他の方法を使用して回復性要件をサポートする必要があります。
サービス レベル アグリーメント (SLA)
Azure App Service のサービス レベル アグリーメント (SLA) では、このサービスの期待される可用性について説明しています。 また、その可用性に対する期待を達成するために満たす必要がある条件についても説明しています。 これらの条件を理解するには、「オンライン サービスのサービス レベル アグリーメント (SLA)」を確認することが重要です。
ゾーン冗長 App Service プランをデプロイすると、SLA で既定されたアップタイムの割合が増加します。