Azure Application Gateway の計画と実装

  • 10 分

Azure Application Gateway は、Web アプリケーションへのトラフィックを管理できる Web トラフィック (Open Systems Interconnections (OSI) レイヤー 7) ロード バランサーです。 従来のロード バランサーはトランスポート レイヤー (OSI レイヤー 4 - TCP と UDP) で動作し、送信元 IP アドレスとポートに基づくトラフィックを送信先 IP アドレスとポートにルーティングします。

Application Gateway では、URI パスやホスト ヘッダーなど、HTTP 要求のより多くの属性に基づいてルーティングの決定を行うことができます。 たとえば、着信 URL に基づいてトラフィックをルーティングできます。 そのため、/images が受信 URL 内にある場合は、イメージ用に構成された特定のサーバー セット (プールと呼ばれます) にトラフィックをルーティングできます。 /video が URL にある場合、そのトラフィックはビデオ用に最適化された別のプールにルーティングされます。

Azure Application Gateway の例を示す図。

この種類のルーティングは、アプリケーション レイヤー (OSI レイヤー 7) の負荷分散と呼ばれます。 Azure Application Gateway は URL ベースのルーティングなどを行うことができます。

アプリケーション ゲートウェイのコンポーネント

アプリケーション ゲートウェイは、クライアントからの単一接続点として機能します。 アプリケーション ゲートウェイは、着信するアプリケーション トラフィックを、Azure VM、仮想マシン スケール セット、Azure App Service、オンプレミス/外部サーバーなど、複数のバックエンド プールに配布します。

Azure Application Gateway コンポーネントを示す図。

インフラストラクチャ

Application Gateway インフラストラクチャには、仮想ネットワーク、サブネット、ネットワーク セキュリティ グループ、およびユーザー定義ルートが含まれます。

フロントエンド IP アドレス

パブリック IP アドレス、プライベート IP アドレス、またはその両方を持つアプリケーション ゲートウェイを構成できます。 クライアントがインターネットに接続する仮想 IP (VIP) 経由でインターネット経由でアクセスする必要があるバックエンドをホストする場合は、パブリック IP が必要です。

インターネットに公開されていない内部エンドポイントには、パブリック IP アドレスは必要ありません。 プライベート フロントエンド構成は、インターネットに公開されていない内部基幹業務アプリケーションに役立ちます。 また、インターネットに公開されていないが、ラウンドロビン負荷分散、セッションの持続性、または TLS 終了を必要とするセキュリティ境界内の多層アプリケーションのサービスと階層にも役立ちます。

1 つのパブリック IP アドレスと 1 つのプライベート IP アドレスのみがサポートされます。 フロントエンド IP は、アプリケーション ゲートウェイを作成するときに選択します。

注

Application Gateway フロントエンドは、デュアルスタック IP アドレス (パブリック プレビュー) をサポートしています。 最大 4 つのフロントエンド IP を作成できます。 2 つのアドレスは IPv4 アドレス (パブリックとプライベート) で、2 つは IPv6 アドレス (パブリックとプライベート) です。

  • パブリック IP アドレスの場合は、新しいパブリック IP アドレスを作成するか、アプリケーション ゲートウェイと同じ場所に既存のパブリック IP を使用できます。 詳細については、「静的と動的パブリック IP アドレス」を参照してください。
  • プライベート IP アドレスの場合は、アプリケーション ゲートウェイが作成されるサブネットのプライベート IP アドレスを指定できます。 Application Gateway v2 SKU のデプロイでは、ゲートウェイにプライベート IP アドレスを追加するときに静的 IP アドレスを定義する必要があります。 Application Gateway v1 SKU デプロイの場合、IP アドレスを指定しない場合、使用可能な IP アドレスがサブネットから自動的に選択されます。 選択した IP アドレスの種類 (静的または動的) は、後で変更することはできません。

フロントエンド IP アドレスはリスナーに関連付けられます。この リスナーは、フロントエンド IP で受信要求をチェックします。

