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

既定では、Azure Application Gateway はバック エンド プールにあるすべてのリソースの状態を監視して、異常とみなしたリソースをプールから自動的に削除します。Azure Application Gateway by default monitors the health of all resources in its back-end pool and automatically removes any resource considered unhealthy from the pool. Application Gateway は異常なインスタンスを継続的に監視し、このインスタンスが利用可能になり正常性プローブに応答するようになると、正常バック エンド プールに戻します。Application Gateway continues to monitor the unhealthy instances and adds them back to the healthy back-end pool once they become available and respond to health probes. 既定では、バックエンドの HTTP 設定で定義されているポートを使用して、Application Gateway から正常性プローブが送信されます。By default, Application gateway sends the health probes with the same port that is defined in the back-end HTTP settings. カスタム プローブ ポートは、カスタムの正常性プローブを使用して構成できます。A custom probe port can be configured using a custom health probe.

Application Gateway で正常性プローブに使用される発信元 IP アドレスは、バックエンド プールによって異なります。The source IP address Application Gateway uses for health probes depends on the backend pool:

  • バックエンド プール内のサーバー アドレスがパブリック エンドポイントの場合、ソース アドレスはアプリケーション ゲートウェイのフロントエンド パブリック IP アドレスです。If the server address in the backend pool is a public endpoint, then the source address is the application gateway's frontend public IP address.
  • バックエンド プール内のサーバー アドレスがプライベート エンドポイントの場合、ソース IP アドレスは Application Gateway サブネットのプライベート IP アドレス空間からのものです。If the server address in the backend pool is a private endpoint, then the source IP address is from the application gateway subnet's private IP address space.

application gateway probe example

既定の正常性プローブによる監視を行うだけでなく、アプリケーションの要件に合わせて正常性プローブをカスタマイズすることもできます。In addition to using default health probe monitoring, you can also customize the health probe to suit your application's requirements. この記事では、既定とカスタムの両方の正常性プローブについて説明します。In this article, both default and custom health probes are covered.

注意

この記事は、新しい Azure PowerShell Az モジュールを使用するために更新されました。This article has been updated to use the new Azure PowerShell Az module. AzureRM モジュールはまだ使用でき、少なくとも 2020 年 12 月までは引き続きバグ修正が行われます。You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. Az モジュールと AzureRM の互換性の詳細については、「Introducing the new Azure PowerShell Az module (新しい Azure PowerShell Az モジュールの概要)」を参照してください。To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. Az モジュールのインストール手順については、Azure PowerShell のインストールを参照してください。For Az module installation instructions, see Install Azure PowerShell.

既定の正常性プローブDefault health probe

カスタム プローブ構成を設定しない場合、アプリケーション ゲートウェイにより既定の正常性プローブが自動で構成されます。An application gateway automatically configures a default health probe when you don't set up any custom probe configuration. 監視は、バックエンド プール内の構成済みの IP アドレスまたは FQDN に対して HTTP GET 要求を行うことで実行されます。The monitoring behavior works by making an HTTP GET request to the IP addresses or FQDN configured in the back-end pool. 既定のプローブでは、バックエンドの http 設定が HTTPS に対応するように構成されている場合、プローブはバックエンド サーバーの正常性をテストする際に HTTPS を使用します。For default probes if the backend http settings are configured for HTTPS, the probe uses HTTPS to test health of the backend servers.

次に例を示します。バックエンド サーバー A、B、C を使用して ポート 80 で HTTP ネットワーク トラフィックを受信するように、アプリケーション ゲートウェイを構成したとします。For example: You configure your application gateway to use back-end servers A, B, and C to receive HTTP network traffic on port 80. 既定の正常性監視では、30 秒ごとにこれら 3 つのサーバーに対して HTTP 応答が正常であるかどうかがテストされます。その際には、各要求に対して 30 秒のタイムアウトが適用されます。The default health monitoring tests the three servers every 30 seconds for a healthy HTTP response with a 30 second timeout for each request. 正常な HTTP 応答の 状態コード は、200 から 399 の間です。A healthy HTTP response has a status code between 200 and 399. この場合、正常性プローブの HTTP GET 要求は http://127.0.0.1/ のようになります。In this case, the HTTP GET request for the health probe will look like http://127.0.0.1/.

サーバー A に対する既定のプローブ チェックが失敗した場合、Application Gateway はこのサーバーへの要求の転送を停止します。If the default probe check fails for server A, the application gateway stops forwarding requests to this server. 既定のプローブは、削除後もサーバー A を 30 秒ごとにチェックし続けます。The default probe still continues to check for server A every 30 seconds. サーバー A が既定の正常性プローブからの 1 つの要求に正常に応答すると、Application Gateway はサーバーへの要求の転送を再び開始します。When server A responds successfully to one request from a default health probe, application gateway starts forwarding the requests to the server again.

既定の正常性プローブの設定Default health probe settings

