Azure Application Gateway v2 の信頼性

Azure Application Gateway は、Web アプリケーションへのトラフィックを管理するために使用できる Web トラフィック ロード バランサーです。 高可用性かつセキュアなアプリケーション配信サービスを提供するために、オート スケーリング、ゾーン冗長性、静的仮想 IP (VIP) アドレス、Web アプリケーション ファイアウォール (WAF) との統合などの高度な機能を備えています。

Azure を使用する場合、 信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。

この記事では、一時的な障害、可用性ゾーンの停止、リージョンの停止など、さまざまな障害や問題に対する Application Gateway v2 の回復性を確保する方法について説明します。 また、Application Gateway v2 サービス レベル アグリーメント (SLA) に関する重要な情報についても説明します。

運用環境のデプロイに関する推奨事項

ソリューションの信頼性要件を満たすための Application Gateway の導入方法や、信頼性がアーキテクチャの他の側面に与える影響について詳しくは、「Azure Well-Architected Framework における Application Gateway のアーキテクチャ ベスト プラクティス」をご覧ください。

信頼性アーキテクチャの概要

Application Gateway はマネージド サービスです。 信頼性に関する適切な判断を行うためには、サービス アーキテクチャの主要な要素を理解しておくことが重要です。

• ゲートウェイ： Application Gateway をデプロイするときは、使用する Azure リソースであるゲートウェイをデプロイ します。

• インスタンス：インスタンスは、ゲートウェイの 1 つのユニットです。 ゲートウェイには複数のインスタンスがあります。 各インスタンスは、独自のプライベート IP アドレスを持ち、トラフィックを処理し、要求をルーティングします。

  Important

  高可用性のために、各ゲートウェイは常に少なくとも 2 つのインスタンスで作成されます。 ただし、実際には 2 つのインスタンスがある場合でも、Azure portal はゲートウェイに 1 つのインスタンスがあることを示している可能性があります。

  プラットフォームが、インスタンスの作成、稼働状況の監視、および異常なインスタンスの置換を自動的に管理します。 スケールイン時には、インスタンスの削除を円滑に管理します。 このプロセスはコネクション ドレインとして知られています。

  次の図は、2 つのインスタンスを持つゲートウェイを示しています。

  

複数の可用性ゾーンにインスタンスを分散し、データセンターの障害時に冗長性と可用性を向上させるために、ゾーンの冗長性を有効にすることができます。

• スケーリング: ゲートウェイの信頼性の重要な側面は、どのようにトラフィックの需要に合わせてスケーリングするかです。 ゲートウェイが適切にスケーリングされない場合、トラフィックが流れず、アプリケーションでダウンタイムが発生する可能性があります。 Application Gateway では、以下のいずれかのスケーリング モードを構成できます。

  • "自動スケーリング:" 指定した範囲内のインスタンスの数を自動的に調整します。 自動スケーリングは、現在のトラフィック需要に基づいてインスタンスの数をスケーリングします。

  • "手動スケーリング:" インスタンスの正確な数を指定する必要があります。 ユーザーがトラフィックの需要を満たすインスタンス数を選択する必要があります。

  "容量ユニット" は、ゲートウェイが処理できる容量を表します。 容量ユニットは、トラフィック、接続数、コンピューティング リソースを包含する合成メジャーです。 各インスタンスは、少なくとも 10 個の容量ユニットを処理できます。 詳細については、Application Gateway v2 と WAF v2 のスケーリングに関するページを参照してください。

• 正常性プローブ: Application Gateway は、正常性プローブを使用して、個々のアプリケーション サーバーなどのバックエンド サーバーを継続的に監視します。 異常なサーバーが検出されると、トラフィックは正常なバックエンド サーバーに自動的にリダイレクトされます。

一時的な障害に対する回復性

一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。

クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。

Application Gateway を使用する際は、次のベスト プラクティスを考慮してください。

• 再試行ロジックを実装します。 一時的な接続エラーに対する適切な再試行メカニズムをクライアントに実装する必要があります。

