Application Gateway のマルチサイト ホスティング

  • [アーティクル]

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

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

Multi-site Application Gateway

重要

v1 SKU では、規則はポータルに一覧表示されている順序で処理されます。 v2 SKU の場合、[ルールの優先度] を使用して処理順序を指定します。 基本リスナーを構成する前に、まずマルチサイト リスナーを構成することを強くお勧めします。 そうすることで、トラフィックが確実に適切なバックエンドにルーティングされます。 基本リスナーが先に表示されていて、なおかつ受信要求と一致した場合、そのリスナーによって要求が処理されます。

http://contoso.com の要求は ContosoServerPool にルーティングされ、http://fabrikam.com は FabrikamServerPool にルーティングされます。

同様に、同じ親ドメインの複数のサブドメインを、同じアプリケーション ゲートウェイ デプロイでホストすることができます。 たとえば、http://blog.contoso.com および http://app.contoso.com を、単一のアプリケーション ゲートウェイ デプロイでホストできます。

要求ルーティング規則の評価順序

マルチサイト リスナーを使用してクライアント トラフィックが正しいバックエンドに確実にルーティングされるようにするには、要求ルーティング規則が正しい順序で存在することが重要です。 たとえば、*.contoso.com と shop.contoso.com のホスト名が関連付けられている 2 つのリスナーがある場合、shop.contoso.com ホスト名を持つリスナーは、*.contoso.com を持つリスナーの前に処理される必要があります。 *.contoso.com を持つリスナーが最初に処理されると、クライアント トラフィックはより具体的な shop.contoso.com リスナーによって受信されません。

規則の順序を確立するには、リスナーに関連付けられている要求ルーティング規則に [優先度] フィールド値を指定します。 1 から 20000 までの整数値を指定できます。1 が最高の優先度で、20000 が最低の優先度です。 受信クライアント トラフィックが複数のリスナーと一致する場合、最も優先度の高い要求ルーティング規則が要求の処理に使用されます。 要求ルーティング規則ごとに、一意の優先度の値が必要です。

[優先度] フィールドは、要求ルーティング規則の評価の順序にのみ影響します。これにより PathBasedRouting 要求ルーティング規則内のパスベースの規則の評価順序が変更されることはありません。

Note

規則の優先度を使用する場合は、既存のすべての要求ルーティング規則に対して規則優先度フィールド値を指定する必要があります。 規則優先度フィールドが使用されると、作成される新しいルーティング規則では、その構成の一部として規則優先度フィールドの値が必要になります。

重要

API バージョン 2021-08-01 以降の規則優先度フィールドは、要求ルーティング規則の必須フィールドです。 API バージョン 2021-08-01 以上、ポータル、Azure PowerShell、Azure CLI を使用して構成の更新を適用する場合、最初の PUT 呼び出しの一部としての現在の評価順序に基づいて、既存の要求ルーティング規則の規則優先度フィールド値が自動的に設定されます。 要求ルーティング規則に対する今後の更新では、構成の一部として規則優先度フィールドを指定する必要が生じます。

リスナーにおけるワイルドカードのホスト名

Application Gateway では、マルチサイト HTTP(S) リスナーを使用したホストベースのルーティングが可能です。 これで、ホスト名でアスタリスク (*) と疑問符 (?) などのワイルドカード文字を使用でき、マルチサイト HTTP(S) リスナーごとに最大 5 つのホスト名を使用できます。 たとえば、*.contoso.com のようにします。

ホスト名でワイルドカード文字を使用すると、1 つのリスナー内で複数のホスト名と一致させることができます。 たとえば、*.contoso.com は、ecom.contoso.com、b2b.contoso.com、customer1.b2b.contoso.com などと一致させることができます。 ホスト名の配列を使用すると、1 つのリスナーに対して複数のホスト名を構成し、バックエンド プールに要求をルーティングすることができます。 たとえば、リスナーには、両方のホスト名に対する要求を受け入れる contoso.com, fabrikam.com を含めることができます。

Wildcard Listener

Note

この機能は、Application Gateway の Standard_v2 および WAF_v2 SKU でのみ使用できます。

Azure PowerShell の場合は、-HostName ではなく -HostNames を使用する必要があります。 HostNames を使用すると、最大 5 つのホスト名をコンマ区切り値として指定でき、ワイルドカード文字を使用できます。 たとえば、-HostNames "*.contoso.com","*.fabrikam.com" のようにします。

Azure CLI の場合は、--host-name ではなく --host-names を使用する必要があります。 host-names を使用すると、最大 5 つのホスト名をコンマ区切り値として指定でき、ワイルドカード文字を使用できます。 たとえば、--host-names "*.contoso.com,*.fabrikam.com" のようにします。

Azure portal のマルチサイト リスナーで、[複数/ワイルドカード] ホストの種類を選択し、使用できるワイルドカード文字を使用して最大 5 つのホスト名を指定する必要があります。

Wildcard Listener UI

ホスト名フィールドで使用できる文字

  • (A-Z,a-z,0-9) - 英数字
  • - - ハイフンまたはマイナス
  • . - 区切り記号としてのピリオド
  • * - 許可された範囲内の複数の文字と一致することができます
  • ? - 許可された範囲内の 1 つの文字と一致することができます

