Application Gateway による正常性監視の概要

既定では、Azure Application Gateway はバック エンド プールにあるすべてのリソースの状態を監視して、異常とみなしたリソースをプールから自動的に削除します。 Application Gateway は異常なインスタンスを継続的に監視し、このインスタンスが利用可能になり正常性プローブに応答するようになると、正常バック エンド プールに戻します。 既定では、バックエンドの HTTP 設定で定義されているポートを使用して、Application Gateway から正常性プローブが送信されます。 カスタム プローブ ポートは、カスタムの正常性プローブを使用して構成できます。

Application Gateway で正常性プローブに使用される発信元 IP アドレスは、バックエンド プールによって異なります。

  • バックエンド プール内のサーバー アドレスがパブリック エンドポイントの場合、ソース アドレスはアプリケーション ゲートウェイのフロントエンド パブリック IP アドレスです。
  • バックエンド プール内のサーバー アドレスがプライベート エンドポイントの場合、ソース IP アドレスは Application Gateway サブネットのプライベート IP アドレス空間からのものです。

application gateway probe example

既定の正常性プローブによる監視を行うだけでなく、アプリケーションの要件に合わせて正常性プローブをカスタマイズすることもできます。 この記事では、既定とカスタムの両方の正常性プローブについて説明します。

注意

この記事では、Azure と対話するために推奨される PowerShell モジュールである Azure Az PowerShell モジュールを使用します。 Az PowerShell モジュールの使用を開始するには、「Azure PowerShell をインストールする」を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。

既定の正常性プローブ

カスタム プローブ構成を設定しない場合、アプリケーション ゲートウェイにより既定の正常性プローブが自動で構成されます。 監視は、バックエンド プール内の構成済みの 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/ のようになります。

サーバー A に対する既定のプローブ チェックが失敗した場合、Application Gateway はこのサーバーへの要求の転送を停止します。 既定のプローブは、削除後もサーバー A を 30 秒ごとにチェックし続けます。 サーバー A が既定の正常性プローブからの 1 つの要求に正常に応答すると、Application Gateway はサーバーへの要求の転送を再び開始します。

既定の正常性プローブの設定

プローブのプロパティ 説明
プローブの URL <protocol>://127.0.0.1:<port>/ プロトコルとポートは、プローブが関連付けられているバックエンド HTTP 設定から継承されます。
Interval 30 次の正常性プローブが送信されるまでの秒数です。
タイムアウト 30 アプリケーション ゲートウェイがプローブの応答を待機する秒数です。これを超えると、プローブは異常としてマークされます。 プローブが正常として返された場合は、対応するバックエンドがすぐに正常としてマークされます。
異常のしきい値 3 通常の正常性プローブで障害が発生した場合に送信するプローブの数を制御します。 v1 SKU では、これらの追加の正常性プローブは、バックエンドの正常性をすばやく確認するために、プローブ間隔を待つことなく立て続けに送信されます。 v2 SKU の場合、正常性プローブはその期間を待ちます。 プローブの連続失敗回数が異常のしきい値に達すると、バックエンド サーバーは「ダウン」とマークされます。

既定のプローブは、正常性状態を判断する際に <protocol>://127.0.0.1:<port> だけをチェックします。 カスタム URL をチェックするように正常性プローブを構成するか、その他の設定を変更する必要がある場合は、カスタム プローブを使用する必要があります。 HTTPS プローブの詳細については、「Application Gateway での TLS 終了とエンド ツー エンド TLS の概要」を参照してください。

プローブの期間

Application Gateway のすべてのインスタンスは、互いに独立してバックエンドをプローブします。 各 Application Gateway インスタンスには、同じプローブ構成が適用されます。 たとえば、プローブ構成が 30 秒ごとに正常性プローブを送信するよう設定されていて、アプリケーション ゲートウェイに 2 つのインスタンスがある場合は、どちらのインスタンスも 30 秒ごとに正常性プローブを送信します。