プローブのプロパティProbe property Value 説明Description
プローブの URLProbe URL <protocol>://127.0.0.1:<port>/<protocol>://127.0.0.1:<port>/ プロトコルとポートは、プローブが関連付けられているバックエンド HTTP 設定から継承されます。The protocol and port are inherited from the backend HTTP settings to which the probe is associated
IntervalInterval 3030 次の正常性プローブが送信されるまでの秒数です。The amount of time in seconds to wait before the next health probe is sent.
タイムアウトTime-out 3030 アプリケーション ゲートウェイがプローブの応答を待機する秒数です。これを超えると、プローブは異常としてマークされます。The amount of time in seconds the application gateway waits for a probe response before marking the probe as unhealthy. プローブが正常として返された場合は、対応するバックエンドがすぐに正常としてマークされます。If a probe returns as healthy, the corresponding backend is immediately marked as healthy.
異常のしきい値Unhealthy threshold 33 通常の正常性プローブで障害が発生した場合に送信するプローブの数を制御します。Governs how many probes to send in case there's a failure of the regular health probe. v1 SKU では、これらの追加の正常性プローブは、バックエンドの正常性をすばやく確認するために、プローブ間隔を待つことなく立て続けに送信されます。In v1 SKU, these additional health probes are sent in quick succession to determine the health of the backend quickly and don't wait for the probe interval. v2 SKU の場合、正常性プローブはその期間を待ちます。In the case of v2 SKU, the health probes wait the interval. プローブの連続失敗回数が異常のしきい値に達すると、バックエンド サーバーは「ダウン」とマークされます。The back-end server is marked down after the consecutive probe failure count reaches the unhealthy threshold.

既定のプローブは、正常性状態を判断する際に <protocol>://127.0.0.1:<port> だけをチェックします。The default probe looks only at <protocol>://127.0.0.1:<port> to determine health status. カスタム URL をチェックするように正常性プローブを構成するか、その他の設定を変更する必要がある場合は、カスタム プローブを使用する必要があります。If you need to configure the health probe to go to a custom URL or modify any other settings, you must use custom probes. HTTPS プローブの詳細については、「Application Gateway での TLS 終了とエンド ツー エンド TLS の概要」を参照してください。For more information about HTTPS probes, see Overview of TLS termination and end to end TLS with Application Gateway.

プローブの期間Probe intervals

Application Gateway のすべてのインスタンスは、互いに独立してバックエンドをプローブします。All instances of Application Gateway probe the backend independent of each other. 各 Application Gateway インスタンスには、同じプローブ構成が適用されます。The same probe configuration applies to each Application Gateway instance. たとえば、プローブ構成が 30 秒ごとに正常性プローブを送信するよう設定されていて、アプリケーション ゲートウェイに 2 つのインスタンスがある場合は、どちらのインスタンスも 30 秒ごとに正常性プローブを送信します。For example, if the probe configuration is to send health probes every 30 seconds and the application gateway has two instances, then both instances send the health probe every 30 seconds.

また、複数のリスナーがある場合、各リスナーは互いに独立してバックエンドをプローブします。Also if there are multiple listeners, then each listener probes the backend independent of each other. たとえば、2 つの異なるポート上で同じバックエンド プールをポイントしている 2 つのリスナーがある場合 (それらが 2 つのバックエンド http 設定で構成されている場合)、各リスナーは同じバックエンドを個別にプローブします。For example, if there are two listeners pointing to the same backend pool on two different ports (configured by two backend http settings) then each listener probes the same backend independently. その場合は、2 つのリスナーに対して、各アプリケーション ゲートウェイ インスタンスからの 2 つのプローブが存在することになります。In this case, there are two probes from each application gateway instance for the two listeners. このシナリオでアプリケーション ゲートウェイのインスタンスが 2 つある場合、バックエンドの仮想マシンでは、構成済みのプローブ期間ごとに 4 つのプローブが確認されることになります。If there are two instances of the application gateway in this scenario, the backend virtual machine would see four probes per the configured probe interval.

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

カスタム プローブを使用すると、正常性監視をより細かく制御できます。Custom probes allow you to have more granular control over the health monitoring. カスタム プローブを使用する場合、カスタム ホスト名、URL パス、プローブ間隔、およびバックエンド プール インスタンスを「異常」とマークするまでの応答の失敗回数などを構成することができます。When using custom probes, you can configure a custom hostname, URL path, probe interval, and how many failed responses to accept before marking the back-end pool instance as unhealthy, etc.

カスタムの正常性プローブの設定Custom health probe settings

カスタム正常性プローブのプロパティの定義を次の表に示します。The following table provides definitions for the properties of a custom health probe.