リスナーでワイルドカード文字と複数のホスト名を使用する場合の条件

  • 1 つのリスナーでは最大で 5 つのホスト名のみを指定できます
  • アスタリスク * は、ドメイン スタイルの名前またはホスト名の構成要素で 1 回だけ使用できます。 たとえば、component1*.component2*.component3 などです。 (*.contoso-*.com) は有効です。
  • ホスト名では、アスタリスク * を最大で 2 つまで使用できます。 たとえば、*.contoso.* は有効ですが、*.contoso.*.*.com は無効です。
  • ホスト名で使用できるワイルドカード文字は最大 4 つです。 たとえば、????.contoso.com、w??.contoso*.edu.* は有効ですが、????.contoso.* は無効です。
  • ホスト名の 1 つの構成要素でアスタリスク * と疑問符 ? を一緒に使用すること (*? または ?* または **) は無効です。 たとえば、*?.contoso.com や **.contoso.com は無効です。

リスナーでワイルドカードまたは複数のホスト名を使用する場合の考慮事項と制限事項

  • SSL ターミネーションとエンド ツー エンド SSL では、プロトコルを HTTPS として構成し、リスナー構成で使用される証明書をアップロードする必要があります。 マルチサイト リスナーの場合は、ホスト名も入力できます。通常、これは SSL 証明書の CN です。 リスナーで複数のホスト名を指定する場合、またはワイルドカード文字を使用する場合は、次の点を考慮する必要があります。
    • *.contoso.com のようなワイルドカードのホスト名の場合、*.contoso.com のような CN を含むワイルドカード証明書をアップロードする必要があります
    • 同じリスナーで複数のホスト名が指定されている場合は、指定されているホスト名と一致する CN が含まれる SAN 証明書 (サブジェクトの別名) をアップロードする必要があります。
  • 正規表現を使用してホスト名を指定することはできません。 ホスト名のパターンを構成するには、アスタリスク (*) や疑問符 (?) などのワイルドカード文字のみを使用できます。
  • バックエンドの正常性チェックでは、HTTP の設定ごとに複数のカスタム プローブを関連付けることはできません。 代わりに、バックエンドで Web サイトの 1 つをプローブするか、"127.0.0.1" を使用してバックエンド サーバーの localhost をプローブすることができます。 ただし、リスナーでワイルドカードまたは複数のホスト名を使用すると、指定したすべてのドメイン パターンに対する要求が、規則の種類 (基本またはパスベース) に応じてバックエンド プールにルーティングされます。
  • "hostname" プロパティは入力として 1 つの文字列を受け取ります。ワイルドカード以外のドメイン名を 1 つだけ指定できます。 "hostname" プロパティは入力として文字列の配列を受け取ります。ワイルドカードのドメイン名を最大 5 つ指定できます。 両方のプロパティを同時に使用することはできません。

マルチサイト リスナーでワイルドカード ホスト名を構成する方法に関するステップ バイ ステップ ガイドについては、Azure PowerShell を使用したマルチサイトの作成または Azure CLI の使用に関する記事を参照してください。

TLS および TCP プロトコル リスナーのマルチサイト リスナー

マルチサイト機能は Layer4 プロキシでも使用できますが、その TLS リスナーに対してのみ使用できます。 TLS リスナーにドメイン名を指定することで、各アプリケーションのトラフィックをそのバックエンド プールに送信できます。 TLS リスナーでのマルチサイト機能を動作させるために、Application Gateway はサーバー名表示 (SNI) 値を使います (クライアントは主に SNI 拡張機能を提示して、正しい TLS 証明書をフェッチします)。 マルチサイト TLS リスナーは、受信接続の TLS ハンドシェイク データからこの SNI 値を選び、その接続を適切なバックエンド プールにルーティングします。 TCP 接続には本質的にホスト名やドメイン名の概念がありません。そのため、これは TCP リスナーでは使用できません。

ホスト ヘッダーと Server Name Indication (SNI)

同じインフラストラクチャ上でマルチサイト ホスティングを有効にするための一般的な方法は 3 つあります。

  1. 複数の Web アプリケーションをそれぞれ、一意の IP アドレスでホストする。
  2. ホスト名を使用して、同じ IP アドレスで複数の Web アプリケーションをホストする。
  3. さまざまなポートを使用して、同じ IP アドレスで複数の Web アプリケーションをホストする。

現在、Application Gateway は、トラフィックをリッスンする単一のパブリック IP アドレスをサポートします。 そのため、それぞれ独自の IP アドレスを持つ複数のアプリケーションは、現在サポートされていません。

Application Gateway は、それぞれが異なるポートをリッスンしている複数のアプリケーションをサポートしていますが、このシナリオではアプリケーションが非標準ポートでトラフィックを受け入れることが必要です。

Application Gateway は、複数の Web サイトを同じパブリック IP アドレスとポートでホストするために、HTTP 1.1 ホスト ヘッダーを利用します。 アプリケーション ゲートウェイでホストされているサイトでは、Server Name Indication (SNI) TLS 拡張機能によって TLS オフロードをサポートすることもできます。 つまり、クライアント ブラウザーとバックエンド Web ファームは、HTTP/1.1 と、RFC 6066 で定義されている TLS 拡張機能をサポートする必要があります。

次のステップ

Application Gateway でマルチサイト ホスティングを構成する方法を確認します

エンド ツー エンドのテンプレートベースのデプロイについては、複数サイト ホスティングを使った Resource Manager テンプレートに関するページを参照してください。