• 許容値を設定した正常性プローブを構成します。 一時的な障害の猶予期間を許可するように正常性プローブを構成します。 正常性プローブは、"異常なしきい値" を使用して構成できます。これは、バックエンド サーバーに異常のマークを付ける必要がある連続して失敗した接続試行の数を指定します。 既定値の 3 により、バックエンド サーバーで一時的な障害が発生しても、Application Gateway が不要にそのサーバーを非正常と判定しないようになっています。

可用性ゾーンの障害に対する回復性

可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

Application Gateway は、Standard_v2 または WAF_v2 ゲートウェイをサポート対象リージョンにデプロイする際に、2 種類の可用性ゾーン サポートを提供します。

• ゾーン冗長: Azure はインスタンスを 2 つ以上の可用性ゾーンに自動的に分散します。

  新しいゲートウェイをデプロイすると、既定ではゾーン冗長になります。

  次の図は、3 つの可用性ゾーンに分散される 3 つのインスタンスを持つゾーン冗長ゲートウェイを示しています。

  

• ゾーナル:　Azure は、選択した Azure リージョン内の単一のゾーンに、すべての Application Gateway インスタンスをデプロイします。

  次の図は、同じ可用性ゾーンにデプロイされた 3 つのインスタンスを含むゾーン ゲートウェイを示しています。

  

  Important

  ゾーン間レイテンシがニーズに対して高すぎる場合、かつそのレイテンシが要件を満たしていないことを確認した場合に限り、単一の可用性ゾーンへの固定が推奨されます。 ゾーン ゲートウェイ自体は、可用性ゾーンの停止に対する回復性を提供しません。 ゾーン の Application Gateway 展開の回復性を向上させるには、個別のゲートウェイを複数の可用性ゾーンに明示的に展開し、トラフィック ルーティングとフェールオーバーを構成する必要があります。

Requirements

• リージョンのサポート: Application Gateway では、可用性ゾーンをサポートするすべての Azure リージョンのStandard_v2層とWAF_v2 層の可用性ゾーンがサポートされます。

• SKU: 可用性ゾーンのサポートを有効にするには、Standard_v2またはWAF_v2 SKU を使用する必要があります。

• インスタンス数: ゲートウェイには、少なくとも 2 つのインスタンスが必要です。

  注

  高可用性を実現するために、すべてのゲートウェイに少なくとも 2 つのインスタンスがあります。 Azure portal 上でゲートウェイが 1 つのインスタンスで構成されているように表示されていても、内部的には常に最低 2 つのインスタンスで作成されています。

考慮事項

ゾーン冗長ゲートウェイは、リージョン内の 2 つ以上の可用性ゾーンに分散されます。 たとえば、3 つの可用性ゾーンが存在するリージョンでは、ゾーン冗長構成の Application Gateway v2 は、少なくともそのうち 2 つのゾーンにインスタンスをデプロイします。 リージョンのキャパシティやプラットフォームの判断に応じて、インスタンスは 2 つのゾーンまたは 3 つのゾーンに分散される場合があります。

費用

Application Gateway v2 の可用性ゾーンのサポートでは、標準の容量ユニットの価格を超える追加料金は発生しません。 価格の詳細については、「Application Gateway および WAF の価格の理解」および「Application Gateway の価格」をご参照ください。

可用性ゾーンのサポートを設定する

このセクションでは、ゲートウェイに可用性ゾーンのサポートを構成する方法について説明します。

