App Service などのマルチテナント バックエンドに対する Application Gateway のサポートApplication Gateway support for multi-tenant back ends such as App service

Web サーバー内がマルチテナント アーキテクチャ設計の場合、同じ Web サーバー インスタンス上で複数の Web サイトが実行されます。In multi-tenant architectural designs in web servers, multiple websites are running on the same web server instance. ホスト名は、ホストされる各種アプリケーションを区別するために使用されます。Hostnames are used to differentiate between the different applications which are hosted. 既定では、クライアントからの受信 HTTP ホスト ヘッダーは、変更されることなくそのままバックエンドに送信されます。By default, application gateway does not change the incoming HTTP host header from the client and sends the header unaltered to the back end. これは、NIC、仮想マシン スケール セット、パブリック IP アドレス、内部 IP アドレス、FQDN などのバックエンド プール メンバーではうまく機能します。これらのメンバーは、特定のホスト ヘッダーや SNI 拡張機能に頼らなくても、正しいエンドポイントに解決されるからです。This works well for backend pool members such as NICs, virtual machine scale sets, public IP addresses, internal IP addresses and FQDN as these do not rely on a specific host header or SNI extension to resolve to the correct endpoint. しかし、Azure App Service の Web アプリや Azure API Management のように、本質的にはマルチテナントであり、特定のホスト ヘッダーや SNI 拡張機能に頼って正しいエンドポイントに解決されるサービスも多数あります。However, there are many services such as Azure App service web apps and Azure API management that are multi-tenant in nature and rely on a specific host header or SNI extension to resolve to the correct endpoint. 通常、アプリケーションの DNS 名 (アプリケーション ゲートウェイに関連付けられた DNS 名になります) は、バックエンド サービスのドメイン名とは異なります。Usually, the DNS name of the application, which in turn is the DNS name associated with the application gateway, is different from the domain name of the backend service. したがって、アプリケーション ゲートウェイで受信された元の要求内のホスト ヘッダーは、バックエンド サービスのホスト名と同じではありません。Therefore, the host header in the original request received by the application gateway is not the same as the host name of the backend service. このため、アプリケーション ゲートウェイからバックエンドへの要求内のホスト ヘッダーが、バックエンド サービスのホスト名に変更されない場合、マルチテナント バックエンドでは、要求を正しいエンドポイントに解決できません。Because of this, unless the host header in the request from the application gateway to the backend is changed to the host name of the backend service, the multi-tenant backends are not able to resolve the request to the correct endpoint.

アプリケーション ゲートウェイには、バックエンドのホスト名に基づいて、要求内の HTTP ホスト ヘッダーをオーバーライドする機能があります。Application gateway provides a capability which allows users to override the HTTP host header in the request based on the host name of the back-end. この機能により、Azure App Service の Web アプリや API Management などのマルチテナント バックエンドがサポートされます。This capability enables support for multi-tenant back ends such as Azure App service web apps and API management. この機能は、Standard SKU および WAF SKU の v1 と v2 の両方で利用できます。This capability is available for both the v1 and v2 standard and WAF SKUs.

ホストのオーバーライド

注意

これは、Azure App Service Environment (ASE) には適用されません。ASE は、マルチテナントのリソースである Azure App Service とは異なり、専用のリソースであるからです。This is not applicable to Azure App service environment (ASE) since ASE is a dedicated resource unlike Azure App service which is a multi-tenant resource.

要求内のホスト ヘッダーのオーバーライドOverride host header in the request

ホスト オーバーライドを指定する機能は、HTTP 設定内で定義されます。また、この機能はルールの作成中にバックエンド プールに適用できます。The ability to specify a host override is defined in the HTTP settings and can be applied to any back-end pool during rule creation. マルチテナント バックエンドのホスト ヘッダーと SNI 拡張機能をオーバーライドする方法として、以下の 2 つがサポートされています。The following two ways of overriding host header and SNI extension for multi-tenant back ends is supported:

  • HTTP 設定内で明示的に入力された固定値をホスト名として設定する機能。The ability to set the host name to a fixed value explicitly entered in the HTTP settings. この機能では、特定の HTTP 設定が適用されたバックエンド プールへのすべてのトラフィックについて、ホスト ヘッダーがこの値にオーバーライドされます。This capability ensures that the host header is overridden to this value for all traffic to the back-end pool where the particular HTTP settings are applied. エンド ツー エンド SSL を使用している場合、オーバーライドされたこのホスト名は SNI 拡張機能で使用されます。When using end to end SSL, this overridden host name is used in the SNI extension. この機能を使用すれば、顧客の受信ホスト ヘッダーと異なるホスト ヘッダーがバックエンド プール ファームによって想定されるシナリオに対応できます。This capability enables scenarios where a back-end pool farm expects a host header that is different from the incoming customer host header.

  • バックエンド プール メンバーの IP または FQDN からホスト名を取得する機能。The ability to derive the host name from the IP or FQDN of the back-end pool members. HTTP 設定では、個々のバックエンド プール メンバーからホスト名を取得するオプションが構成されている場合、バックエンド プール メンバーの FQDN からホスト名を動的に選択するオプションも設定できます。HTTP settings also provide an option to dynamically pick the host name from a back-end pool member's FQDN if configured with the option to derive host name from an individual back-end pool member. エンド ツー エンド SSL を使用している場合、このホスト名は FQDN から取得され、SNI 拡張機能で使用されます。When using end to end SSL, this host name is derived from the FQDN and is used in the SNI extension. この機能を使用すれば、バックエンド プールに 2 つ以上のマルチテナント PaaS サービス (Azure Web Apps など) を使用でき、各メンバーへの要求のホスト ヘッダーに FQDN から取得されたホスト名を含めるシナリオに対応できます。This capability enables scenarios where a back-end pool can have two or more multi-tenant PaaS services like Azure web apps and the request's host header to each member contains the host name derived from its FQDN. このシナリオを実装する場合は、HTTP 設定内で [バックエンド アドレスからホスト名を選択します] というスイッチを使用します。これにより、元の要求内のホスト ヘッダーが動的にオーバーライドされ、バックエンド プール内に示されているホスト ヘッダーになります。For implementing this scenario, we use a switch in the HTTP Settings called Pick hostname from backend address which will dynamically override the host header in the original request to the one mentioned in the backend pool. たとえば、要求が当該バックエンド サーバーに送信される場合、バックエンド プールの FQDN に "contoso11.azurewebsites.net" と "contoso22.azurewebsites.net" が含まれていれば、元の要求のホスト ヘッダー (contoso.com) は、contoso11.azurewebsites.net または contoso22.azurewebsites.net にオーバーライドされます。For example, if your backend pool FQDN contains “contoso11.azurewebsites.net” and “contoso22.azurewebsites.net”, the original request’s host header which is contoso.com will be overridden to contoso11.azurewebsites.net or contoso22.azurewebsites.net when the request is sent to the appropriate backend server.

    Web アプリのシナリオ