プローブのプロパティProbe property 説明Description
名前Name プローブの名前。Name of the probe. この名前は、バックエンドの HTTP 設定でプローブを識別して参照するために使用されます。This name is used to identify and refer to the probe in back-end HTTP settings.
ProtocolProtocol プローブを送信するために使用するプロトコル。Protocol used to send the probe. これは、関連付けられているバックエンド HTTP 設定で定義されているプロトコルと一致している必要があります。This has to match with the protocol defined in the back-end HTTP settings it is associated to
HostHost プローブを送信するホスト名。Host name to send the probe with. v1 SKU では、この値はプローブ要求のホスト ヘッダーに対してのみ使用されます。In v1 SKU, this value will be used only for the host header of the probe request. v2 SKU では、ホスト ヘッダーおよび SNI の両方として使用されます。In v2 SKU, it will be used both as host header as well as SNI
PathPath プローブの相対パス。Relative path of the probe. パスは先頭が "/" である必要があります。A valid path starts with '/'
PortPort 定義されている場合は、宛先ポートとして使用されます。If defined, this is used as the destination port. それ以外の場合は、関連付けられている HTTP 設定と同じポートを使用します。Otherwise, it uses the same port as the HTTP settings that it is associated to. このプロパティは、v2 SKU でのみ使用できます。This property is only available in the v2 SKU
IntervalInterval プローブの間隔 (秒)。Probe interval in seconds. この値は、2 つの連続するプローブの時間間隔ですThis value is the time interval between two consecutive probes
タイムアウトTime-out プローブのタイムアウト (秒)。Probe time-out in seconds. このタイムアウト期間内に正常な応答が受信されなかった場合は、プローブが「失敗」とマークされますIf a valid response isn't received within this time-out period, the probe is marked as failed
異常のしきい値Unhealthy threshold プローブの再試行回数。Probe retry count. プローブの連続失敗回数が異常のしきい値に達すると、バックエンド サーバーは「ダウン」とマークされますThe back-end server is marked down after the consecutive probe failure count reaches the unhealthy threshold

プローブの一致Probe matching

既定では、状態コードが 200 から 399 の HTTP(S) 応答は正常と見なされます。By default, an HTTP(S) response with status code between 200 and 399 is considered healthy. カスタム正常性プローブでは、さらに 2 つの一致条件がサポートされます。Custom health probes additionally support two matching criteria. 一致条件を使用して、正常な応答を行うための既定の解釈を必要に応じて変更できます。Matching criteria can be used to optionally modify the default interpretation of what makes a healthy response.

一致条件は、次のとおりです。The following are matching criteria:

  • HTTP 応答の状態コードの一致 - ユーザー指定 http 応答コードまたは応答コードの範囲を受け入れるためのプローブの一致条件。HTTP response status code match - Probe matching criterion for accepting user specified http response code or response code ranges. 個々のコンマ区切りの応答状態コードまたは状態コードの範囲がサポートされています。Individual comma-separated response status codes or a range of status code is supported.
  • HTTP 応答本文の一致 - HTTP 応答本文をチェックし、ユーザー指定文字列と一致させるプローブの一致条件。HTTP response body match - Probe matching criterion that looks at HTTP response body and matches with a user specified string. 一致ではユーザー指定文字列が応答本文内にあるかどうかのみがチェックされ、完全な正規表現の一致ではありません。The match only looks for presence of user specified string in response body and isn't a full regular expression match.

一致条件は New-AzApplicationGatewayProbeHealthResponseMatch コマンドレットを使用して指定できます。Match criteria can be specified using the New-AzApplicationGatewayProbeHealthResponseMatch cmdlet.

次に例を示します。For example:

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

一致条件が指定されたら、PowerShell の -Match パラメーターを使用してプローブの構成にアタッチできます。Once the match criteria is specified, it can be attached to probe configuration using a -Match parameter in PowerShell.

NSG に関する考慮事項NSG considerations

Application Gateway v1 SKU の TCP ポート 65503 ~ 65534 と、v2 SKU の TCP ポート 65200 ~ 65535 で、宛先サブネットが [すべて] 、ソースが GatewayManager サービス タグである着信インターネット トラフィックを許可する必要があります。You must allow incoming Internet traffic on TCP ports 65503-65534 for the Application Gateway v1 SKU, and TCP ports 65200-65535 for the v2 SKU with the destination subnet as Any and source as GatewayManager service tag. このポート範囲は、Azure インフラストラクチャの通信に必要です。This port range is required for Azure infrastructure communication.

さらに、送信インターネット接続はブロックできないため、AzureLoadBalancer タグから送信された受信トラフィックを許可する必要があります。Additionally, outbound Internet connectivity can't be blocked, and inbound traffic coming from the AzureLoadBalancer tag must be allowed.

詳細については、「アプリケーション ゲートウェイ構成の概要」を参照してください。For more information, see Application Gateway configuration overview.

次のステップNext steps

Application Gateway による正常性監視について学習した後は、Azure Portal でカスタム正常性プローブを構成することも、PowerShell と Azure Resource Manager デプロイ モデルを使用してカスタム正常性プローブを構成することもできます。After learning about Application Gateway health monitoring, you can configure a custom health probe in the Azure portal or a custom health probe using PowerShell and the Azure Resource Manager deployment model.