• 可用性ゾーン サポートを有効にして新しいゲートウェイを作成します。 可用性ゾーンの構成方法は、ゾーン冗長ゲートウェイを作成するか、ゾーナル ゲートウェイを作成するかによって異なります。

  • "ゾーン冗長:" 新しいゲートウェイは、既定でゾーン冗長として作成されます。 インスタンスは複数の可用性ゾーンに分散され、リージョン内の 2 つ以上のゾーンが使用される場合があります。

    新しいゲートウェイをデプロイするには、「クイックスタート: Azure portal を使用して Web トラフィックを Application Gateway に誘導する」をご覧ください。

    Azure CLI、Azure PowerShell、Bicep、Azure Resource Manager テンプレート (ARM テンプレート)、または Terraform を使用する場合、ゲートウェイをデプロイする可用性ゾーンを任意で指定できます。 2 つ以上のゾーンを指定することで、ゾーン冗長ゲートウェイを展開できます。 ただし、特定のゾーンを使用しない明確な理由がない限り、ゲートウェイがすべての可用性ゾーンを利用できるように、ゾーン リストの指定は省略することを推奨します。

  • ゾーナル: 以下のツールを使用して、ゾーナル ゲートウェイをデプロイできます。

    • Azure CLI:--zones コマンドで az network application-gateway create パラメーターを使用して、ゾーンを明示的に選択する必要があります。 ゲートウェイを 1 つのゾーンにピン留めするには、論理ゾーン番号を指定します。

    • Azure PowerShell:-Zone コマンドで New-AzApplicationGateway パラメーターを使用します。 ゲートウェイを 1 つのゾーンにピン留めするには、論理ゾーン番号を指定します。

    • Bicep および ARM テンプレート: リソース定義内で zones プロパティを構成します。 ゲートウェイを 1 つのゾーンにピン留めするには、論理ゾーン番号を指定します。

    注

    使用する可用性ゾーンを選択した場合、実際には "論理可用性ゾーン" を選択していることになります。 別の Azure サブスクリプションの他のワークロード コンポーネントをデプロイした場合、別の "論理可用性ゾーン" 番号を使用して、同じ物理可用性ゾーンにアクセスできる場合があります。 詳細については、「物理ゾーンと可用性ゾーン」を参照してください。

• 既存の Application Gateway v2 インスタンスの可用性ゾーン構成を変更します。 すべてのゲートウェイは、ゾーン構成にしていない限りゾーン冗長です。

  ゾーン冗長ゲートウェイからゾーン構成に移行する必要がある場合は、新しいゲートウェイを展開する必要があります。

• 可用性ゾーン サポートを無効にします。 可用性ゾーン サポートは無効にできません。 可用性ゾーンをサポートするリージョンでは、すべてのゲートウェイはゾーン冗長構成またはゾーナル構成のいずれかである必要があります。

容量の計画と管理

ゾーン冗長構成のアプリケーション ゲートウェイや、複数のゾーンにデプロイされた複数のゾーナル ゲートウェイに対してゾーン障害を想定する際は、トラフィックの再分配により、障害を免れたゾーンのインスタンスに負荷が集中する可能性があることを考慮してください。 接続が数秒間の短時間中断を伴う可能性があります。

キャパシティを効果的に管理するには、次の対策を講じてください。

• 自動スケーリングを使います。 ゾーン停止中の潜在的なトラフィックの再配布処理に適切な最大インスタンス数を使用して、自動スケーリングを構成します。

  手動スケーリングを使用する場合は、可用性ゾーンの障害に備えて、ゲートウェイ内のインスタンスの数の "過剰プロビジョニング" を検討してください。 オーバー プロビジョニングにより、一定のキャパシティ損失を許容しつつ、パフォーマンスを低下させることなくシステムを継続的に稼働させることができます。 詳細については、「 過剰プロビジョニングによる容量の管理」を参照してください。

• トラフィック パターンの変化に対応します。 キャパシティ メトリックを監視し、トラフィック パターンやパフォーマンス要件に応じてスケーリング パラメーターを調整します。

すべてのゾーンが正常な場合の動作

次のセクションでは、Application Gateway v2 に可用性ゾーン サポートを構成し、すべての可用性ゾーンが正常に稼働している場合に予想される動作について説明します。

• ゾーン間のトラフィック ルーティング: Application Gateway は、ゲートウェイが使用するすべてのゾーン内のインスタンス間で受信要求を自動的に分散します。 このアクティブ/アクティブ構成により、通常の動作条件下での最適なパフォーマンスと負荷分散が保証されます。

• インスタンス管理: プラットフォームが、ゲートウェイで使用されるゾーン間のインスタンス配置を自動的に管理します。 障害が発生したインスタンスを置き換え、設定されたインスタンス数を維持します。 稼働状況の監視により、正常なインスタンスのみがトラフィックを受信します。

ゾーン障害時の動作