また、複数のリスナーがある場合、各リスナーは互いに独立してバックエンドをプローブします。 たとえば、2 つの異なるポート上で同じバックエンド プールをポイントしている 2 つのリスナーがある場合 (それらが 2 つのバックエンド http 設定で構成されている場合)、各リスナーは同じバックエンドを個別にプローブします。 その場合は、2 つのリスナーに対して、各アプリケーション ゲートウェイ インスタンスからの 2 つのプローブが存在することになります。 このシナリオでアプリケーション ゲートウェイのインスタンスが 2 つある場合、バックエンドの仮想マシンでは、構成済みのプローブ期間ごとに 4 つのプローブが確認されることになります。

カスタムの正常性プローブ

カスタム プローブを使用すると、正常性監視をより細かく制御できます。 カスタム プローブを使用する場合、カスタム ホスト名、URL パス、プローブ間隔、およびバックエンド プール インスタンスを「異常」とマークするまでの応答の失敗回数などを構成することができます。

カスタムの正常性プローブの設定

カスタム正常性プローブのプロパティの定義を次の表に示します。

プローブのプロパティ 説明
名前 プローブの名前。 この名前は、バックエンドの HTTP 設定でプローブを識別して参照するために使用されます。
Protocol プローブを送信するために使用するプロトコル。 これは、関連付けられているバックエンド HTTP 設定で定義されているプロトコルと一致している必要があります。
Host プローブを送信するホスト名。 v1 SKU では、この値はプローブ要求のホスト ヘッダーに対してのみ使用されます。 v2 SKU では、ホスト ヘッダーおよび SNI の両方として使用されます。
Path プローブの相対パス。 パスは先頭が "/" である必要があります。
Port 定義されている場合は、宛先ポートとして使用されます。 それ以外の場合は、関連付けられている HTTP 設定と同じポートを使用します。 このプロパティは、v2 SKU でのみ使用できます。
Interval プローブの間隔 (秒)。 この値は、2 つの連続するプローブの時間間隔です
タイムアウト プローブのタイムアウト (秒)。 このタイムアウト期間内に正常な応答が受信されなかった場合は、プローブが「失敗」とマークされます
異常のしきい値 プローブの再試行回数。 プローブの連続失敗回数が異常のしきい値に達すると、バックエンド サーバーは「ダウン」とマークされます

プローブの一致

既定では、状態コードが 200 から 399 の HTTP(S) 応答は正常と見なされます。 カスタム正常性プローブでは、さらに 2 つの一致条件がサポートされます。 一致条件を使用して、正常な応答を行うための既定の解釈を必要に応じて変更できます。

一致条件は、次のとおりです。

  • HTTP 応答の状態コードの一致 - ユーザー指定 http 応答コードまたは応答コードの範囲を受け入れるためのプローブの一致条件。 個々のコンマ区切りの応答状態コードまたは状態コードの範囲がサポートされています。
  • HTTP 応答本文の一致 - HTTP 応答本文をチェックし、ユーザー指定文字列と一致させるプローブの一致条件。 一致ではユーザー指定文字列が応答本文内にあるかどうかのみがチェックされ、完全な正規表現の一致ではありません。

一致条件は New-AzApplicationGatewayProbeHealthResponseMatch コマンドレットを使用して指定できます。

次に例を示します。

$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399
$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"

一致条件が指定されたら、PowerShell の -Match パラメーターを使用してプローブの構成にアタッチできます。

NSG に関する考慮事項

Application Gateway v1 SKU の TCP ポート 65503 ~ 65534 と、v2 SKU の TCP ポート 65200 ~ 65535 で、宛先サブネットが [すべて] 、ソースが GatewayManager サービス タグである着信インターネット トラフィックを許可する必要があります。 このポート範囲は、Azure インフラストラクチャの通信に必要です。

さらに、送信インターネット接続はブロックできないため、AzureLoadBalancer タグから送信された受信トラフィックを許可する必要があります。

詳細については、「アプリケーション ゲートウェイ構成の概要」を参照してください。

次のステップ

Application Gateway による正常性監視について学習した後は、Azure Portal でカスタム正常性プローブを構成することも、PowerShell と Azure Resource Manager デプロイ モデルを使用してカスタム正常性プローブを構成することもできます。