顧客はこの機能を使用して、HTTP 設定とカスタム プローブのオプションを適切な構成に指定します。With this capability, customers specify the options in the HTTP settings and custom probes to the appropriate configuration. さらに、この設定は、ルールを使用してリスナーとバックエンド プールに関連付けられます。This setting is then tied to a listener and a back-end pool by using a rule.

特別な考慮事項Special considerations

マルチテナント サービスでの SSL 終了およびエンド ツー エンド SSLSSL termination and end to end SSL with multi-tenant services

マルチテナント サービスでは、SSL 終了とエンド ツー エンド SSL 暗号化の両方がサポートされます。Both SSL termination and end to end SSL encryption is supported with multi-tenant services. アプリケーション ゲートウェイで SSL 終了を行う場合、SSL 証明書を引き続きアプリケーション ゲートウェイのリスナーに追加する必要があります。For SSL termination at the application gateway, SSL certificate continues to be required to be added to the application gateway listener. ただし、エンド ツー エンド SSL の場合、信頼されている Azure サービス (Azure App Service の Web アプリなど) では、アプリケーション ゲートウェイ内でバックエンドをホワイト リスト登録する必要はありません。However, in case of end to end SSL, trusted Azure services such as Azure App service web apps do not require whitelisting the backends in the application gateway. したがって、どの認証証明書も追加する必要はありません。Therefore, there is no need to add any authentication certificates.

エンド ツー エンド SSL

上の画像で App Service がバックエンドとして選択されている場合は、認証証明書を追加する必要はないことに注意してください。Notice that in the above image, there is no requirement to add authentication certificates when App service is selected as backend.

正常性プローブHealth probe

HTTP 設定内でホスト ヘッダーをオーバーライドすると、要求とそのルーティングにのみ影響が及びます。Overriding the host header in the HTTP settings only affects the request and its routing. 正常性プローブの動作には影響が及びません。it does not impact the health probe behavior. エンド ツー エンドの機能が動作するには、正しい構成を反映するようプローブと HTTP 設定の両方を変更する必要があります。For end to end functionality to work, both the probe and the HTTP settings must be modified to reflect the correct configuration. プローブ構成内でホスト ヘッダーを指定できるほか、カスタム プローブでは、現在構成されている HTTP 設定からホスト ヘッダーを取得する機能もサポートされています。In addition to providing the ability to specify a host header in the probe configuration, custom probes also support the ability to derive the host header from the currently configured HTTP settings. この構成は、プローブ構成の PickHostNameFromBackendHttpSettings パラメーターを使用して指定できます。This configuration can be specified by using the PickHostNameFromBackendHttpSettings parameter in the probe configuration.

App Service の URL にリダイレクトされるシナリオRedirection to App Service’s URL scenario

App Service からの応答内のホスト名によって、エンドユーザーのブラウザーが、Application Gateway に関連付けられているドメインではなく、*.azurewebsites.net ホスト名にリダイレクトされる場合があります。There can be scenarios where the hostname in the response from the App service may direct the end-user browser to the *.azurewebsites.net hostname instead of the domain associated with the Application Gateway. この問題が発生するのは、以下の場合です。This issue may happen when:

  • App Service 上でリダイレクトが構成されている。You have redirection configured on your App Service. 要求の末尾にスラッシュを追加するだけでリダイレクトが実行される場合があります。Redirection can be as simple as adding a trailing slash to the request.
  • Azure AD 認証が構成されており、これが原因でリダイレクトが実行される。You have Azure AD authentication which causes the redirection.

このような問題を解決するには、App Service の URL にリダイレクトされる問題のトラブルシューティングに関するページを参照してください。To resolve such cases, see Troubleshoot redirection to App service’s URL issue.

次の手順Next steps

マルチテナント アプリケーション (Azure App Service の Web アプリなど) と共にアプリケーション ゲートウェイをバックエンド プール メンバーとして設定する方法については、Application Gateway を使用する App Service の Web アプリ の構成に関するページを参照してください。Learn how to set up an application gateway with a multi-tenant app such as Azure App service web app as a back-end pool member by visiting Configure App Service web apps with Application Gateway