次のセクションでは、Application Gateway v2 が可用性ゾーンのサポートを使用して構成されていて、1 つ以上の可用性ゾーンが使用できないときに予期される内容について説明します。

• 検出と対応: 検出および対応の責任は、ゲートウェイで使用されている可用性ゾーンの構成に依存します。

  • "ゾーン冗長:" Microsoft がゾーン障害の検出を管理し、フェールオーバーを自動的に開始します。 お客様による対応は必要ありません。

  • "ゾーン:" ユーザーが可用性ゾーンの損失を検出し、別の可用性ゾーンに作成するセカンダリ ゲートウェイへのフェールオーバーを開始する必要があります。

• • 通知: ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、Azure Resource Healthを使用して個々のリソースの正常性を監視したり、Resource Healthアラートを設定して問題を通知したりすることはできます。 また、Azure Service Health を使用して、ゾーンの障害を含むサービスの全体的な正常性を把握し、問題を通知する Service Health アラートを設定することもできます。

• アクティブな要求: ゾーン障害が発生した場合、そのゾーン内のインスタンスで処理中の要求は終了されます。」 クライアントは、一時的な障害の対処方法に関するガイダンスに従って、要求を再試行する必要があります。

• 想定されるデータ損失: Application Gateway はステートレスなサービスであるため、ゾーン障害によってデータ損失が発生することは想定されていません。

• 想定されるダウンタイム: 予想されるダウンタイムは、ゲートウェイで使用されている可用性ゾーンの構成によって異なります。

  • ゾーン冗長: ゾーン障害が発生した場合、トラフィックの再分配に伴い、接続が通常数秒程度の短時間中断を伴うことがあります。

  • "ゾーン:" ゾーンが使用できないとき、ゲートウェイは可用性ゾーンが復旧するまで使用できません。

• インスタンス管理: インスタンス管理の動作は、次のようにゲートウェイが使用する可用性ゾーンの構成によって異なります。

  • "ゾーン冗長:" プラットフォームが、他の可用性ゾーンに一時的なインスタンスを作成することで、ゲートウェイの容量を維持しようとします。

    内部的には、Application Gateway では仮想マシン スケール セットが使用され、 ベスト エフォート ゾーン分散が実行されます。 この動作により、容量をゾーン間で均等に分割できない (1 インスタンス多いか少ない) ときにスケーリング操作が発生しない可能性があります。

  • "ゾーン:" 必要な場合は、ユーザーが正常なゾーンにインスタンスを作成する必要があります。

• トラフィックの再ルーティング: トラフィックの再ルーティング動作は、次のようにゲートウェイが使用する可用性ゾーンの構成によって異なります。

  • "ゾーン冗長:" Application Gateway が、一時的に作成されたインスタンスを含め、正常なゾーン内のインスタンスにトラフィックを直ちに再配布します。

  • "ゾーン:" ゾーンが使用できないとき、ゲートウェイは使用できません。 別の可用性ゾーンにセカンダリ ゲートウェイがある場合は、ユーザーがそのセカンダリ ゲートウェイへのトラフィックを再ルーティングする必要があります。

ゾーンの回復

ゾーンの復旧動作は、ゲートウェイで使用される可用性ゾーンの構成によって異なります。

• ゾーン冗長: 影響を受けた可用性ゾーンが復旧すると、Application Gateway は次の処理を自動的に実行します。

  • 復旧されたゾーン内のインスタンスを復元します

  • 停止中に他のゾーンで作成されたすべての一時インスタンスを削除します

  • 使用可能なすべてのゾーンにわたって通常のトラフィック分散に戻ります

• "ゾーン:" 可用性ゾーンが復旧した後、ユーザーが元の可用性ゾーン内のゲートウェイへのトラフィックを再ルーティングする必要があります。

ゾーンエラーのテスト

ゾーンの障害をテストするためのオプションは、次のようにゲートウェイが使用する可用性ゾーンの構成によって異なります。