プライベート リスナーとパブリック リスナーは、同じポート番号で作成できます。 ただし、Application Gateway サブネットに関連付けられているすべてのネットワーク セキュリティ グループ (NSG) に注意してください。 NSG の構成によっては、アプリケーション ゲートウェイのパブリックおよびプライベート フロントエンド IP として宛先 IP アドレスを含む受信許可規則が必要になる場合があります。 同じポートを使用すると、アプリケーション ゲートウェイによって受信フローの 宛先 がゲートウェイのフロントエンド IP に変更されます。

受信規則:

  • ソース:要件に従い
  • 宛先: アプリケーション ゲートウェイのパブリックおよびプライベート フロントエンド IP。
  • 宛先ポート: 構成済みのリスナーに応じて
  • プロトコル:TCP

送信規則: 特定の要件なし

リスナー

リスナーは、ポート、プロトコル、ホストおよび IP アドレスを使用して着信接続要求をチェックする論理エンティティです。 リスナーを構成するときは、ゲートウェイの受信要求の値に対応する値を入力する必要があります。

Azure portal を使用してアプリケーション ゲートウェイを作成するときにも、リスナーのプロトコルとポートを選択して既定のリスナーを作成します。 リスナー上で HTTP2 のサポートを有効にするかどうかを選択できます。 アプリケーション ゲートウェイを作成した後、この既定リスナー (appGatewayHttpListener) の設定を編集することや、新しいリスナーを作成することができます。

リスナーの種類

リスナーは、入ってくる接続要求をチェックする論理エンティティです。 リスナーは、要求に関連付けられているプロトコル、ポート、ホスト名、IP アドレスがリスナー構成に関連付けられている同じ要素に一致した場合、要求を受け取ります。

アプリケーション ゲートウェイを使用する前に、リスナーを少なくとも 1 つ追加する必要があります。 1 つのアプリケーション ゲートウェイには複数のリスナーをアタッチできます。その複数のリスナーは同じプロトコルに使用できます。

クライアントから送信された要求がリスナーに検出されると、アプリケーション ゲートウェイでは、規則に構成されているバックエンド プールのメンバーにその要求が転送されます。

リスナーでは、次のポートとプロトコルがサポートされます。

ポート

Application Gateway では、さまざまな構成可能なポートがサポートされています。 V2 SKU はポート 1 から 64999 (ポート 22 を除く) をサポートし、V1 SKU はポート 1 から 65502 (ポート 3389 を除く) をサポートします。

プロトコル

Application Gateway では、HTTP、HTTPS、HTTP/2、WebSocket の 4 つのプロトコルがサポートされています。

注

HTTP/2 プロトコルのサポートを利用できるのは、アプリケーション ゲートウェイ リスナーに接続しているクライアントだけです。 バックエンド サーバー プールへの通信は、常に HTTP/1.1 で行われます。 既定では、HTTP/2 のサポートは無効になっています。 必要であれば、有効にすることもできます。

  • リスナー構成で HTTP プロトコルと HTTPS プロトコルの間で指定します。
  • WebSocket と HTTP/2 プロトコルのサポートはネイティブで提供され、WebSocket のサポートは既定で有効になっています。 WebSocket のサポートを選択的に有効または無効にするユーザー設定はありません。 WebSocket は HTTP リスナーと HTTPS リスナーの両方で使用します。

TLS 終了には HTTPS リスナーを使用します。 HTTPS リスナーは、暗号化と復号化の作業をアプリケーション ゲートウェイにオフロードするため、Web サーバーはオーバーヘッドの負担を受けないようにします。

要求ルーティング規則

Azure portal を使用してアプリケーション ゲートウェイを作成するときに、既定の規則 (rule1) を作成します。 この規則によって、既定のリスナー (appGatewayHttpListener) が既定のバックエンド プール (appGatewayBackendPool) と既定のバックエンド HTTP 設定 (appGatewayBackendHttpSettings) にバインドされます。 ゲートウェイを作成した後で、既定の規則の設定の編集や新しい規則の作成を行うことができます。

ルールの種類

