Azure Application Gateway のしくみ

  • 5 分

Azure Application Gateway は一連のコンポーネントで構成されており、これらを組み合わせて、要求を安全にルーティングして負荷を分散し、Web サーバーのプール全体にルーティングします。 Application Gateway には、次のようなコンポーネントがあります。

Diagram that shows Azure Application Gateway components.

  • フロントエンド IP アドレス: クライアントの要求は、フロントエンド IP アドレスによって受信されます。 Application Gateway は、パブリック IP アドレス、プライベート IP アドレス、またはその両方を持つように構成できます。 Application Gateway は、複数のパブリック IP アドレスと 1 つのプライベート IP アドレスを持つことはできません。
  • リスナー: Application Gateway では、着信した要求を受け取るために 1 つまたは複数のリスナーが使われます。 リスナーは、プロトコル、ポート、ホスト、IP アドレスの指定された組み合わせに到着したトラフィックを受け付けます。 各リスナーは、指定されたルーティング規則に従って、サーバーのバックエンド プールに要求をルーティングします。 リスナーには、"基本" と "マルチサイト" があります。 ''基本'' リスナーでは、URL 内のパスに基づく要求のルーティングのみが行われます。 ''マルチサイト'' リスナーでは、URL のホスト名要素を使った要求のルーティングも可能です。 リスナーでは、ユーザーと Application Gateway の間でアプリケーションをセキュリティ保護するために、TLS/SSL 証明書の処理も行われます。
  • ルーティング規則: ルーティング規則により、リスナーとバックエンド プールがバインドされます。 規則では、要求の URL 内のホスト名要素とパス要素を解釈する方法、および適切なバックエンド プールに要求を転送する方法が指定されています。 また、ルーティング規則には HTTP 設定のセットが関連付けられています。 これらの HTTP 設定により、Application Gateway とバックエンド サーバーの間でトラフィックを暗号化するかどうか (およびその方法) を指示します。 その他の構成情報としては、プロトコル、セッションの持続性、接続ドレイン、要求のタイムアウト期間、正常性プローブがあります。

Application Gateway での負荷分散

Application Gateway では、ラウンドロビン メカニズムを使って、各バックエンド プール内のサーバーに送信された要求が自動的に負荷分散されます。 負荷分散は、Application Gateway のルーティングによって実装される OSI レイヤー 7 ルーティングで動作します。つまり、Application Gateway ルールによって使われるルーティング パラメーター (ホスト名とパス) に基づいて、要求の負荷分散が行われます。 それに対し、Azure Load Balancer などの他のロード バランサーは OSI レイヤー 4 のレベルで機能し、トラフィックは要求のターゲットの IP アドレスに基づいて分散されます。

同じセッション内の 1 つのクライアントに対するすべての要求がバックエンド プール内の同じサーバーに確実にルーティングされるようにする必要がある場合は、セッションの持続性を構成できます。

Web アプリケーション ファイアウォール

"Web アプリケーション ファイアウォール" (WAF) は、受信した要求をリスナーに達する前に処理するオプションのコンポーネントです。 Web アプリケーション ファイアウォールでは、Open Web Application Security Project (OWASP) に基づいて、各要求で多くの一般的な脅威がチェックされます。 次のような一般的な脅威があります。SQL インジェクション、クロスサイト スクリプティング、コマンド インジェクション、HTTP 要求の獲得、HTTP 応答の分割、リモート ファイルの取り込み、ボット、クローラー、スキャナー、HTTP プロトコル違反と例外。

OWASP では、攻撃を検出するための一般的な規則のセットが定義されています。 これらの規則は、コア ルール セット (CRS) と呼ばれます。 そのルール セットは、攻撃の高度化に対応して常に再検討されています。 WAF では、CRS 3.2、3.1、3.0、および 2.2.9 の 4 つのルール セットがサポートされています。 CRS 3.1 が既定値です。 必要に応じて、ルール セット内の特定の規則だけを選択し、特定の脅威を対象にすることができます。 さらに、ファイアウォールをカスタマイズし、要求で調べる要素を指定したり、大量のアップロードによってサーバーが過負荷になるのを防ぐためにメッセージのサイズを制限したりできます。

バックエンド プール

バックエンド プールは、Web サーバーのコレクションであり、仮想マシンの固定のセット、仮想マシン スケール セット、Azure App Services によってホストされているアプリ、またはオンプレミス サーバーのコレクションで構成される可能性があります。

各バックエンド プールには、作業をプール全体に分散させるロード バランサーが関連付けられています。 プールを構成するときに、各 Web サーバーの IP アドレスまたは名前を指定します。 バックエンド プール内のすべてのサーバーは、そのセキュリティ設定を含め、同じ方法で構成する必要があります。

TLS/SSL を使用している場合、バックエンド プールには、バックエンド サーバーの認証に使用される証明書を参照する HTTP 設定があります。 ゲートウェイでは、この証明書を使用してトラフィックが再暗号化されてから、バックエンド プール内のいずれかのサーバーに送信されます。

Azure App Service を使用してバックエンド アプリケーションをホストする場合は、バックエンド プールに接続するために Application Gateway に証明書をインストールする必要はありません。 通信はすべて自動的に暗号化されます。 Application Gateway ではサーバーが信頼されます。それらは Azure によって管理されるためです。

Application Gateway では ''規則'' を使用して、その受信ポートで受信されたメッセージを、バックエンド プール内のサーバーに送信する方法を指定します。 サーバーで TLS/SSL が使用されている場合は、以下を示すように規則を構成する必要があります。

  • サーバーでは、HTTPS プロトコル経由のトラフィックが予期される。
  • トラフィックの暗号化とサーバーへの接続の認証に使用する証明書。