• ゾーン冗長: Application Gateway プラットフォームは、ゾーン冗長構成のゲートウェイに対して、トラフィックのルーティング、フェールオーバー、およびフェールバックを完全に管理します。 Microsoft がこの機能を管理するため、可用性ゾーンの障害プロセスを開始または検証する必要はありません。 プラットフォームが、すべてのゾーン障害シナリオを透過的に処理します。

• "ゾーン:" ゲートウェイを明示的に停止することで、ユーザーが可用性ゾーンの障害の一部の側面をシミュレートできます。 ゲートウェイを停止することで、他のシステムやロード バランサーがゲートウェイの障害にどのように対応するかをテストできます。 詳細については、「Application Gateway の停止と起動方法」を参照してください。

リージョン全体の障害に対する回復性

Application Gateway v2 は単一リージョン サービスです。 リージョンが利用不可になると、ゲートウェイも利用できなくなります。

回復性のためのカスタム マルチリージョン ソリューション

Application Gateway v2 を使用してマルチリージョンの回復性を実現するには、必要な各リージョンに個別のゲートウェイをデプロイし、リージョン間でトラフィック管理を実装する必要があります。 各ゲートウェイの展開と構成、およびトラフィック のルーティングとフェールオーバーはユーザーが行う必要があります。 次の点を考慮してください。

• リージョン間で一貫した Application Gateway の規則とポリシーを構成します。 Bicep や Terraform などのツールを使用することで、コードとしてのインフラストラクチャ (IaC) としてインフラを定義し、複数リージョンにわたるデプロイや構成を簡素化できます。

• リージョン ゲートウェイ間でトラフィックを送信できるグローバル負荷分散ソリューションを展開します。 Azure のグローバル負荷分散サービスは、Azure Traffic Manager と Azure Front Door です。 各サービスは、正常性チェック、地理的近接性、またはパフォーマンス メトリックに基づいてトラフィックをルーティングします。 Azure Front Door には、分散型サービス拒否 (DDoS) 攻撃対策、WAF 機能、高度なルール設定やルーティング機能など、さまざまな機能が備わっています。

• ゲートウェイを超えて、バックエンド アプリケーションとデータをリージョン間でレプリケートすることを検討してください。 マルチリージョンデプロイのアプローチを理解するには、各Azure サービスの信頼性ガイドを参照してください。

例としてのアプローチについては、「Application Gateway と Traffic Manager の併用方法」を参照してください。

バックアップと復元

Application Gateway v2 はステートレスなサービスであり、従来のバックアップおよび復元操作を必要としません。 すべての構成データは Resource Manager に保存されており、Bicep ファイルや ARM テンプレートなどの IaC 手法を使用して再デプロイできます。

構成管理およびディザスター リカバリーのために、次の対応を行う必要があります。

• Bicep ファイルまたは ARM テンプレートを使用して Application Gateway 展開の構成を定義するか、既存のゲートウェイの構成をエクスポートします。

• トランスポート層セキュリティ (TLS) 証明書は、Azure Key Vault に保存して、安全な管理およびレプリケーションを行ってください。

• カスタム構成、ルール、ポリシーを文書化し、バージョン管理します。

• 一貫性のあるゲートウェイ プロビジョニングのための自動デプロイ パイプラインを実装します。

サービス メンテナンスに対する回復性

Application Gateway v2 は、定期的なサービス アップグレードやその他のメンテナンス タスクを実行します。 アップグレード中に予想される容量を維持するために、プラットフォームはアップグレード プロセス中にゲートウェイのインスタンスを自動的に追加します。 ただし、ゲートウェイのサブネットに、一時インスタンスを作成するための十分な空き IP アドレス空間があることを確認する必要があります。 詳細については、「 Application Gateway で定期的なメンテナンスを処理する方法」を参照してください。

サービス水準合意書

Azure サービスのサービス レベル アグリーメント (SLA) には、各サービスの期待される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について記載されています。 詳細については、 オンライン サービスの SLA を参照してください。

ゲートウェイを Application Gateway 可用性 SLA の対象にするには、次の条件を満たす必要があります。

• HTTP 負荷分散を実行するには、正しく構成する必要があります。
• ゾーン冗長であるか、自動スケールを使用するように構成する必要があります。

関連コンテンツ

• Azure の信頼性の概要