Azure Application Gateway を計画して実装する
Azure Application Gateway は、Web アプリケーションに対するトラフィックを管理できる Web トラフィック (OSI レイヤー 7) ロード バランサーです。 従来のロード バランサーはトランスポート レイヤー (OSI レイヤー 4 - TCP と UDP) で動作し、送信元 IP アドレスとポートに基づくトラフィックを送信先 IP アドレスとポートにルーティングします。
Application Gateway では、URI パスやホスト ヘッダーなど、HTTP 要求の追加属性に基づいてルーティングを決定できます。 たとえば、着信 URL に基づいてトラフィックをルーティングできます。 そのため、着信 URL に /images がある場合、画像用に構成された特定のサーバー セット (プールと呼ばれます) にトラフィックをルーティングできます。 /video が URL にある場合、そのトラフィックはビデオ用に最適化された別のプールにルーティングされます。
この種類のルーティングは、アプリケーション レイヤー (OSI レイヤー 7) の負荷分散と呼ばれます。 Azure Application Gateway は URL ベースのルーティングなどを行うことができます。
アプリケーション ゲートウェイのコンポーネント
アプリケーション ゲートウェイは、クライアントからの単一接続点として機能します。 アプリケーション ゲートウェイは、着信するアプリケーション トラフィックを、Azure VM、仮想マシン スケール セット、Azure App Service、オンプレミス/外部サーバーなど、複数のバックエンド プールに配布します。
インフラストラクチャ
Application Gateway のインフラストラクチャには、仮想ネットワーク、サブネット、ネットワーク セキュリティ グループ、ユーザー定義ルートが含まれます。
フロントエンド IP アドレス
Application Gateway は、パブリック IP アドレス、プライベート IP アドレス、またはその両方を持つように構成できます。 パブリック IP が必要となるのは、インターネットに接続している仮想 IP (VIP) を介してインターネット上でクライアントがアクセスする必要があるバックエンドをホストするときです。
インターネットに公開されない内部エンドポイントの場合は、パブリック IP アドレスは必要ありません。 プライベート フロントエンド構成は、インターネットに接続されていない内部の基幹業務アプリケーションに便利です。 また、インターネットに接続されていないけれども、ラウンド ロビンの負荷分散、セッションの持続性、または TLS ターミネーションが必要な、セキュリティ境界内の多階層アプリケーションのサービスや階層にも役立ちます。
1 つのパブリック IP アドレスと 1 つのプライベート IP アドレスだけがサポートされています。 アプリケーション ゲートウェイを作成するときにフロントエンド IP を選択します。
Note
Application Gateway のフロントエンドでは、デュアルスタックの IP アドレスがサポートされています (パブリック プレビュー)。 最大で 4 個のフロントエンド IP を作成できます。 2 つの IPv4 アドレス (パブリックとプライベート) と、2 つの IPv6 アドレス (パブリックとプライベート) です。
- パブリック IP アドレスの場合は、新しいパブリック IP アドレスの作成またはアプリケーション ゲートウェイと同じ場所にある既存のパブリック IP を使用できます。 詳しくは、「静的パブリック IP アドレスと動的パブリック IP アドレス」をご覧ください。
- プライベート IP アドレスの場合は、アプリケーション ゲートウェイが作成されるサブネットのプライベート IP アドレスを指定できます。 Application Gateway v2 SKU のデプロイでは、プライベート IP アドレスをゲートウェイに追加するときに、静的 IP アドレスを定義する必要があります。 Application Gateway v1 SKU のデプロイでは、IP アドレスを指定しないと、サブネットから使用できる IP アドレスが自動的に選ばれます。 選択した IP アドレスの種類 (静的または動的) は後で変更できません。
フロントエンド IP アドレスが関連付けられた "リスナー" が、フロントエンド IP での着信要求をチェックします。
プライベートとパブリックのリスナーを、同じポート番号で作成できます。 ただし、Application Gateway サブネットに関連付けられているネットワーク セキュリティ グループ (NSG) に注意してください。 NSG の構成によっては、アプリケーション ゲートウェイのパブリックとプライベートのフロントエンド IP として宛先 IP アドレスを使用するインバウンド許可規則が必要になる場合があります。 同じポートを使用すると、アプリケーション ゲートウェイによって、インバウンド フローの宛先がゲートウェイのフロントエンド IP に変更されます。
インバウンド規則:
- ソース: 要件に応じて
- 宛先: アプリケーション ゲートウェイのパブリックとプライベートのフロントエンド IP。
- 宛先ポート: 構成されているリスナーに応じて
- プロトコル: TCP
アウトバウンド規則:特定の要件なし
リスナー
リスナーは、ポート、プロトコル、ホストおよび IP アドレスを使用して着信接続要求をチェックする論理エンティティです。 リスナーを構成するときは、ゲートウェイの着信要求の対応する値と同じ値をここに入力する必要があります。
Azure portal を使用してアプリケーション ゲートウェイを作成するときにも、リスナーのプロトコルとポートを選択して既定のリスナーを作成します。 リスナー上で HTTP2 のサポートを有効にするかどうかを選択できます。 アプリケーション ゲートウェイを作成した後、この既定リスナー (appGatewayHttpListener) の設定を編集することや、新しいリスナーを作成することができます。
リスナーの種類
リスナーは、入ってくる接続要求をチェックする論理エンティティです。 リスナーは、要求に関連付けられているプロトコル、ポート、ホスト名、IP アドレスがリスナー構成に関連付けられている同じ要素に一致した場合、要求を受け取ります。
アプリケーション ゲートウェイを使用する前に、リスナーを少なくとも 1 つ追加する必要があります。 1 つのアプリケーション ゲートウェイには複数のリスナーをアタッチできます。その複数のリスナーは同じプロトコルに使用できます。
クライアントから送信された要求がリスナーに検出されると、アプリケーション ゲートウェイでは、規則に構成されているバックエンド プールのメンバーにその要求が転送されます。
リスナーでは、次のポートとプロトコルがサポートされます。
Port
ポートとは、リスナーがクライアント要求を待つ場所です。 v1 および v2 SKU のポートは以下のように構成できます。
| SKU | サポートされているポート範囲 | 例外 |
|---|---|---|
| V2 | 1 から 64999 | 22 |
| V1 | 1 から 65502 | 3389 |
プロトコル
Application Gateway では、HTTP、HTTPS、HTTP/2、WebSocket の 4 つのプロトコルがサポートされます。
Note
HTTP/2 プロトコルのサポートを利用できるのは、アプリケーション ゲートウェイ リスナーに接続しているクライアントだけです。 バックエンド サーバー プールへの通信は、常に HTTP/1.1 で行われます。 既定では、HTTP/2 のサポートは無効になっています。 必要であれば、有効にすることもできます。
- リスナー構成で HTTP プロトコルか HTTPS プロトコルを指定します。
- WebSockets プロトコルと HTTP/2 プロトコルのサポートはネイティブで提供されます。WebSocket サポートは既定で有効になっています。 ユーザーが構成可能な、WebSocket のサポートを選択的に有効または無効にするための設定はありません。 WebSocket は HTTP リスナーと HTTPS リスナーの両方で使用します。
HTTPS リスナーは TLS 終端に使用します。 HTTPS リスナーは暗号化と解読の作業負荷をアプリケーション ゲートウェイにまかせるため、Web サーバーはオーバーヘッドの負担から解放されます。
要求ルーティング規則
Azure portal を使用してアプリケーション ゲートウェイを作成するときに、既定の規則 (rule1) を作成します。 この規則によって、既定のリスナー (appGatewayHttpListener) が既定のバックエンド プール (appGatewayBackendPool) と既定のバックエンド HTTP 設定 (appGatewayBackendHttpSettings) にバインドされます。 ゲートウェイを作成した後で、既定の規則の設定の編集や新しい規則の作成を行うことができます。
規則の種類
新しい規則を作成するときは、"基本" または "パス ベース" を選択します。
- 関連付けられたリスナー (例: blog.contoso.com/*) に対するすべての要求を 1 つのバックエンド プールに転送する場合は、基本を選択します。
- 特定の URL パスからの要求を特定のバックエンド プールにルーティングする場合は、パス ベースを選択します。 パスのパターンは URL のパスのみに適用され、クエリ パラメーターには適用されません。
関連付けられたリスナー
リスナーに関連付けられた "要求のルーティング規則" が評価されて、要求のルーティング先のバックエンド プールを決定できるように、リスナーを規則に関連付けます。
関連付けられたバックエンド プール
リスナーが受信する要求を処理するバックエンド ターゲットを含むバックエンド プールを規則に関連付けます。
- 基本規則の場合、1 つのバックエンド プールのみが許可されます。 関連付けられているリスナー上のすべての要求は、そのバックエンド プールに転送されます。
- パスベースの規則の場合は、各 URL パスに対応する複数のバックエンド プールを追加します。 入力した URL パスと一致する要求が、対応するバックエンド プールに転送されます。 また、既定のバックエンド プールを追加します。 規則内のどの URL パスとも一致しない要求は、そのプールに転送されます。
関連付けられたバックエンド HTTP 設定
各規則のバックエンド HTTP 設定を追加します。 要求は、この設定に指定されるポート番号、プロトコル、および他の情報を使用して、アプリケーション ゲートウェイからバックエンド ターゲットにルーティングされます。
基本規則の場合、1 つのバックエンド HTTP 設定のみが許可されます。 関連付けられているリスナー上のすべての要求は、この HTTP 設定を使用して、対応するバックエンド ターゲットに転送されます。
パスベースの規則の場合は、各 URL パスに対応する複数のバックエンド HTTP 設定を追加します。 この設定の URL パスと一致する要求は、各 URL パスに対応する HTTP 設定を使用して、対応するバックエンド ターゲットに転送されます。 また、既定の HTTP 設定を追加します。 この規則のどの URL パスとも一致しない要求は、既定の HTTP 設定を使用して既定のバックエンド プールに転送されます。
リダイレクト設定
基本規則でリダイレクトが構成されている場合、関連付けられているリスナーのすべての要求はターゲットにリダイレクトされます。 これは "グローバル" なリダイレクトです。 パスベースの規則に対してリダイレクトが構成されている場合は、特定のサイト領域内の要求のみがリダイレクトされます。 たとえば、/cart/* で示されるショッピング カート領域です。 これがパスベースのリダイレクトです。
リスナー
ゲートウェイ上のあるリスナーから別のリスナーにトラフィックをリダイレクトするには、リダイレクト ターゲットとしてリスナーを選択します。 この設定は、HTTP から HTTPS へのリダイレクトを有効にする場合に必要です。 着信 HTTP 要求を確認するソース リスナーから、着信 HTTPS 要求を確認する宛先リスナーにトラフィックがリダイレクトされます。 元の要求のクエリ文字列とパスを、リダイレクト ターゲットに転送される要求に含めることもできます。
外部サイト
この規則に関連付けられたリスナーに対するトラフィックを外部サイトにリダイレクトするときに、外部サイトを選択します。 元の要求のクエリ文字列を、リダイレクト ターゲットに転送される要求に含めることができます。 元の要求内のパスを外部サイトに転送することはできません。
HTTP ヘッダーと URL を書き換える
書き換え規則を使用すると、要求および応答パケットがアプリケーション ゲートウェイを通じてクライアントとバックエンド プールの間を移動する際に、HTTP(S) 要求と応答ヘッダーや URL パスとクエリ文字列パラメーターを追加、削除、または更新できます。
ヘッダーおよび URL パラメーターは、静的な値に設定するか、その他のヘッダーやサーバー変数に設定できます。 クライアント IP アドレスを抽出する、バックエンドに関する機密情報を削除する、セキュリティを追加するなど、重要なユース ケースで役立ちます。
HTTP 設定
アプリケーション ゲートウェイは、ここで指定した構成を使用してトラフィックをバックエンド サーバーにルーティングします。 HTTP 設定を作成したら、それを 1 つ以上の要求ルーティング規則に関連付ける必要があります。
Cookie ベースのアフィニティ
Azure Application Gateway では、ユーザー セッションを維持するために、ゲートウェイで管理される Cookie を使用します。 ユーザーが最初の要求を Application Gateway に送信すると、セッションの詳細を含むハッシュ値を使用して、応答にアフィニティ Cookie が設定されます。これにより、このアフィニティ Cookie を伝送する後続の要求は、持続性を維持するために同じバックエンド サーバーにルーティングされるようになります。
この機能は、ユーザー セッションを同じサーバー上に維持する必要があり、ユーザー セッションのセッション状態がサーバー上にローカル保存される場合に便利です。 アプリケーションが Cookie ベースのアフィニティを処理できない場合は、この機能を使用できません。 使用するには、クライアントが Cookie をサポートしている必要があります。
Note
一部の脆弱性スキャンでは、Application Gateway アフィニティ Cookie にフラグが設定されることがあります。Secure フラグまたは HttpOnly フラグが設定されないためです。 これらのスキャンでは、Cookie のデータが一方向のハッシュで生成されることが考慮されません。 Cookie にはユーザー情報が含まれず、ルーティング目的でのみ使用されます。
接続のドレイン
接続ドレインを使用すると、計画されたサービスの更新中にバックエンド プール メンバーを正常に削除できます。 これは、
- バックエンド プールから明示的に削除された、
- スケールイン操作中に削除された、または
- 正常性プローブによって異常として報告されたバックエンド インスタンスに適用されます。
バックエンドの設定で接続ドレインを有効にすると、この設定をすべてのバックエンド プール メンバーに適用できます。 これで、バックエンド プール内の登録を解除するすべてのインスタンスが、構成されたタイムアウト値まで既存の接続を維持しながら、新しい要求や接続を受信しなくなります。 これは WebSocket 接続にも当てはまります。
| [構成の種類] | Value |
|---|---|
| [バックエンド設定] で [接続ドレイン] が有効になっていない場合の既定値 | 30 秒 |
| [バックエンド設定] で [接続ドレイン] が有効になっている場合のユーザー定義値 | 1 秒から 3,600 秒 |
これに対する唯一の例外は、ゲートウェイによって管理されるセッション アフィニティのために登録を解除するインスタンス宛ての要求です。これらは、登録を解除するインスタンスによって引き続き転送されます。
プロトコル
Application Gateway は、要求をバックエンド サーバーにルーティングする際に HTTP と HTTPS の両方をサポートします。 HTTP を選択した場合、バックエンド サーバーへのトラフィックは暗号化されません。 暗号化されていない通信を許容できない場合は、HTTPS を選択してください。
リスナーで HTTPS と組み合わせたこの設定は、エンド ツー エンド TLS をサポートします。 これによって、機密データを暗号化して安全にバックエンドに送信することができます。 エンド ツー エンド TLS が有効になったバックエンド プール内の各バックエンド サーバーは、セキュリティで保護された通信が可能になるように証明書で構成する必要があります。
Port
この設定では、バックエンド サーバーがアプリケーション ゲートウェイからのトラフィックをリッスンするポートを指定します。 1 から 65535 までの範囲のポートを構成できます。
信頼されたルート証明書
バックエンド プロトコルとして HTTPS を選択した場合、Application Gateway には、エンド ツー エンド SSL のバックエンド プールを信頼するために信頼されたルート証明書が必要です。 既定では、[ 既知の CA 証明書を使用する] オプションは [いいえ] に設定されています。 自己署名証明書または内部の証明機関によって署名された証明書を使用する場合は、バックエンド プールが使用する一致する公開証明書を Application Gateway に指定する必要があります。 この証明書は、 .CER formatのApplication Gatewayに直接アップロードする必要があります。
信頼された公的な証明機関によって署名されたバックエンド プールで証明書を使用する場合は、[既知の CA 証明書を使用する] オプションを [はい ] に設定することで、公開証明書のアップロードをスキップできます。
要求タイムアウト
この設定は、アプリケーション ゲートウェイがバックエンド サーバーからの応答の受信を待機する秒数です。
バックエンド パスのオーバーライド
この設定を使用すると、要求がバックエンドに転送されるときに使用できる、オプションのカスタム転送パスを構成できます。 [バックエンド パスのオーバーライド] フィールドに指定したカスタム パスと一致する受信パスの部分が、転送先パスにコピーされます。 次の表は、この機能のしくみを示しています。
HTTP 設定が基本の要求ルーティング規則に関連付けられている場合:
| 元の要求 | バックエンド パスのオーバーライド | バックエンドに転送される要求 |
|---|---|---|
| /home/ | /override/ | /override/home/ |
| /home/secondhome/ | /override/ | /override/home/secondhome/ |
HTTP 設定がパスベースの要求ルーティング規則に関連付けられている場合:
| 元の要求 | パスの規則 | バックエンド パスのオーバーライド | バックエンドに転送される要求 |
|---|---|---|---|
| /pathrule/home/ | /pathrule* | /override/ | /override/home/ |
| /pathrule/home/secondhome/ | /pathrule* | /override/ | /override/home/secondhome/ |
| /home/ | /pathrule* | /override/ | /override/home/ |
| /home/secondhome/ | /pathrule* | /override/ | /override/home/secondhome/ |
| /pathrule/home/ | /pathrule/home* | /override/ | /override/ |
| /pathrule/home/secondhome/ | /pathrule/home* | /override/ | /override/secondhome/ |
| /pathrule/ | /pathrule/ | /override/ | /override/ |
[カスタム プローブの使用]
この設定で、カスタム プローブが HTTP 設定と関連付けられます。 カスタム プローブを 1 つだけ HTTP 設定と関連付けることができます。 カスタム プローブを明示的に関連付けないと、バックエンドの正常性を監視するために既定のプローブが使用されます。 バック エンドの正常性監視をきめ細かく制御するには、カスタム プローブを作成することをお勧めします。
Note
対応する HTTP 設定が明示的にリスナーに関連付けられていない限り、カスタム プローブはバックエンド プールの正常性を監視しません。
ホスト名の構成
Application Gateway を使うと、バックエンドとの確立した接続に、クライアントが Application Gateway への接続に使ったホスト名とは異なるホスト名を使用できます。 この構成は便利な場合もありますが、クライアントとアプリケーション ゲートウェイ間、アプリケーション ゲートウェイからバックエンド ターゲット間で異なるホスト名をオーバーライドする場合は、注意が必要です。
運用環境では、クライアントがアプリケーション ゲートウェイに対して使うホスト名を、アプリケーション ゲートウェイがバックエンド ターゲットに対して使うホスト名と同じにしておくことをお勧めします。 これにより、絶対 URL、リダイレクト URL、ホストにバインドされた Cookie に関する潜在的な問題を回避できます。
ここから逸脱する Application Gateway を設定する前に、アーキテクチャ センターで詳しく説明されているように、そのような構成の影響を確認してください。"リバース プロキシとそのバックエンド Web アプリケーションの間で元の HTTP ホスト名を保持します。"
HTTP 設定には、Application Gateway がバックエンドに接続するために使うホスト HTTP ヘッダーに影響を与える 2 つの側面があります。
- バックエンド アドレスからホスト名を選択します
- [ホスト名の上書き]
[バックエンド アドレスからホスト名を選択します]
この機能によって、要求の host ヘッダーが、バックエンド プールのホスト名に動的に設定されます。 これには IP アドレスまたは FQDN が使用されます。
この機能が役立つのは、バックエンドのドメイン名がアプリケーション ゲートウェイの DNS 名と異なっており、バックエンドが特定のホスト ヘッダーを利用して正しいエンドポイントに解決される場合です。
例となるケースは、バックエンドとしてのマルチテナント サービスです。 アプリ サービスは、単一の IP アドレスを持つ共有領域を使用するマルチテナント サービスです。 そのため、アプリ サービスにアクセスするには、カスタム ドメイン設定で構成されているホスト名を使用する必要があります。
既定ではカスタム ドメイン名は example.azurewebsites.net です。 アプリケーション ゲートウェイを使用して、App Service に明示的に登録されていないホスト名またはアプリケーション ゲートウェイの FQDN によって App Service にアクセスするには、元の要求のホスト名をオーバーライドして、アプリ サービスのホスト名にすることができます。 これを行うために、[バックエンド アドレスからホスト名を選択します] 設定を有効にします。
既存のカスタム DNS 名がアプリ サービスにマップされているカスタム ドメインの場合、[バックエンド アドレスからホスト名を選択します] を有効にしない構成をお勧めします。
[ホスト名の上書き]
この機能によって、アプリケーション ゲートウェイの着信要求の host ヘッダーが、指定するホスト名に置き換えられます。
たとえば、www.contoso.com が [ホスト名] 設定に指定されている場合、元の要求 *https://appgw.eastus.cloudapp.azure.com/path1 は、バックエンド サーバーに転送されるときに、*https://www.contoso.com/path1 に変更されます。
バックエンド プール
バックエンド プールには、4 種類のバックエンド メンバー (特定の仮想マシン、仮想マシン スケール セット、IP アドレス/FQDN、または App Service) を指定できます。
バックエンド プールを作成した後で、それを 1 つ以上の要求ルーティング規則に関連付ける必要があります。 アプリケーション ゲートウェイ上の各バックエンド プールに対して正常性プローブを構成する必要もあります。 要求のルーティング規則の条件が満たされると、アプリケーション ゲートウェイは、トラフィックを対応するバックエンド プール内の正常なサーバー (正常性プローブによって判別) に転送します。
正常性プローブ
Azure Application Gateway は、バックエンド プール内のすべてのサーバーの正常性を監視し、異常と見なされるすべてのサーバーへのトラフィックの送信を自動的に停止します。 プローブはこのような異常なサーバーを開始し続け、プローブが正常であると検出するとすぐに、ゲートウェイによってトラフィックのルーティングが再び開始されます。
既定のプローブでは、関連付けられているバックエンド設定とその他のプリセット構成のポート番号が使用されます。 カスタム プローブを使用して、独自の方法で構成できます。
プローブの動作
ソース IP アドレス
プローブの発信元 IP アドレスは、バックエンド サーバーの種類によって異なります。
- バックエンド プール内のサーバーがパブリック エンドポイントの場合、ソース アドレスはアプリケーション ゲートウェイのフロントエンド パブリック IP アドレスになります。
- バックエンド プール内のサーバーがプライベート エンドポイントの場合、発信元 IP アドレスはアプリケーション ゲートウェイ サブネットのアドレス空間から取得されます。
プローブ操作
ゲートウェイは、ルールをバックエンド設定とバックエンド プール (およびリスナー) に関連付けることで、規則を構成した直後にプローブの起動を開始します。 この図は、ゲートウェイがすべてのバックエンド プール サーバーを個別にプローブすることを示しています。 到着を開始する受信要求は、正常なサーバーにのみ送信されます。 プローブ応答が正常に受信されるまで、バックエンド サーバーは既定で異常としてマークされます。
必要なプローブは、バックエンド サーバーとバックエンド設定の一意の組み合わせに基づいて決定されます。 たとえば、2 つのサーバーと 2 つのバックエンド設定がある 1 つのバックエンド プールを持つゲートウェイについて考えてみます。それぞれのポート番号が異なります。 これらの個別のバックエンド設定がそれぞれのルールを使用して同じバックエンド プールに関連付けられている場合、ゲートウェイにより各サーバーのプローブとバックエンド設定の組み合わせが作成されます。 これは、[バックエンドの正常性] ページで確認できます。
さらに、アプリケーション ゲートウェイのすべてのインスタンスは、互いに独立してバックエンド サーバーをプローブします。
Note
バックエンド正常性レポートは、それぞれのプローブの更新間隔に基づいて更新され、ユーザーの要求に依存しません。
既定の正常性プローブ
カスタム プローブ構成を設定しない場合、アプリケーション ゲートウェイにより既定の正常性プローブが自動で構成されます。 監視は、バックエンド プール内の構成済みの IP アドレスまたは FQDN に対して HTTP GET 要求を行うことで実行されます。 既定のプローブでは、バックエンドの http 設定が HTTPS に対応するように構成されている場合、プローブはバックエンド サーバーの正常性をテストする際に HTTPS を使用します。
たとえば、バックエンド サーバー A、B、C を使用して ポート 80 で HTTP ネットワーク トラフィックを受信するように、アプリケーション ゲートウェイを構成したとします。 既定の正常性監視では、30 秒ごとにこれら 3 つのサーバーに対して HTTP 応答が正常であるかどうかがテストされます。その際、各要求に対して 30 秒のタイムアウトが適用されます。 正常な HTTP 応答の 状態コード は、200 から 399 の間です。 この場合、正常性プローブの HTTP GET 要求は http://127.0.0.1/ のようになります。 「Application Gateway の HTTP 応答コード」も参照してください。
サーバー A に対する既定のプローブ チェックが失敗した場合、Application Gateway はこのサーバーへの要求の転送を停止します。 既定のプローブは、削除後もサーバー A を 30 秒ごとにチェックし続けます。 サーバー A が既定の正常性プローブからの 1 つの要求に正常に応答すると、Application Gateway はサーバーへの要求の転送を再び開始します。
既定の正常性プローブの設定
| プローブのプロパティ | Value | 説明 |
|---|---|---|
| プローブの URL | <protocol>://127.0.0.1:<port>/ | プロトコルとポートは、プローブが関連付けられているバックエンド HTTP 設定から継承されます。 |
| Interval | 30 | 次の正常性プローブが送信されるまでの秒数です。 |
| タイムアウト | 30 | アプリケーション ゲートウェイがプローブの応答を待機する秒数です。これを超えると、プローブは異常としてマークされます。 プローブが正常として返された場合は、対応するバックエンドがすぐに正常としてマークされます。 |
| 異常のしきい値 | 3 | 通常の正常性プローブで障害が発生した場合に送信するプローブの数を制御します。 v1 SKU では、これらの追加の正常性プローブは、バックエンドの正常性をすばやく確認するために、プローブ間隔を待つことなく立て続けに送信されます。 v2 SKU の場合、正常性プローブはその期間を待ちます。 プローブの連続失敗回数が異常のしきい値に達すると、バックエンド サーバーは「ダウン」とマークされます。 |
既定のプローブは、正常性状態を判断する際に <protocol>://127.0.0.1:<port> だけをチェックします。 カスタム URL をチェックするように正常性プローブを構成するか、その他の設定を変更する必要がある場合は、カスタム プローブを使用する必要があります。
カスタムの正常性プローブ
カスタム プローブを使用すると、正常性監視をより細かく制御できます。 カスタム プローブを使用する場合、カスタム ホスト名、URL パス、プローブ間隔、およびバックエンド プール インスタンスを「異常」とマークするまでの応答の失敗回数などを構成することができます。
カスタムの正常性プローブの設定
カスタム正常性プローブのプロパティの定義を次の表に示します。
| プローブのプロパティ | 説明 |
|---|---|
| 名前 | プローブの名前。 この名前は、バックエンドの HTTP 設定でプローブを識別して参照するために使用されます。 |
| プロトコル | プローブを送信するために使用するプロトコル。 これは、関連付けられているバックエンド HTTP 設定で定義されているプロトコルと一致している必要があります |
| Host | プローブを送信するホスト名。 v1 SKU では、この値はプローブ要求のホスト ヘッダーに対してのみ使用されます。 v2 SKU では、ホスト ヘッダーおよび SNI の両方として使用されます |
| Path | プローブの相対パス。 パスは先頭が "/" である必要があります。 |
| Port | 定義されている場合は、宛先ポートとして使用されます。 それ以外の場合は、関連付けられている HTTP 設定と同じポートを使用します。 このプロパティは、v2 SKU でのみ使用できます。 |
| Interval | プローブの間隔 (秒)。 この値は、2 つの連続するプローブの時間間隔です |
| タイムアウト | プローブのタイムアウト (秒)。 このタイムアウト期間内に正常な応答が受信されなかった場合は、プローブが「失敗」とマークされます |
| 異常のしきい値 | プローブの再試行回数。 プローブの連続失敗回数が異常のしきい値に達すると、バックエンド サーバーは「ダウン」とマークされます |
プローブの一致
既定では、状態コードが 200 から 399 の HTTP(S) 応答は正常と見なされます。 カスタム正常性プローブでは、さらに 2 つの一致条件がサポートされます。 一致条件を使用して、正常な応答を行うための既定の解釈を必要に応じて変更できます。
一致条件は、次のとおりです。
- HTTP 応答の状態コードの一致 - ユーザー指定 http 応答コードまたは応答コードの範囲を受け入れるためのプローブの一致条件。 個々のコンマ区切りの応答状態コードまたは状態コードの範囲がサポートされています。
- HTTP 応答本文の一致 - HTTP 応答本文をチェックし、ユーザー指定文字列と一致させるプローブの一致条件。 一致ではユーザー指定文字列が応答本文内にあるかどうかのみがチェックされ、完全な正規表現の一致ではありません。 指定した一致は 4090 文字以下にする必要があります。
一致条件は New-AzApplicationGatewayProbeHealthResponseMatch コマンドレットを使用して指定できます。
例:
Azure PowerShell
$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399
$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"
一致条件は、PowerShell の -Match 演算子を使用してプローブ構成にアタッチできます。
カスタム プローブのユース ケース
- バックエンド サーバーによって、認証されたユーザーにのみアクセスが許可された場合、アプリケーション ゲートウェイ プローブは 200 ではなく 403 応答コードを受け取ります。 クライアント (ユーザー) がライブ トラフィックに対して自身を認証するようにバインドされるため、プローブ トラフィックを構成して、期待される応答として 403 を受け入れるようにすることができます。
- バックエンド サーバーにワイルドカード証明書 (*.contoso.com) がインストールされ、異なるサブドメインを提供する場合は、特定のホスト名 (SNI に必要) を指定してカスタム プローブを使用できます。このプローブは、正常な TLS プローブを確立し、そのサーバーを正常と報告するために受け入れられます。 バックエンド設定の [ホスト名の上書き] を [いいえ] に設定すると、異なる受信ホスト名 (サブドメイン) がバックエンドにそのまま渡されます。
ネットワーク セキュリティ グループ (NSG) に関する考慮事項
パブリック プレビューでは、NSG ルールを使用して Application Gateway サブネットを細かく制御できます。 詳細については、こちらをご覧ください。
現在の機能には、いくつかの制限があります。
Application Gateway v1 SKU の TCP ポート 65503 ～ 65534 と、v2 SKU の TCP ポート 65200 ～ 65535 で、宛先サブネットが [すべて]、ソースが GatewayManager サービス タグである着信インターネット トラフィックを許可する必要があります。 このポート範囲は、Azure インフラストラクチャの通信に必要です。
さらに、送信インターネット接続はブロックできないため、AzureLoadBalancer タグから送信された受信トラフィックを許可する必要があります。
アプリケーション ゲートウェイの動作
アプリケーション ゲートウェイでの要求の受け付け方法
- クライアントからアプリケーション ゲートウェイに要求が送信される前に、ドメイン ネーム システム (DNS) サーバーを使用してアプリケーション ゲートウェイのドメイン名が解決されます。 すべてのアプリケーション ゲートウェイは azure.com ドメインに存在するため、DNS エントリは Azure によって制御されます。
- Azure DNS によって、IP アドレス (アプリケーション ゲートウェイのフロントエンド IP アドレス) がクライアントに返されます。
- アプリケーション ゲートウェイは、1 つ以上のリスナーで受信トラフィックを受け付けます。 リスナーは、接続要求をチェックする論理エンティティです。 これは、クライアントからアプリケーション ゲートウェイに接続するためのフロントエンド IP アドレス、プロトコル、およびポート番号で構成されています。
- Web アプリケーション ファイアウォール (WAF) が使用されている場合、要求のヘッダーと本文が存在していれば、WAF 規則に対するチェックがアプリケーション ゲートウェイで実行されます。 このアクションによって、要求が有効な要求であるかセキュリティ上の脅威であるかが決定されます。 要求が有効な場合は、バックエンドにルーティングされます。 要求が有効ではなく、WAF が防止モードになっている場合は、セキュリティ上の脅威としてブロックされます。 検出モードの場合は、要求は評価されてログに記録されますが、それでもバックエンド サーバーに転送されます。
内部アプリケーション ロード バランサーまたはインターネットに接続しているアプリケーション ロード バランサーとして、Azure Application Gateway を使用できます。 インターネットに接続しているアプリケーション ゲートウェイでは、パブリック IP アドレスが使用されます。 インターネットに接続しているアプリケーション ゲートウェイの DNS 名は、そのパブリック IP アドレスにパブリックに解決できます。 その結果、インターネットに接続しているアプリケーション ゲートウェイで、インターネットからのクライアント要求をルーティングできます。
内部アプリケーション ゲートウェイでは、プライベート IP アドレスだけが使用されます。 カスタムまたはプライベート DNS ゾーンを使用している場合、ドメイン名は、アプリケーション ゲートウェイのプライベート IP アドレスに内部的に解決される必要があります。 そのため、内部ロード バランサーでは、アプリケーション ゲートウェイ用の仮想ネットワークにアクセスできるクライアントからの要求のみルーティングできます。
アプリケーション ゲートウェイでの要求のルーティング方法
要求が有効であり、WAF によってブロックされない場合は、リスナーに関連付けられている要求ルーティング規則がアプリケーション ゲートウェイで評価されます。 このアクションによって、どのバックエンド プールに要求をルーティングするかが決定されます。
要求ルーティング規則に基づいて、アプリケーション ゲートウェイでは、リスナー上のすべての要求を特定のバックエンド プールにルーティングするか、URL パスに基づいて異なるバックエンド プールにルーティングするか、別のポートまたは外部サイトにリダイレクトするかが決定されます。
アプリケーション ゲートウェイでバックエンド プールが選択されると、プール内のいずれかの正常なバックエンド サーバー (y.y.y.y) に要求が送信されます。 サーバーの正常性は、正常性プローブによって決定されます。 バックエンド プールに複数のサーバーが含まれている場合、アプリケーション ゲートウェイではラウンド ロビン アルゴリズムを使用して、正常なサーバーに要求がルーティングされます。 これにより、複数のサーバーに要求が負荷分散されます。
アプリケーション ゲートウェイでバックエンド サーバーが決定されると、HTTP 設定に基づいて、そのバックエンド サーバーとの新しい TCP セッションが開かれます。 HTTP 設定には、バックエンド サーバーとの新しいセッションを確立するために必要なプロトコル、ポート、その他のルーティング関連の設定が指定されています。
アプリケーション ゲートウェイとバックエンド サーバーの間でトラフィックが暗号化されるかどうか (またそれによって、エンド ツー エンドの TLS が達成されるかどうか) は、HTTP 設定で使用されているポートとプロトコルによって決まります。
Note
規則は、v1 SKU に対してポータルに一覧表示される順序で処理されます。
アプリケーション ゲートウェイによって元の要求がバックエンド サーバーに送信されるときに、HTTP 設定内のホスト名、パス、およびプロトコルをオーバーライドするためのカスタム構成が使用されます。 このアクションによって、Cookie ベースのセッション アフィニティ、接続のドレイン、バックエンドからのホスト名の選択が管理されます。
バックエンド プールが、
- パブリック エンドポイントである場合、アプリケーション ゲートウェイでは、フロントエンド パブリック IP を使用してサーバーに到達します。 フロントエンド パブリック IP アドレスが存在しない場合は、送信外部接続用のフロントエンド パブリック IP アドレスが割り当てられます。
- 内部的に解決できる FQDN またはプライベート IP アドレスが含まれている場合、アプリケーション ゲートウェイでは、インスタンスのプライベート IP アドレスを使用して、バックエンド サーバーに要求がルーティングされます。
- 外部エンドポイントまたは外部的に解決できる FQDN が含まれている場合、アプリケーション ゲートウェイでは、フロントエンド パブリック IP アドレスを使用して、要求がバックエンド サーバーにルーティングされます。 サブネットにサービス エンドポイントが含まれる場合、アプリケーション ゲートウェイにより要求がサービスにそのプライベート IP アドレス経由でルーティングされます。 プライベート DNS ゾーンまたはカスタム DNS サーバーが構成されている場合、DNS 解決はそれをペースとします。構成されていない場合、Azure で提供されている既定の DNS が使用されます。 フロントエンド パブリック IP アドレスが存在しない場合は、送信外部接続用のフロントエンド パブリック IP アドレスが割り当てられます。
バックエンド サーバーの DNS 解決
バックエンド プールのサーバーが完全修飾ドメイン名 (FQDN) で構成されている場合、Application Gateway では DNS 参照を実行してドメイン名の IP アドレスを取得します。 IP 値はお使いのアプリケーション ゲートウェイのキャッシュに格納され、受信要求を処理するとき、ターゲットにすばやく到達することを可能にします。
Application Gateway は、その DNS レコードの TTL (有効期間) に相当する期間、このキャッシュされた情報を保持し、TTL の有効期限が切れると新しい DNS 参照を実行します。 ゲートウェイはその後続の DNS クエリの IP アドレスの変更を検出すると、この更新された宛先へのトラフィックのルーティングを開始します。 DNS 参照で応答を受信できない、レコードが存在していないなどの問題が発生した場合、ゲートウェイでは、前回正常に使用できた IP アドレスが引き続き使用されます。 これにより、データ パスへの影響を最小限に抑えることができます。
- Application Gateway の仮想ネットワークでカスタム DNS サーバーを使用するとき、すべてのサーバーが同一であり、同じ DNS 値で一貫して応答することが重要です。
- オンプレミス カスタム DNS サーバーのユーザーは、プライベート エンドポイントにプライベート DNS ゾーンを使用するときは必ず、Azure DNS Private Resolver (推奨) または DNS フォワーダー経由で Azure DNS に接続する必要があります。
要求への変更
アプリケーション ゲートウェイは、要求をバックエンドに転送する前に、すべての要求に 6 つの追加ヘッダーを挿入します。 これらのヘッダーは、x-forwarded-for、x-forwarded-port、x-forwarded-proto、x-original-host、x-original-url、x-appgw-trace-id です。x-forwarded-for ヘッダーの形式は、IP:ポートのコンマ区切りリストです。
x-forwarded-proto の有効な値は、HTTP または HTTPS です。 x-forwarded-port には、要求がアプリケーション ゲートウェイに到達したポートが指定されます。 X-original-host ヘッダーには、到着した要求にあった元のホスト ヘッダーが含まれています。 このヘッダーは、トラフィックがバックエンドにルーティングされる前に受信ホスト ヘッダーが変更される Azure Web サイト統合で役立ちます。 オプションとしてセッション アフィニティが有効になっている場合は、ゲートウェイで管理されるアフィニティ Cookie が挿入されます。
x-appgw-trace-id は、アプリケーション ゲートウェイによってクライアント要求ごとに生成され、バックエンド プール メンバーに転送される要求に示される一意の GUID です。 GUID は、ダッシュなしで示される 32 文字の英数字で構成されます (例: ac882cd65a2712a0fe1289ec2bb6aee7)。 この GUID を使用して、アプリケーション ゲートウェイによって受信され、バックエンド プール メンバーに対して開始された要求を、診断ログ内の transactionId プロパティを介して関連付けることができます。
HTTP ヘッダーと URL を書き換える方法に関するページを使用して、要求および応答ヘッダーを変更したり、path-override 設定を使用して、URI パスを変更したりするようにアプリケーション ゲートウェイを構成できます。 ただし、そのように構成されていない限り、すべての受信要求はバックエンドにプロキシ処理されます。