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

  • [アーティクル]

アプリケーション ゲートウェイは、クライアントからの単一接続点として機能します。 アプリケーション ゲートウェイは、着信するアプリケーション トラフィックを、Azure VM、仮想マシン スケール セット、Azure App Service、オンプレミス/外部サーバーなど、複数のバックエンド プールに配布します。 トラフィックを配布するために、アプリケーション ゲートウェイではこの記事で説明する各種コンポーネントが使用されます。

The components used in an application gateway

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

フロントエンド IP アドレスとは、アプリケーション ゲートウェイに関連付けられた IP アドレスのことです。 アプリケーション ゲートウェイは、パブリック IP アドレス、プライベート IP アドレス、またはその両方を持つように構成できます。 アプリケーション ゲートウェイでは、パブリックまたはプライベート IP アドレスが 1 つサポートされます。 仮想ネットワークとパブリック IP アドレスは、アプリケーション ゲートウェイと同じ場所に存在する必要があります。 フロントエンド IP アドレスは、作成された後、リスナーに関連付けられます。

静的パブリック IP アドレスと動的パブリック IP アドレス

Azure Application Gateway V2 SKU は、静的内部 IP アドレスと静的パブリック IP アドレスの両方をサポートするよう構成することも、静的パブリック IP アドレスのみをサポートするよう構成することもできます。 静的内部 IP アドレスのみをサポートするよう構成することはできません。

V1 SKU は、静的または動的な内部 IP アドレスと動的パブリック IP アドレスをサポートするように構成できます。 Application Gateway の動的 IP アドレスは、実行中のゲートウェイでは変化しません。 ゲートウェイの停止時または起動時にのみ変化する可能性があります。 システム障害、更新、Azure ホストの更新などでは変化しません。

アプリケーション ゲートウェイに関連付けられた DNS 名は、そのゲートウェイのライフサイクル全体を通して変更されません。 そのため、CNAME エイリアスを使用し、アプリケーション ゲートウェイの DNS アドレスを参照してください。

リスナー

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

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

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

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

Port

ポートとは、リスナーがクライアント要求を待つ場所です。 v1 および v2 SKU のポートは以下のように構成できます。

SKU サポートされるポート範囲 例外
V2 1 から 64999 22
V1 1 から 65502 3389

プロトコル

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

Note

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

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

HTTPS リスナーは TLS 終端に使用します。 HTTPS リスナーは暗号化と解読の作業負荷をアプリケーション ゲートウェイにまかせるため、Web サーバーはオーバーヘッドの負担から解放されます。

カスタム エラー ページ

アプリケーション ゲートウェイでは、既定のエラー ページを表示する代わりに、カスタム エラー ページを作成できます。 カスタム エラー ページでは、独自のブランディングとレイアウトを使用することができます。 要求がバックエンドに到達できない場合、Application Gateway にはカスタム エラー ページが表示されます。

詳しくは、Application Gateway のカスタム エラー ページの作成に関するページをご覧ください。

リスナーの種類

リスナーには、次の 2 つの種類があります:

  • ベーシック。 このタイプのリスナーでは、1 つのドメイン サイトがリッスンされます。この構成では、アプリケーション ゲートウェイの IP アドレスに対して 1 つの DNS マッピングが適用されます。 アプリケーション ゲートウェイの背後に 1 つのサイトをホストする場合は、このリスナー構成が必要になります。

  • マルチサイト。 このリスナー構成は、同じアプリケーション ゲートウェイ上の複数の Web アプリケーションに対して、ホスト名またはドメイン名に基づいてルーティングを構成する場合に必要です。 最大で 100 個以上の Web サイトを 1 つのアプリケーション ゲートウェイに追加することによって、デプロイに効率的なトポロジを構成できます。 各 Web サイトは、独自のバックエンド プールに送られるようにすることができます。 たとえば、contoso.com、fabrikam.com、adatum.com という 3 つのドメインで、アプリケーション ゲートウェイの IP アドレスが示されています。 マルチサイト リスナーを 3 つ作成し、リスナーごとにポートとプロトコル設定を構成します。

    マルチサイト リスナーでワイルドカードのホスト名を定義し、リスナー 1 つにつき最大 5 つのホスト名を定義することもできます。 詳細については、リスナーでのワイルドカードのホスト名に関する記事を参照してください。

    マルチサイト リスナーの構成方法の詳細については、Azure portal を使用した Application Gateway での複数サイトのホスティングに関する記事をご覧ください。

リスナーを作成したら、要求ルーティング規則に関連付ける必要があります。 この規則により、リスナー上で受信された要求がバック エンドにルーティングされる方法が決まります。 要求ルーティング規則には、ルーティング先のバックエンド プールと、バックエンド ポートやプロトコルなどを指定する HTTP 設定も含まれています。

要求ルーティング規則

要求ルーティング規則は、リスナーのトラフィックを転送する方法を決定することから、アプリケーション ゲートウェイの主要なコンポーネントとなっています。 この規則では、リスナー、バックエンド サーバー プール、およびバックエンド HTTP の各設定がバインドされます。

リスナーが要求を受け取ると、要求ルーティング規則により要求がバックエンドに転送されるか、他の場所にリダイレクトされます。 要求がバックエンドに転送される場合、要求ルーティング規則により、転送先となるバックエンド サーバー プールが決定されます。 要求ルーティング規則では、要求のヘッダーを書き直すかどうかも決定されます。 リスナーは、1 つの規則に 1 つだけアタッチできます。