Application Gateway のルーティング

ゲートウェイで、バックエンド プール内の Web サーバーにクライアント要求がルーティングされたとき、ゲートウェイに対して構成されているルールのセットを使って、要求の送り先が決定されます。 このクライアント要求トラフィックの主要なルーティング方法としては、パスベースのルーティングと複数サイトのルーティングの 2 つがあります。

パスベースのルーティング

パスベースのルーティングでは、異なる URL パスの要求を、異なるバックエンド サーバーのプールに送信します。 たとえば、パスが /video/* である要求を、ビデオ ストリーミングを処理するために最適化されたサーバーが含まれているバックエンド プールに転送し、/images/* に対する要求を、画像の取得を処理するサーバー プールに転送できます。

Diagram that depicts path-based routing in Azure Application Gateway.

複数サイトのルーティング

複数サイトのルーティングでは、同じ Application Gateway のインスタンスで複数の Web アプリケーションを構成します。 マルチサイトの構成では、アプリケーション ゲートウェイの IP アドレスに複数の DNS 名 (CNAME) を登録し、各サイトの名前を指定します。 アプリケーション ゲートウェイでは、個別のリスナーを使って各サイトの要求を待ちます。 各リスナーでは、異なるルールに要求が渡されて、異なるバックエンド プール内のサーバーに要求をルーティングできます。 たとえば、http://contoso.com に対するすべての要求をあるバックエンド プール内のサーバーに転送し、http://fabrikam.com に対する要求を別のバックエンド プールに転送できます。 次の図はこの構成を示したものです。

Diagram that depicts multi-site routing in Azure Application Gateway.

マルチサイトの構成は、各テナントに Web アプリケーションをホストする独自の仮想マシンがある、または他のリソースのセットがあるマルチテナント アプリケーションをサポートするのに便利です。

Application Gateway のルーティングには、次のような機能もあります。

  • リダイレクト。 リダイレクトは、別のサイトに対して、または HTTP から HTTPS に対して使用できます。
  • HTTP ヘッダーを書き換える。 HTTP ヘッダーを使用すると、クライアントとサーバーは、要求または応答と共にパラメーター情報を渡すことができます。
  • カスタム エラー ページ. Application Gateway では、既定のエラー ページを表示する代わりに、カスタム エラー ページを作成することができます。 カスタム エラー ページでは、独自のブランディングとレイアウトを使用することができます。

TLS/SSL 終端

TLS/SSL 接続をアプリケーション ゲートウェイで終端させると、CPU に負荷がかかる TLS/SSL 終端のワークロードがサーバーからオフロードされます。 また、サーバーに証明書をインストールして TLS/SSL を構成する必要はありません。

エンドツーエンドの暗号化が必要な場合、Application Gateway では秘密キーを使用してゲートウェイ上のトラフィックの暗号化を解除してから、バックエンド プールで実行されているサービスの公開キーを使ってもう一度再暗号化できます。

トラフィックはフロントエンド ポートを介してゲートウェイに入ります。 多数のポートを開き、Application Gateway はこれらのポートのいずれでもメッセージを受信できます。 リスナーは、トラフィックがポートを介してゲートウェイに入るときに最初に直面するものです。 リスナーは、特定のホスト名と、特定の IP アドレス上の特定のポートをリッスンするように設定されています。 リスナーでは、TLS/SSL 証明書を使用して、ゲートウェイに入るトラフィックの暗号化を解除することができます。 その後、リスナーでは、受信要求をバックエンド プールに送信するように定義した規則が使用されます。

Diagram that depicts TLS/SSL termination in Azure Application Gateway.

アプリケーション ゲートウェイを介して Web サイトまたは Web アプリケーションを公開することは、サーバーを Web に直接接続しないことも意味します。 アプリケーション ゲートウェイでポート 80 またはポート 443 のみを公開し、そのポートをバックエンド プール サーバーに転送します。 この構成では、Web サーバーにはインターネットから直接アクセスできないため、インフラストラクチャの攻撃面が減ります。

正常性プローブ

正常性プローブにより、バックエンド プールで負荷分散に使用できるサーバーを決定します。 Application Gateway では、正常性プローブを使用して要求をサーバーに送信します。 200 から 399 までの範囲の状態コードを含む HTTP 応答がサーバーから返された場合、サーバーは正常と見なされます。 正常性プローブを構成しないと、Application Gateway では 30 秒間待機してからサーバーが使用不能と判断する既定のプローブが作成されます。 正常性プローブにより、バックエンド プール内の応答しないまたは障害が発生した Web エンドポイントにはトラフィックが送信されません。

自動スケール

Application Gateway では、自動スケーリングがサポートされており、トラフィック負荷パターンの変化に基づいてスケールアップまたはスケールダウンできます。 また、自動スケールにより、プロビジョニングの間にデプロイのサイズまたはインスタンスの数を選択する必要がなくなります。

WebSocket と HTTP/2 トラフィック

Application Gateway は、WebSocket および HTTP/2 プロトコルをネイティブにサポートしています。 WebSocket および HTTP/2 プロトコルによって、長時間実行されている TCP 接続上でサーバーとクライアント間の全二重通信が可能になります。 この種の通信は、HTTP ベースの実装では必須だったポーリングを使うことなく、Web サーバーとクライアント間でより対話的であり、双方向で通信できます。 これらのプロトコルは、(HTTP とは異なり) オーバーヘッドが少なく、複数の要求や応答で同じ TCP 接続を再利用できるため、リソースをより効率的に使用できます。 これらのプロトコルは、従来の HTTP ポート 80 および 443 上で動作するよう設計されています。