Application Gateway の作成と構成

10 分

Application Gateway を構成する一連のコンポーネントの連携により、要求が Web サーバーのプールにルーティングされ、これらの Web サーバーの正常性が確認されます。これらのコンポーネントがどのように関連し、Application Gateway でどのような役割を果たすかを見てみましょう。

Application Gateway コンポーネントを視覚化した図。

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

クライアントの要求は、"フロントエンド IP アドレス" によって受信されます。 Application Gateway は、パブリック IP アドレス、プライベート IP アドレス、またはその両方を持つように構成できます。 Application Gateway は、複数のパブリック IP アドレスおよび複数のプライベート IP アドレスを持つことはできません。

リスナー

Application Gateway では、着信した要求を受け取るために 1 つまたは複数の "リスナー" が使われます。リスナーは、プロトコル、ポート、ホスト、IP アドレスの指定された組み合わせに到着したトラフィックを受け付けます。各リスナーは、指定されたルーティング規則に従って、サーバーのバックエンドプールに要求をルーティングします。リスナーには、"基本" と "マルチサイト" があります。基本リスナーでは、URL 内のパスに基づく要求のルーティングのみが行われます。マルチサイトリスナーでは、URL のホスト名要素を使った要求のルーティングも可能です。

リスナーでは、ユーザーと Application Gateway の間でアプリケーションをセキュリティ保護するために、SSL 証明書の処理も行われます。

ルーティング規則

"ルーティング規則" により、リスナーとバックエンドプールがバインドされます。規則では、要求の URL 内のホスト名要素とパス要素を解釈する方法と、要求を適切なバックエンドプールに転送する方法が指定されています。また、ルーティング規則には HTTP 設定のセットが関連付けられています。これらの設定では、Application Gateway とバックエンドサーバーの間でトラフィックを暗号化するかどうか (およびその方法) と、次のような他の構成情報が示されています。

プロトコル (HTTP または HTTPS)。
セッションの持続性。あるクライアントセッションのすべての要求を、負荷分散で複数のサーバー間に配布するのではなく、同じ Web サーバーに渡します。
接続のドレイン。バックエンドプールからのサーバーの正常な削除を有効にします。
要求のタイムアウト期間 (秒単位)。
正常性プローブ。バックエンドプール内のサーバーが使用できるかどうかを判断するために使われる、プローブ URL、タイムアウト期間、その他のパラメーターを指定します。

バックエンドプール

"バックエンドプール" とは、Web サーバーのコレクションのことです。プールを構成するときに、各 Web サーバーの IP アドレスと、要求をリッスンするポートを指定します。各プールでは、仮想マシンの固定のセット、仮想マシンスケールセット、Azure App Services によってホストされているアプリ、またはオンプレミスサーバーのコレクションを指定できます。各バックエンドプールには、作業をプール全体に分散させるロードバランサーが関連付けられています

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

"Web アプリケーションファイアウォール" (WAF) は、受信した要求をリスナーに達する前に処理するオプションのコンポーネントです。 Web アプリケーションファイアウォールでは、Open Web Application Security Project (OWASP) に基づいて、各要求で多くの一般的な脅威がチェックされます。次に例を示します。

SQL インジェクション
クロスサイトスクリプティング
コマンドインジェクション
HTTP 要求スマグリング
HTTP 応答分割
リモートファイルインクルージョン
ボット、クローラー、スキャナー
HTTP プロトコル違反および異常

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

ご自分のアプリケーションゲートウェイで WAF を有効にするには、ゲートウェイを作成するときに WAF 層を選びます。

正常性プローブ

正常性プローブは、バックエンドプール内で負荷分散に使用可能なサーバーをロードバランサーが特定するのを支援する重要な要素です。 Application Gateway では、正常性プローブを使ってサーバーに要求が送信されます。 200 から 399 の範囲の状態コードを含む HTTP 応答がサーバーから返された場合、サーバーは正常と見なされます。

正常性プローブを構成しないと、Application Gateway では 30 秒間待機してからサーバーが使用不能と判断する既定のプローブが作成されます。

Application Gateway のネットワーク要件

Application Gateway には、動作するための仮想ネットワークが必要です。 Application Gateway をセットアップする前に、この仮想ネットワークと専用のサブネットを作成する必要があります。 Application Gateway では、内部で使うためと、ゲートウェイがスケールアウトする場合に各インスタンスと通信するために、多数のプライベートアドレスが使われます。たとえば、4 インスタンスにスケールアウトする場合は、/28 サイズのサブネットを作成しますもっと多くのインスタンスに拡大する可能性がある場合は、さらに大きいサブネットを作成します。

パブリック IP アドレスを使って Application Gateway を公開することも、仮想ネットワーク内のプライベート IP アドレスだけを指定することによって公開しないでおくこともできます。これは、Application Gateway を使って負荷分散を提供する内部サイトがある場合に便利です。

Application Gateway のオプション

アプリケーションゲートウェイは、Standard レベルまたは WAF レベルで作成できます。また、パフォーマンス、価格、スケーラビリティが異なる次の 3 つのサイズから選択できます: Small、Medium、Large。

Standard レベルと WAF レベルは、V1 と V2 の 2 つのバージョンで利用できます。 V2 では Azure Availability Zones がサポートされますが、現在はプレビュー段階です。

Application Gateway では、手動スケーリングと自動スケーリングがサポートされます。自動スケーリングを選択すると、Application Gateway はアプリケーションのトラフィックに応じて自動的にスケールアウトおよびスケールインします。 Application Gateway のインスタンスの最大数と最小数を制限することができます。

ゲートウェイを作成して構成する

Azure portal、Azure PowerShell、または Azure CLI を使って、アプリケーションゲートウェイの作成と構成を行うことができます。 Azure CLI の場合、新しいゲートウェイを作成するには az network application-gateway create コマンドを使います。 PowerShell の方がよければ、New-AzApplicationGateway コマンドレットを使用できます。また、ほとんどの操作は Azure portal を使って実行することもできます。

ゲートウェイのコンポーネントの構成を調べたり変更したりするには、Azure CLI の az network application-gateway http-listener、az network application-gateway rule、az network application-gateway address-pool、az network application-gateway http-settings、az network application-gateway front-end-port コマンドを使用できます。 PowerShell では、Get-AzApplicationGateway* および Set-AzApplicationGateway* シリーズのコマンドレットによって同じ操作が提供されます。

ここでデプロイした車両部門 Web サイト用のアプリケーションゲートウェイを作成して構成しましょう。