要求ルーティング規則には、次の 2 つの種類があります。

  • ベーシック。 関連付けられたリスナー (例: blog.contoso.com/*) 上のすべての要求が、関連付けられた HTTP 設定を使用して、関連付けられたバックエンド プールに転送されます。

  • パスベース。 このルーティング規則では、関連付けられたリスナー上の要求を、要求内の URL に基づいて、特定のバックエンド プールにルーティングできます。 要求内の URL のパスがパスベース規則内のパス パターンと一致した場合は、その規則により要求がルーティングされます。 パスのパターンは URL パスのみに適用され、そのクエリ パラメーターには適用されません。 リスナー要求の URL のパスがいずれのパスベース規則とも一致しなかった場合、要求は既定のバックエンド プールと HTTP 設定にルーティングされます。

詳しくは、URL ベースのルーティングに関する記事をご覧ください。

リダイレクトのサポート

要求ルーティング規則では、アプリケーション ゲートウェイ上でトラフィックをリダイレクトすることもできます。 これは一般的なリダイレクト メカニズムであり、規則を利用することで、定義した任意のポート間でリダイレクトできます。

リダイレクト先として別のリスナー (HTTP から HTTPS への自動リダイレクトに便利) や外部サイトを選択できます。 リダイレクトを一時的なものとして指定することも、いつも同じ場所にリダイレクトすることもできます。URI パスとクエリ文字列をリダイレクト先の URL に追加することもできます。

詳しくは、アプリケーション ゲートウェイでのトラフィックのリダイレクトに関する記事をご覧ください。

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

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

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

詳しくは、「Application Gateway で HTTP ヘッダーと URL を書き換える」を参照してください。

HTTP 設定

アプリケーション ゲートウェイは、このコンポーネントに詳細があるポート番号、プロトコル、その他の設定を使用し、(HTTP 設定が含まれる要求ルーティング規則に指定されている) バックエンド サーバーにトラフィックをルーティングします。

アプリケーション ゲートウェイとバックエンド サーバーの間でトラフィックが暗号化されるかどうか (エンドツーエンドの TLS が提供されるかどうか) は、HTTP 設定で使用されているポートやプロトコルによって決定されます。

このコンポーネントは次の目的にも使用されます。

  • Cookie ベースのセッション アフィニティを利用し、ユーザー セッションを同じサーバー上で維持するかどうかを決定する。

  • 接続のドレインを使用し、バックエンド プール メンバーを正常に削除する。

  • カスタム プローブを関連付け、バックエンドの正常性を監視する。要求タイムアウトの間隔を設定する。要求のホスト名とパスをオーバーライドする。App Service バックエンドの設定をワンクリックで簡単に指定できるようにする。

バックエンド プール

バックエンド プールにより、要求にサービスを提供するバックエンド サーバーに要求がルーティングされます。 バックエンド プールに含まれるもの:

  • NIC
  • 仮想マシン スケール セット
  • パブリック IP アドレス
  • 内部 IP アドレス
  • FQDN
  • マルチテナント バックエンド (App Service など)

Application Gateway バックエンド プールのメンバーは、可用性セットには関連付けられません。 アプリケーション ゲートウェイは、それが属している仮想ネットワークの外部にあるインスタンスとの通信が可能です。 そのため、IP 接続がある限り、バックエンド プールのメンバーを、クラスターやデータ センターをまたいで、または Azure の外部に配置したりすることができます。

バックエンド プール メンバーとして内部 IP を使用する場合、仮想ネットワーク ピアリングまたは VPN ゲートウェイを使用する必要があります。 仮想ネットワーク ピアリングはサポート対象であり、他の仮想ネットワークにおけるトラフィックの負荷分散に適しています。

アプリケーション ゲートウェイは、トラフィックが許可されていれば、Azure ExpressRoute や VPN トンネルによって接続されているオンプレミスのサーバーとも通信できます。

要求の種類ごとに、異なるバックエンド プールを作成することもできます。 たとえば、一般的な要求用のバックエンド プールを 1 つ作成したうえで、アプリケーションのマイクロ サービスに対する要求については、別のバックエンド プールを作成することもできます。

仮想マシン スケール セットをバックエンド プール メンバーとして追加した後、仮想マシン スケール セット インスタンスをアップグレードする必要があります。 スケール セット インスタンスをアップグレードするまで、バックエンドは異常になります。

正常性プローブ

既定では、アプリケーション ゲートウェイによりそのバック エンド プールにあるすべてのリソースの状態が監視され、異常なリソースがプールから自動的に削除されます。 その後、異常なインスタンスが監視され、それらのインスタンスが利用可能になって、正常性プローブに応答するようになったら、それらが正常なバックエンド プールに追加しなおされます。

既定の正常性プローブによる監視を行うだけでなく、アプリケーションの要件に合わせて正常性プローブをカスタマイズすることもできます。 カスタム プローブを使用すると、正常性監視をより細かく制御できます。 カスタム プローブを使用する場合、カスタム ホスト名、URL パス、プローブ間隔、バックエンド プール インスタンスを異常としてマークするまでの応答の失敗回数、カスタム ステータス コード、応答本文の一致などを構成することができます。カスタム プローブでは、各バックエンド プールの正常性を監視するように構成することをお勧めします。

詳しくは、アプリケーション ゲートウェイの正常性の監視に関する記事をご覧ください。

次のステップ

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