バックエンド設定を使用すると、アプリケーション ゲートウェイ リソースからバックエンド プール内のサーバーに確立されたバックエンド接続の構成を管理できます。 バックエンド設定の構成は、1 つ以上のルーティング規則に関連付けることができます。
Application Gateway のバックエンド設定の種類
ポータル ユーザーには [バックエンド設定] オプションのみが表示されますが、API ユーザーは 2 種類の設定にアクセスできます。 プロトコルに従って、正しい構成を利用する必要があります。
- バックエンド HTTP 設定 - HTTP プロトコルと HTTPS プロトコルをサポートするレイヤー 7 プロキシ構成用です。
- バックエンド設定 - TLS および TCP プロトコルをサポートするレイヤー 4 プロキシ (プレビュー) 構成用です。
Cookie ベースのアフィニティ
Azure Application Gateway では、ユーザー セッションを維持するために、ゲートウェイで管理される Cookie を使用します。 ユーザーは、最初の要求を Application Gateway に送信すると、セッションの詳細を含むハッシュ値を持つアフィニティ Cookie を応答に設定します。 このプロセスにより、アフィニティ Cookie を保持する後続の要求を同じバックエンド サーバーにルーティングできるため、持続性が維持されます。
この機能は、ユーザー セッションを同じサーバー上に維持する必要があり、ユーザー セッションのセッション状態がサーバー上にローカル保存される場合に便利です。 アプリケーションが Cookie ベースのアフィニティを処理できない場合は、この機能を使用できません。 使用するには、クライアントが Cookie をサポートしている必要があります。
注
一部の脆弱性スキャンでは、Application Gateway アフィニティ Cookie にフラグが設定されることがあります。Secure フラグまたは HttpOnly フラグが設定されないためです。 これらのスキャンでは、Cookie 内のデータが一方向ハッシュを使用して生成されることを考慮しません。 Cookie にはユーザー情報が含まれず、ルーティング目的でのみ使用されます。
Chromium ブラウザーv80 の更新では、SameSite 属性のない HTTP Cookie を SameSite=Lax として扱うことが必須になりました。 CORS (クロス オリジン リソース共有) 要求の際に Cookie をサードパーティのコンテキストで送信する必要がある場合は、SameSite=None; Secure 属性を使用する必要があり、HTTPS 経由でのみ送信する必要があります。 それ以外の場合、HTTP のみのシナリオでは、ブラウザーはサードパーティのコンテキストで Cookie を送信しません。 Chrome のこの更新の目的は、セキュリティを強化し、クロスサイト リクエスト フォージェリ (CSRF) 攻撃を回避することです。
この変更をサポートするために、2020 年 2 月 17 日以降、Application Gateway (すべての SKU タイプ) は、既存の ApplicationGatewayAffinity Cookie に加えて、ApplicationGatewayAffinityCORS と呼ばれる別の Cookie を挿入します。 ApplicationGatewayAffinityCORS Cookie には、クロス オリジン要求に対してもスティッキー セッションが維持されるように、2 つの属性が追加されています ("SameSite = None; Secure")。
既定のアフィニティ Cookie 名は ApplicationGatewayAffinity であり、変更できます。 ネットワーク トポロジに複数のアプリケーション ゲートウェイをインラインでデプロイする場合は、リソースごとに一意の Cookie 名を設定する必要があります。 カスタムのアフィニティ Cookie 名を使用する場合、サフィックスとして CORS を付加した別の Cookie も追加されます。 たとえば、CustomCookieNameCORS です。
注
SameSite=None 属性が設定されている場合は、Cookie に Secure フラグも含まれていることが必須であり、HTTPS 経由で送信する必要があります。 CORS 経由のセッション アフィニティが必要な場合は、ワークロードを HTTPS に移行する必要があります。 Application Gateway の TLS オフロードとエンド ツー エンド TLS のドキュメントを参照してください。 SSL の 概要、 TLS 終端を使用したアプリケーション ゲートウェイの構成、 エンド ツー エンド TLS の構成を参照してください。
接続のドレイン
接続ドレインを使用すると、計画されたサービスの更新中にバックエンド プール メンバーを正常に削除できます。 これは、バックエンド プールから明示的に削除されたバックエンド インスタンスに適用されます。
バックエンドの設定で接続ドレインを有効にすると、この設定をすべてのバックエンド プール メンバーに適用できます。 これで、バックエンド プール内の登録を解除するすべてのインスタンスが、構成されたタイムアウト値まで既存の接続を維持しながら、新しい要求や接続を受信しなくなります。 このプロセスは、WebSocket 接続にも当てはまります。
| [構成の種類] | 値 |
|---|---|
| バックエンド設定で接続ドレインが有効になっていない場合の既定値 | 30 秒 |
| [バックエンド設定] で [接続ドレイン] が有効になっている場合のユーザー定義値 | 1 秒から 3,600 秒 |
このプロセスの唯一の例外は、ゲートウェイで管理されるセッションアフィニティのために、インスタンス登録解除を目的とした要求です。 これらの要求は、登録解除中のインスタンスに引き続き転送されます。
注
接続ドレインのタイムアウト後に構成を更新すると、進行中の接続が終了するという制限があります。 この制限に対処するには、バックエンド設定の接続ドレイン タイムアウトを、予想されるクライアントのダウンロード時間の最大値より大きい値に増やす必要があります。
プロトコル
Application Gateway は、要求をバックエンド サーバーにルーティングする際に HTTP と HTTPS の両方をサポートします。 HTTP を選択した場合、バックエンド サーバーへのトラフィックは暗号化されません。 暗号化されていない通信を許容できない場合は、HTTPS を選択してください。
リスナーで HTTPS と組み合わせたこの設定は、エンド ツー エンド TLS をサポートします。 これによって、機密データを暗号化して安全にバックエンドに送信することができます。 エンド ツー エンド TLS が有効になったバックエンド プール内の各バックエンド サーバーは、セキュリティで保護された通信が可能になるように証明書で構成する必要があります。
港 / ポート
この設定では、バックエンド サーバーがアプリケーション ゲートウェイからのトラフィックをリッスンするポートを指定します。 1 から 65535 までの範囲のポートを構成できます。
信頼されたルート証明書
バックエンド設定で HTTPS プロトコルを選択すると、アプリケーション ゲートウェイ リソースは既定の信頼されたルート CA 証明書ストアを使用して、バックエンド サーバーによって提供される証明書のチェーンと信頼性を確認します。
既定では、Application Gateway リソースには一般的な CA 証明書が含まれています。これにより、バックエンド サーバー証明書がパブリック CA によって発行されたときに、シームレスなバックエンド TLS 接続が可能になります。 ただし、プライベート CA または自己生成証明書を使用する場合は、このバックエンド設定構成で対応するルート CA 証明書 (.cer) を指定する必要があります。
要求タイムアウト
この設定は、アプリケーション ゲートウェイがバックエンド サーバーからの応答の受信を待機する秒数です。 既定値は 20 秒です。 ただし、アプリケーションのニーズに合わせてこの設定を調整することもできます。
バックエンド パスのオーバーライド
この設定を使用すると、要求がバックエンドに転送されるときに使用できる、オプションのカスタム転送パスを構成できます。 [バックエンド パスのオーバーライド] フィールドに指定したカスタム パスと一致する受信パスの部分が、転送先パスにコピーされます。 次の表は、この機能のしくみを示しています。
HTTP 設定が基本の要求ルーティング規則に関連付けられている場合:
元の要求 バックエンド パスのオーバーライド バックエンドに転送される要求 /ホーム/ /オーバーライド/ /override/home/ /home/secondhome/ /オーバーライド/ /override/home/secondhome/ HTTP 設定がパスベースの要求ルーティング規則に関連付けられている場合:
元の要求 パスの規則 バックエンド パスのオーバーライド バックエンドに転送される要求 /pathrule/home/ /pathrule* /オーバーライド/ /override/home/ /pathrule/home/secondhome/ /pathrule* /オーバーライド/ /override/home/secondhome/ /ホーム/ /pathrule* /オーバーライド/ /override/home/ /home/secondhome/ /pathrule* /オーバーライド/ /override/home/secondhome/ /pathrule/home/ /pathrule/home* /オーバーライド/ /オーバーライド/ /pathrule/home/secondhome/ /pathrule/home* /オーバーライド/ /override/secondhome/ /pathrule/ /pathrule/ /オーバーライド/ /オーバーライド/
[カスタム プローブの使用]
この設定で、カスタム プローブが HTTP 設定と関連付けられます。 カスタム プローブを 1 つだけ HTTP 設定と関連付けることができます。 カスタム プローブを明示的に関連付けないと、バックエンドの正常性を監視するために既定のプローブが使用されます。 バック エンドの正常性監視をきめ細かく制御するには、カスタム プローブを作成することをお勧めします。
注
対応する HTTP 設定が明示的にリスナーに関連付けられていない限り、カスタム プローブはバックエンド プールの正常性を監視しません。
ホスト名の構成
Application Gateway を使うと、バックエンドとの確立した接続に、クライアントが Application Gateway への接続に使ったホスト名とは異なるホスト名を使用できます。 この構成は場合によっては便利ですが、アプリケーション ゲートウェイとクライアントの間でバックエンド ターゲットと比較して異なるホスト名をオーバーライドする場合は注意が必要です。
運用環境では、クライアントからアプリケーション ゲートウェイへの接続と、バックエンド ターゲット接続へのアプリケーション ゲートウェイに対して同じホスト名を使用することをお勧めします。 この方法では、絶対 URL、リダイレクト URL、およびホスト バインド Cookie に関する潜在的な問題を回避します。
これを逸脱した Application Gateway を設定する前に、「アーキテクチャ センター: リバース プロキシとそのバックエンド Web アプリケーションの間で元の HTTP ホスト名を保持する」で詳しく説明されているように、このような構成の影響を確認してください
HTTP 設定には、Application Gateway がバックエンドへの接続に使う Host HTTP ヘッダーに影響する 2 つの側面があります。
- [バックエンド アドレスからホスト名を選択します]
- [ホスト名の上書き]
[バックエンド アドレスからホスト名を選択します]
この機能によって、要求の host ヘッダーが、バックエンド プールのホスト名に動的に設定されます。 これには IP アドレスまたは FQDN が使用されます。
この機能が役立つのは、バックエンドのドメイン名がアプリケーション ゲートウェイの DNS 名と異なっており、バックエンドが特定のホスト ヘッダーを利用して正しいエンドポイントに解決される場合です。
例として、バックエンドとしてのマルチテナント サービスがあります。 アプリ サービスは、1 つの IP アドレスを持つ共有スペースを使用するマルチテナント サービスです。 そのため、アプリ サービスにアクセスするには、カスタム ドメイン設定で構成されているホスト名を使用する必要があります。
既定ではカスタム ドメイン名は example.azurewebsites.net です。 アプリケーション ゲートウェイを使用して、App Service に明示的に登録されていないホスト名またはアプリケーション ゲートウェイの FQDN によって App Service にアクセスするには、元の要求のホスト名をオーバーライドして、アプリ サービスのホスト名にすることができます。 これを行うために、[バックエンド アドレスからホスト名を選択します] 設定を有効にします。
既存のカスタム DNS 名がアプリ サービスにマップされているカスタム ドメインの場合、推奨される構成では 、バックエンド アドレスからホスト名を選択することはできません。
注
この設定は、専用のデプロイである App Service Environment では必要ありません。
[ホスト名の上書き]
この機能によって、アプリケーション ゲートウェイの着信要求の host ヘッダーが、指定するホスト名に置き換えられます。
たとえば、www.contoso.comの設定でが指定されている場合、要求がバックエンド サーバーに転送されるときに、元の要求 *https://appgw.eastus.cloudapp.azure.com/path1が *https://www.contoso.com/path1 に変更されます。