ルールを作成するときは、基本ベースとパスベースのどちらかを選択します。

  • 関連付けられているリスナーのすべての要求 (たとえば、blog.contoso.com/*) を単一のバックエンド プールに転送する場合は、[基本] を選択します。
  • 特定の URL パスからの要求を特定のバックエンド プールにルーティングする場合は、パス ベースを選択します。 パスのパターンは URL のパスのみに適用され、クエリ パラメーターには適用されません。

関連付けられたリスナー

リスナーをルールに関連付けて、リスナーに関連付けられている 要求ルーティング規則 が評価され、要求のルーティングの対象となるバックエンド プールが決定されます。

関連付けられたバックエンド プール

リスナーが受信する要求を処理するバックエンド ターゲットを含むバックエンド プールを規則に関連付けます。

  • 基本規則の場合、1 つのバックエンド プールのみが許可されます。 関連付けられているリスナー上のすべての要求は、そのバックエンド プールに転送されます。
  • パスベースの規則の場合は、各 URL パスに対応する複数のバックエンド プールを追加します。 入力された URL パスに一致する要求は、対応するバックエンド プールに転送されます。 また、既定のバックエンド プールを追加します。 規則内のどの URL パスとも一致しない要求は、そのプールに転送されます。

関連付けられたバックエンド HTTP 設定

各規則のバックエンド HTTP 設定を追加します。 要求は、この設定で指定されたポート番号、プロトコル、およびその他の情報を使用して、アプリケーション ゲートウェイからバックエンド ターゲットにルーティングされます。

基本規則の場合、1 つのバックエンド HTTP 設定のみが許可されます。 関連付けられているリスナー上のすべての要求は、この HTTP 設定を使用して、対応するバックエンド ターゲットに転送されます。

パスベースの規則の場合は、各 URL パスに対応する複数のバックエンド HTTP 設定を追加します。 この設定の URL パスと一致する要求は、各 URL パスに対応する HTTP 設定を使用して、対応するバックエンド ターゲットに転送されます。 また、既定の HTTP 設定を追加します。 この規則のどの URL パスとも一致しない要求は、既定の HTTP 設定を使用して既定のバックエンド プールに転送されます。

リダイレクト設定

基本ルールに対してリダイレクトが構成されている場合、関連付けられているリスナーのすべての要求は、 グローバル リダイレクトと呼ばれるターゲットにリダイレクトされます。 パスベースの規則に対してリダイレクトが構成されている場合は、特定のサイト領域内の要求のみがリダイレクトされます。 たとえば、ショッピング カートエリアです。これは パスベースの リダイレクトです。

リスナー

ゲートウェイ上のあるリスナーから別のリスナーにトラフィックをリダイレクトするには、リダイレクト ターゲットとしてリスナーを選択します。 この設定は、HTTP から HTTPS へのリダイレクトを有効にする場合に必要です。 着信 HTTP 要求を確認するソース リスナーから、着信 HTTPS 要求を確認する宛先リスナーにトラフィックがリダイレクトされます。 元の要求のクエリ文字列とパスを、リダイレクト ターゲットに転送される要求に含めることもできます。

リダイレクト構成設定ページの例を示すスクリーンショット。

外部サイト

この規則に関連付けられたリスナーに対するトラフィックを外部サイトにリダイレクトするときに、外部サイトを選択します。 元の要求のクエリ文字列を、リダイレクト ターゲットに転送される要求に含めることができます。 元の要求内のパスを外部サイトに転送することはできません。

HTTP ヘッダーと URL を書き換える

書き換え規則を使用すると、要求および応答パケットがアプリケーション ゲートウェイを通じてクライアントとバックエンド プールの間を移動する際に、HTTP(S) 要求と応答ヘッダーや URL パスとクエリ文字列パラメーターを追加、削除、または更新できます。

ヘッダーと URL パラメーターは、静的な値に設定するか、その他のヘッダーやサーバー変数に設定できます。 クライアント IP アドレスを抽出する、バックエンドに関する機密情報を削除する、セキュリティを追加するなど、重要なユース ケースで役立ちます。

HTTP 設定

アプリケーション ゲートウェイは、ここで指定した構成を使用してトラフィックをバックエンド サーバーにルーティングします。 HTTP 設定を作成したら、それを 1 つ以上の要求ルーティング規則に関連付ける必要があります。

Azure Application Gateway では、ユーザー セッションを維持するために、ゲートウェイで管理される Cookie を使用します。 ユーザーが Application Gateway に最初の要求を送信すると、応答にアフィニティ Cookie が設定され、セッションの詳細が含まれるハッシュ値が設定されます。そのため、アフィニティ Cookie を保持する後続の要求は、持続性を維持するために同じバックエンド サーバーにルーティングされます。

この機能は、ユーザー セッションを同じサーバー上に維持する必要があり、ユーザー セッションのセッション状態がサーバー上にローカル保存される場合に便利です。 アプリケーションが Cookie ベースのアフィニティを処理できない場合は、この機能を使用できません。 使用するには、クライアントが Cookie をサポートしている必要があります。

注

一部の脆弱性スキャンでは、Secure フラグまたは HttpOnly フラグが設定されていないため、Application Gateway アフィニティ Cookie にフラグを設定できます。 これらのスキャンでは、Cookie 内のデータが一方向ハッシュを使用して生成されることを考慮しません。 Cookie にはユーザー情報が含まれず、ルーティング目的でのみ使用されます。

接続のドレイン

接続のドレインを使用すると、計画的なサービスの更新中にバックエンド プール メンバーを正常に削除することができます。 これは、正常性プローブによって異常と報告された

  • バックエンド プールから明示的に削除
  • スケールイン操作の際に削除される、または
  • バックエンド インスタンスに適用されます。

[バックエンド設定] で [接続ドレイン] を有効にすると、この設定をすべてのバックエンド プール メンバーに適用できます。 これで、バックエンド プール内のすべての登録解除インスタンスが、構成されたタイムアウト値まで既存の接続を維持しながら、新しい要求や接続を受信しなくなります。 これは WebSocket 接続にも当てはまります。

構成の種類 価値
バックエンド設定で接続ドレインが有効になっていない場合の既定値 30 秒
[バックエンド設定] で [接続ドレイン] が有効になっている場合のユーザー定義値 1 ~ 3,600 秒

プロトコル

Application Gateway では、要求のバックエンド サーバーへのルーティングに対して HTTP と HTTPS の両方がサポートされます。 HTTP を選択した場合、バックエンド サーバーへのトラフィックは暗号化されません。 暗号化されていない通信を許容できない場合は、HTTPS を選択してください。

リスナー内の HTTPS と組み合わせたこの設定では、エンド ツー エンド TLS がサポートされます。 これにより、暗号化された機密データをバックエンドに安全に送信できます。 エンド ツー エンド TLS が有効になったバックエンド プール内の各バックエンド サーバーは、セキュリティで保護された通信を許可するように証明書で構成する必要があります。

港 / ポート

この設定は、バックエンド サーバーがアプリケーション ゲートウェイからのトラフィックをリッスンするポートを指定します。 1 から 65535 までの範囲のポートを構成できます。

信頼されたルート証明書

バックエンド プロトコルとして HTTPS を選択した場合、Application Gateway には、エンド ツー エンド SSL のバックエンド プールを信頼するために信頼されたルート証明書が必要です。 既定では、[既知の CA 証明書を使用する] オプションは [いいえ] に設定されています。 自己署名証明書または内部証明機関によって署名された証明書を使用する場合は、バックエンド プールが使用する一致するパブリック証明書を Application Gateway に提供する必要があります。 この証明書は、.CER 形式で Application Gateway に直接アップロードする必要があります。

信頼されたパブリック証明機関によって署名されたバックエンド プールで証明書を使用する場合は、[よく知られている CA 証明書を使用する] オプションを [はい] に設定し、パブリック証明書のアップロードをスキップできます。

要求タイムアウト

この設定は、アプリケーション ゲートウェイがバックエンド サーバーからの応答の受信を待機する秒数です。

バックエンド パスのオーバーライド

この設定では、要求がバックエンドに転送されるときに使用するオプションのカスタム転送パスを構成できます。 構成すると、カスタム パスに一致する受信パスの一部が転送パスにコピーされます。 これは、バックエンドの互換性のために URL を書き換える必要がある場合や、URL パターンに基づいて異なるバックエンド パスにトラフィックをルーティングする必要がある場合に便利です。

カスタム プローブの使用

この設定により、カスタム プローブが HTTP 設定に関連付けられます。 カスタム プローブを 1 つだけ HTTP 設定と関連付けることができます。 カスタム プローブを明示的に関連付けない場合は、既定のプローブを使用してバックエンドの正常性が監視されます。 バックエンドの正常性監視をより詳細に制御するためのカスタム プローブを作成することをお勧めします。

注

対応する HTTP 設定が明示的にリスナーに関連付けられていない限り、カスタム プローブはバックエンド プールの正常性を監視しません。

ホスト名の構成

Application Gateway を使うと、バックエンドに確立された接続で、クライアントが Application Gateway への接続に使ったホスト名とは異なるホスト名を使用できます。 この構成は場合によっては便利ですが、クライアントとアプリケーション ゲートウェイ間で異なるホスト名をバックエンド ターゲットにオーバーライドする場合は、注意して行う必要があります。

運用環境では、クライアントが使用するホスト名を、アプリケーション ゲートウェイで使用されるのと同じホスト名として、バックエンド ターゲットに保持することをお勧めします。 これにより、絶対 URL、リダイレクト URL、ホストにバインドされた Cookie に関する潜在的な問題を回避できます。

これを逸脱した Application Gateway を設定する前に、「アーキテクチャ センター: リバース プロキシとそのバックエンド Web アプリケーションの間で元の HTTP ホスト名を保持する」で詳しく説明されているように、このような構成の影響を確認してください。

バックエンドに接続するために Application Gateway によって使用されるホスト HTTP ヘッダーに影響を与える HTTP 設定には、次の 2 つの側面があります。

  • バックエンド アドレスからホスト名を選択する
  • ホスト名をオーバーライドする

バックエンド アドレスからホスト名を選択する

この機能によって、要求の host ヘッダーが、バックエンド プールのホスト名に動的に設定されます。 これには IP アドレスまたは FQDN が使用されます。

この機能は、バックエンドのドメイン名がアプリケーション ゲートウェイの DNS 名と異なり、バックエンドが特定のホスト ヘッダーに依存して正しいエンドポイントに解決する場合に役立ちます。

例として、バックエンドとしてのマルチテナント サービスがあります。 アプリ サービスは、1 つの IP アドレスを持つ共有スペースを使用するマルチテナント サービスです。 そのため、アプリ サービスにアクセスするには、カスタム ドメイン設定で構成されているホスト名を使用する必要があります。

既定ではカスタム ドメイン名は example.azurewebsites.net です。 アプリケーション ゲートウェイを使用して、App Service に明示的に登録されていないホスト名またはアプリケーション ゲートウェイの FQDN によって App Service にアクセスするには、元の要求のホスト名をオーバーライドして、アプリ サービスのホスト名にする必要があります。 これを行うには、 バックエンド アドレスからホスト名を選択設定を有効にします。

既存のカスタム DNS 名がアプリ サービスにマップされているカスタム ドメインの場合、推奨される構成では 、バックエンド アドレスからホスト名を選択することはできません。

ホスト名をオーバーライドする

この機能によって、アプリケーション ゲートウェイの着信要求の host ヘッダーが、指定するホスト名に置き換えられます。

たとえば、www.contoso.comの設定でが指定されている場合、元の要求https://appgw.eastus.cloudapp.azure.com/path1は、要求がバックエンド サーバーに転送されるときにhttps://www.contoso.com/path1に変更されます。

バックエンド プール

バックエンド プールには、4 種類のバックエンド メンバー (特定の仮想マシン、仮想マシン スケール セット、IP アドレス/FQDN、または App Service) を指定できます。

バックエンド プールを作成した後で、それを 1 つ以上の要求ルーティング規則に関連付ける必要があります。 アプリケーション ゲートウェイ上の各バックエンド プールに対して正常性プローブを構成する必要もあります。 要求のルーティング規則の条件が満たされると、アプリケーション ゲートウェイは、トラフィックを対応するバックエンド プール内の正常なサーバー (正常性プローブによって判別) に転送します。

ヘルスプローブ

Azure Application Gateway は、バックエンド プール内のすべてのサーバーの正常性を監視し、異常と見なされるすべてのサーバーへのトラフィックの送信を自動的に停止します。 プローブはこのような異常なサーバーを継続的に監視し、正常であることを検知すると、ゲートウェイがトラフィックのルーティングを再び開始します。

既定のプローブでは、関連付けられているバックエンド設定とその他のプリセット構成のポート番号が使用されます。 カスタム プローブを使用して、独自の方法で構成できます。

送信元 IP アドレス

プローブのソース IP アドレスは、バックエンド サーバーの種類によって異なります。

  • バックエンド プール内のサーバーがパブリック エンドポイントの場合、ソース アドレスはアプリケーション ゲートウェイのフロントエンド パブリック IP アドレスです。
  • バックエンド プール内のサーバーがプライベート エンドポイントの場合、ソース IP アドレスはアプリケーション ゲートウェイ サブネットのアドレス空間からのものです。

プローブ操作

規則をバックエンド設定とバックエンド プール (およびリスナー) に関連付けることで、ゲートウェイは規則を構成した直後にプローブの起動を開始します。 この図は、ゲートウェイがすべてのバックエンド プール サーバーを個別にプローブする様子を示しています。 届き始めた着信要求は、正常なサーバーにのみ送信されます。 正常なプローブ応答が受信されるまで、バックエンド サーバーは既定で異常としてマークされます。

Azure Application Gateway の正常性プローブ操作の例を示す図。

必要なプローブは、バックエンド サーバーとバックエンド設定の一意の組み合わせに基づいて決定されます。 たとえば、ポート番号が異なる、2 つのサーバーと 2 つのバックエンド設定を含む 1 つのバックエンド プールを持つゲートウェイがあるとします。 これらの個別のバックエンド設定が、それぞれの規則によって同じバックエンド プールに関連付けられている場合、ゲートウェイは、各サーバーのプローブとバックエンド設定の組み合わせを作成します。 これは、[バックエンドの正常性] ページで確認できます。

バックエンドの正常性設定の例を示すスクリーンショット。

さらに、アプリケーション ゲートウェイのすべてのインスタンスは、互いに独立してバックエンド サーバーをプローブします。

注

バックエンド正常性レポートは、それぞれのプローブの更新間隔に基づいて更新され、ユーザーの要求には依存しません。

既定の正常性プローブ

カスタム プローブ構成を設定しない場合、アプリケーション ゲートウェイにより既定の正常性プローブが自動で構成されます。 監視は、バックエンド プール内の構成済みの IP アドレスまたは FQDN に対して HTTP GET 要求を行うことで実行されます。 既定のプローブでは、バックエンドの http 設定が HTTPS に対応するように構成されている場合、プローブはバックエンド サーバーの正常性をテストする際に HTTPS を使用します。

たとえば、バックエンド サーバー A、B、C を使用してポート 80 で HTTP ネットワーク トラフィックを受信するように、アプリケーション ゲートウェイを構成したとします。 既定の正常性監視では、30 秒ごとにこれら 3 つのサーバーの HTTP 応答が正常であるかがテストされます。その際には、各要求に対して 30 秒のタイムアウトが適用されます。 正常な HTTP 応答の状態コードは、200 から 399 の間です。 この場合、正常性プローブの HTTP GET 要求は http://127.0.0.1/ のようになります。 Application Gateway の HTTP 応答コードも参照してください。

サーバー A に対する既定のプローブ チェックが失敗した場合、アプリケーション ゲートウェイはこのサーバーへの要求の転送を停止します。 既定のプローブは、削除後もサーバー A を 30 秒ごとにチェックし続けます。 サーバー A が既定の正常性プローブからの 1 つの要求に正常に応答すると、アプリケーション ゲートウェイはサーバーへの要求の転送を再び開始します。

既定の正常性プローブの設定

プローブのプロパティ 価値 説明
プローブ URL <protocol>://127.0.0.1:<port>/ プロトコルとポートは、プローブが関連付けられているバックエンド HTTP 設定から継承されます
インターバル 30 次の正常性プローブが送信されるまでの秒数です。
タイムアウト 30 アプリケーション ゲートウェイがプローブの応答を待機する秒数です。これを超えると、プローブは異常としてマークされます。 プローブが正常として返された場合は、対応するバックエンドがすぐに正常としてマークされます。
異常なしきい値 3 通常の正常性プローブで障害が発生した場合に送信するプローブの数を制御します。 v1 SKU では、これらの他の正常性プローブは、バックエンドの正常性をすばやく判断するために連続して送信され、プローブの間隔を待つことはありません。 v2 SKU の場合、正常性プローブはその期間を待ちます。 プローブの連続失敗回数が異常のしきい値に達すると、バックエンド サーバーは「ダウン」とマークされます。

既定のプローブは、正常性状態を判断する際に <protocol>://127.0.0.1:<port> だけをチェックします。 カスタム URL をチェックするように正常性プローブを構成するか、その他の設定を変更する必要がある場合は、カスタム プローブを使用する必要があります。

カスタムの正常性プローブ

カスタム プローブを使用すると、正常性監視をより細かく制御できます。 カスタム プローブを使用する場合、カスタム ホスト名、URL パス、プローブ間隔、バックエンド プール インスタンスを「異常」とマークするまでの応答の失敗回数などを構成することができます。

カスタムの正常性プローブの設定

カスタム正常性プローブのプロパティの定義を次の表に示します。

プローブのプロパティ 説明
名前 プローブの名前。 この名前は、バックエンドの HTTP 設定でプローブを識別して参照するために使用されます。
プロトコル プローブを送信するために使用するプロトコル。 これは、関連付けられているバックエンド HTTP 設定で定義されているプロトコルと一致している必要があります
ホスト プローブを送信するホスト名。 v1 SKU では、この値はプローブ要求のホスト ヘッダーに対してのみ使用されます。 v2 SKU では、ホスト ヘッダーと SNI の両方として使用されます
経路 プローブの相対パス。 "/" で始まる有効なパスです
港 / ポート 定義されている場合は、宛先ポートとして使用されます。 それ以外の場合は、関連付けられている HTTP 設定と同じポートを使用します。 このプロパティは v2 SKU でしか利用できません
インターバル プローブの間隔 (秒)。 この値は、2 つの連続するプローブの時間間隔です
タイムアウト プローブは秒単位でタイムアウトします。 このタイムアウト期間内に有効な応答が受信されない場合、プローブは失敗としてマークされます
異常なしきい値 プローブの再試行回数。 プローブの連続失敗回数が異常のしきい値に達すると、バックエンド サーバーは「ダウン」とマークされます

プローブの一致

既定では、状態コードが 200 から 399 の HTTP(S) 応答は正常と見なされます。 カスタム正常性プローブでは、さらに 2 つの一致条件がサポートされます。 一致条件を使用して、正常な応答を行うための既定の解釈を必要に応じて変更できます。

一致条件は、次のとおりです。

  • HTTP 応答の状態コードの一致 - ユーザー指定 http 応答コードまたは応答コードの範囲を受け入れるためのプローブの一致条件。 個々のコンマ区切りの応答状態コードまたは状態コードの範囲がサポートされています。
  • HTTP 応答本文の一致 - HTTP 応答本文をチェックし、ユーザー指定文字列と一致させるプローブの一致条件。 一致ではユーザー指定文字列が応答本文内にあるかどうかのみがチェックされ、完全な正規表現の一致ではありません。 指定した一致は 4,090 文字以下にする必要があります。

一致条件は New-AzApplicationGatewayProbeHealthResponseMatch コマンドレットを使用して指定できます。

例えば：

Azure PowerShell

$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399


$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"

一致条件は、PowerShell の -Match 演算子を使用してプローブ構成に添付できます。

カスタム プローブのユース ケース

  • バックエンド サーバーが認証されたユーザーのみにアクセスを許可する場合、アプリケーション ゲートウェイ プローブは 200 ではなく 403 応答コードを受け取ります。 クライアント (ユーザー) はライブ トラフィックに対して自身を認証するようにバインドされるため、期待される応答として 403 を受け入れるようにプローブ トラフィックを構成できます。
  • バックエンド サーバーにワイルドカード証明書 (*.contoso.com) がインストールされ、異なるサブドメインを提供する場合は、特定のホスト名 (SNI に必要) を持つカスタム プローブを使用して、TLS プローブを正常に確立し、そのサーバーを正常と報告できます。 [バックエンド設定] の [ホスト名の上書き] を [いいえ] に設定すると、異なる受信ホスト名 (サブドメイン) がバックエンドにそのまま渡されます。

ネットワーク セキュリティ グループ (NSG) に関する考慮事項

パブリック プレビューでは、NSG 規則を使用して Application Gateway サブネットを細かく制御できます。 詳細については、こちらをご覧ください。

現在の機能には、いくつかの制限があります。

Application Gateway v1 SKU の TCP ポート 65503 から 65534、宛先サブネットが Any、ソースが GatewayManager サービス タグである v2 SKU の TCP ポート 65200-65535 で受信インターネット トラフィックを許可する必要があります。 このポート範囲は、Azure インフラストラクチャの通信に必要です。

さらに、送信インターネット接続をブロックすることはできません。また、AzureLoadBalancer タグからの受信トラフィックを許可する必要があります。

アプリケーション ゲートウェイの動作

Azure アプリケーション ゲートウェイのしくみの例を示す図。

要求フローとルーティング

Application Gateway は、次のフローを使用してクライアント要求を処理します。

  1. DNS 解決: クライアントは要求を送信する前に、アプリケーション ゲートウェイのドメイン名を解決します。 Azure DNS はフロントエンド IP アドレスを返します。
  2. リスナーがトラフィックを受け入れる: アプリケーション ゲートウェイは、フロントエンド IP アドレス、プロトコル、ポートを使用して構成された 1 つ以上のリスナーで受信トラフィックを受け入れます。
  3. WAF 検査: 有効な場合、アプリケーション ゲートウェイは WAF 規則に対して要求ヘッダーと本文をチェックして、要求が有効か、セキュリティ上の脅威かを判断します。 無効な要求は防止モードでブロックされるか、検出モードでログに記録されます。
  4. 要求ルーティング: ゲートウェイは、リスナーに関連付けられている要求ルーティング規則を評価して、ターゲット バックエンド プールを決定します。
  5. バックエンドの選択: ゲートウェイはラウンドロビン負荷分散を使用して正常なバックエンド サーバーを選択し、HTTP 設定に基づいて新しい TCP セッションを開きます。
  6. TLS に関する考慮事項: HTTP 設定で使用されるプロトコルによって、ゲートウェイとバックエンド サーバー間のトラフィックが暗号化 (エンド ツー エンド TLS) か暗号化されていないかが決まります。

Application Gateway は、パブリック IP アドレスを使用してインターネットに接続するロード バランサーとして、またはプライベート IP アドレスのみを使用する内部ロード バランサーとして機能できます。

バックエンド サーバーの DNS 解決

バックエンド プール サーバーが完全修飾ドメイン名 (FQDN) で構成されている場合、Application Gateway は DNS 参照を実行してドメイン名を IP アドレスに解決します。 解決された IP は、DNS レコードの TTL (有効期間) 中にキャッシュされます。 カスタム DNS サーバーを使用する場合は、信頼できる操作のために、同じ DNS 値で一貫して応答するようにします。

リクエストの変更とヘッダー

Application Gateway は、バックエンド サーバーに転送する前に、すべての要求に追加のヘッダーを挿入します。 これらのヘッダーには、x-forwarded-for、x-forwarded-port、x-forwarded-proto、x-original-host、x-original-url、x-appgw-trace-id が含まれます。これらのヘッダーは、元の要求に関する重要なコンテキストを提供し、ゲートウェイを介して適切なログ記録とトレースを有効にします。

書き換えルールを使用して要求と応答のヘッダーと URL を変更するか、パスオーバーライド設定を使用して URI パスを変更するように Application Gateway を構成できます。 ただし、そのように構成されていない限り、すべての受信要求は、受信したとおりにバックエンドにプロキシされます。