Azure App Service は、Web アプリケーション、REST API、およびモバイル バックエンドをホストするための HTTP ベースのサービスです。 App Service は Microsoft Azure と統合され、アプリケーションのセキュリティ、負荷分散、自動スケーリング、および自動管理が提供されます。 この記事では、 Azure App Service での信頼性のサポートについて説明します。 可用性ゾーン と 複数リージョンのデプロイによるリージョン内の回復性について説明します。
App Service Environment を使用している場合、その環境での信頼性のサポートの詳細については、 Azure App Service Environment の信頼性に関するページを参照してください。
信頼性は、お客様と Microsoft の間で共有される責任です。 このガイドを使用して、特定のビジネス目標とアップタイム目標を満たす信頼性オプションを決定できます。
運用環境デプロイに関する推奨事項
ソリューションの信頼性要件をサポートするために Azure App Service をデプロイする方法と、信頼性がアーキテクチャの他の側面にどのように影響するかについては、 Azure Well-Architected Framework での Azure App Service (Web Apps) のアーキテクチャのベスト プラクティスに関するページを参照してください。
信頼性アーキテクチャの概要
Azure App Service Web アプリを作成するときに、アプリを実行する App Service プラン を定義します。
App Service プランでは、Web アプリを実行するコンピューティング リソースのセットを定義します。 すべての Web アプリは、App Service プラン内で実行する必要があります。 App Service プランをスケーリングして、複数の仮想マシン インスタンス (worker) で実行できます。 これらのインスタンスは、アプリ コードを実行するコンピューティング リソースです。 1 つの App Service プランで複数のアプリをホストでき、すべて同じ VM インスタンスの共有セットで実行されます。
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 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
Premium v2-v4 レベルでは、App Service をゾーン冗長として構成できます。つまり、リソースは複数の可用性ゾーンに分散されます。 複数のゾーンに分散することで、運用ワークロードで回復性と信頼性を実現できます。 App Service プランでゾーン冗長を構成すると、そのプランを使用するすべてのアプリがゾーン冗長になります。
リージョンのサポート
ゾーン冗長 App Service Premium v2-v4 プランは、 可用性ゾーンをサポートする任意のリージョンにデプロイできます。
必要条件
ゾーン冗長を有効にするには、次の手順を実行する必要があります。
Premium v2-4 プランの種類を使用します。
プランに少なくとも 2 つのインスタンスをデプロイします。
可用性ゾーンをサポートするスケール ユニットに配置する。 App Service プランを作成すると、プランはスケール ユニットに割り当てられます。 割り当てられているスケール ユニットは、App Service プランをデプロイするリソース グループに基づいています。 スケール ユニットが可用性ゾーンをサポートしていない場合は、新しいリソース グループに新しいプランを作成する必要があります。
App Service プランがオンになっているスケール ユニットがゾーンの冗長性をサポートしているかどうかを確認するには、「 App Service プランのゾーン冗長のサポートを確認する」を参照してください。
ゾーン間でのインスタンスの分散
ゾーン冗長 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 プランの物理ゾーンを表示する」を参照してください。
考慮事項
Premium v2-4 プランの場合、可用性ゾーンの停止中に、アプリケーションが引き続きトラフィックを処理している場合でも、Azure App Service の一部の側面が影響を受ける可能性があります。 これらの動作には、App Serviceプランのスケーリング、アプリケーションの作成、アプリケーションの構成、およびアプリケーションの発行が含まれます。
App Service Premium v2-4 プランでゾーン冗長を有効にすると、App Service プラットフォームがロールアウトする更新プログラムに対する回復性も向上します。詳細については、 サービスメンテナンス中の信頼性に関するページを参照してください。
ゾーン冗長として構成されていない App Service プランの場合、基になる VM インスタンスは可用性ゾーンの障害に対する回復性がありません。 そのリージョン内のどのゾーンで障害が発生しても、ダウンタイムが発生する可能性があります。
コスト
App Service Premium v2-v4 プランを使用する場合、App Service プランに 2 つ以上のインスタンスがある限り、可用性ゾーンの有効化に関連する追加コストは発生しません。 ご利用の App Service プランの SKU、指定した容量、自動スケーリング条件に基づいてスケーリングする任意のインスタンスに基づいて課金されます。
可用性ゾーンを有効にしたが、容量が 2 未満を指定した場合、プラットフォームは最小インスタンス数を 2 に設定します。 プラットフォームでは、これら 2 つのインスタンスに対して課金されます。
可用性ゾーンのサポートを設定する
新しいゾーン冗長のアプリサービスプランを作成してください。 新しいゾーン冗長 App Service プランを作成する方法については、「 ゾーン冗長を使用して新しい App Service プランを作成する」を参照してください。
既存の App Service プランでゾーン冗長を有効または無効にします。 既存の App Service プランをゾーン冗長性を有効または無効にする方法については、「既存の App Service プランをゾーン冗長性に対して有効または無効にする」を参照してください。
容量の計画と管理
可用性ゾーンの障害に備えて、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 でのアプリのスケールアップ と 自動スケールの概要に関するページを参照してください。
重要
ゾーンダウン シナリオでは、追加インスタンスの要求が成功する保証はありません。 失われたインスタンスのバックフィルは、ベスト エフォートベースで行われます。 可用性ゾーンが失われたときに保証された容量が必要な場合は、ゾーンの損失を考慮して App Service プランを作成して構成する必要があります。 これを実現するには、 App Service プランの容量を過剰にプロビジョニングします。
実行時間以外の動作: ゾーン冗長 App Service プランにデプロイされたアプリケーションは、可用性ゾーンで障害が発生した場合でも、引き続き実行され、トラフィックを処理します。 ただし、可用性ゾーンの停止中に、実行時以外の動作が影響を受ける可能性があります。 これらの動作には、App Serviceプランのスケーリング、アプリケーションの作成、アプリケーションの構成、およびアプリケーションの発行が含まれます。
フェールバック
可用性ゾーンが復旧すると、App Service によって、復旧された可用性ゾーンにインスタンスが自動的に作成され、他の可用性ゾーンで作成された一時インスタンスが削除され、インスタンス間のトラフィックが通常どおりにルーティングされます。
ゾーン障害のテスト
App Service プラットフォームは、ゾーン冗長 App Service プランのトラフィック ルーティング、フェールオーバー、フェールバックを管理します。 この機能は完全に管理されているため、可用性ゾーンの障害プロセスを開始または検証する必要はありません。
マルチリージョン サポート
App Service は単一リージョン のサービスです。 リージョンが使用できなくなった場合、アプリケーションも使用できなくなります。
代替のマルチリージョン アプローチ
アプリケーションに影響を与える単一リージョンの障害のリスクを軽減するために、複数のリージョンにプランをデプロイできます。 次の手順は、回復性の強化に役立ちます。
- アプリケーションを各リージョンのプランにデプロイします。
- 負荷分散とフェールオーバーのポリシーを構成します。
- 最後のアプリケーションの状態を回復できるように、リージョン間でデータをレプリケートします。
この方法に関連するリソースを次に示します。
バックアップ
Basic レベル以上を使用する場合は、App Service のバックアップと復元の機能を使用して、App Service アプリをファイルにバックアップできます。
この機能は、コードの再デプロイが難しい場合、または状態をディスクに格納する場合に役立ちます。 ほとんどのソリューションでは、バックアップのみに依存しないでください。 代わりに、このガイドで説明されている他の機能を使用して、回復性の要件をサポートします。 ただし、バックアップでは、他の方法では行わないリスクから保護されます。 詳細については、「 App Service でのアプリのバックアップと復元」を参照してください。
サービスメンテナンス中の信頼性
Azure App Service では、通常のサービス アップグレードと、その他の形式のメンテナンスが実行されます。 アップグレード中に予想される容量が確実に使用可能になるように、プラットフォームはアップグレード プロセス中に App Service プランのインスタンスを自動的に追加します。
ゾーン冗長を有効にします。 App Service プランでゾーン冗長を有効にすると、App Service プラットフォームがロールアウトする更新に対する回復性も向上します。 更新ドメインは、更新 時にオフラインになる仮想マシン (VM) のコレクションで構成されます。 更新ドメインは可用性ゾーンに関連付けられています。 App Service プランに複数のインスタンスをデプロイし、プランのゾーン冗長性を有効にすると、インスタンスまたはゾーンが異常になった場合に、アップグレード中に回復性のレイヤーが追加されます。
詳細については、 Azure App Service の定期的な計画メンテナンス と、 Azure App Service の定期的なメンテナンス、再起動、ダウンタイムに関するページを参照してください。
サービス レベル アグリーメント (SLA)
Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するために満たす必要がある条件について説明します。 詳細については、 オンライン サービスの SLA を参照してください。
ゾーン冗長 App Service プランをデプロイすると、SLA で既定されたアップタイムの割合が増加します。