Azure Load Balancer の正常性プローブ
Azure Load Balancer 正常性プローブは、アプリケーション インスタンスの正常性状態を検出する機能です。 インスタンスに要求を送信して、インスタンスが使用可能で要求に応答しているかを確認します。 正常性プローブは、TCP、HTTP、HTTPS などのさまざまなプロトコルを使用するように構成できます。 アプリケーションの障害の検出、負荷の管理、ダウンタイムの計画に役立つため、これは重要な機能です。
Azure Load Balancer ルールでは、エンドポイントの状態を検出するために正常性プローブが必要です。 正常性プローブの構成とプローブの応答によって、新しい接続を受け入れるバックエンド プール インスタンスが決まります。 正常性プローブを使用して、アプリケーションの障害を検出します。 正常性プローブに対するカスタム応答を生成します。 フロー制御のために正常性プローブを使用して、負荷または計画されたダウンタイムを管理します。 正常性プローブが失敗した場合、Load Balancer は、それぞれの異常なインスタンスへの新しい接続の送信を停止します。 アウトバウンド接続は影響を受けず、インバウンド接続のみが影響を受けます。
プローブ プロトコル
正常性プローブでは、複数のプロトコルがサポートされます。 特定の正常性プローブ プロトコルを利用できるどうかは、Load Balancer SKU によって異なります。 さらに、次の表で示すように、サービスの動作も Load Balancer SKU によって異なります。
| SKU | プローブ プロトコル | プローブのダウン動作 |
|---|---|---|
| Standard | TCP、HTTP、HTTPS | すべてのプローブがダウンすると、すべての TCP フローは続行します。 |
| 基本 | TCP、HTTP | すべてのプローブがダウンすると、すべての TCP フローは終了します。 |
プローブのプロパティ
正常性プローブには次のプロパティがあります。
| 正常性プローブのプロパティ名 | 詳細 |
|---|---|
| 名前 | 正常性プローブの名前。 これは、正常性プローブ用に定義する名前です |
| Protocol | 正常性プローブのプロトコル。 これは正常性プローブで使用するプロトコルの種類です。 オプションは、TCP、HTTP、HTTPS です |
| Port | 正常性プローブのポート。 正常性プローブにおいて、仮想マシンに接続してその正常性をチェックする際に使用する宛先ポート |
| 間隔 (秒) | 正常性プローブの間隔。 異なるプローブによる仮想マシンに対する連続した 2 回の正常性チェックの再試行までの時間 (秒単位) |
| 使用者 | この特定の正常性プローブを使用するロード バランサー規則の一覧。 正常性プローブを使用して有効にするには、少なくとも 1 つのルールが必要です |
プローブの構成
正常性プローブの構成は、次の要素から成っています。
| 正常性プローブの構成 | 詳細 |
|---|---|
| プロトコル | 正常性プローブのプロトコル。 これは正常性プローブで使用するプロトコルの種類です。 使用可能なオプション: TCP、HTTP、HTTPS |
| Port | 正常性プローブのポート。 正常性プローブで、仮想マシンに接続して仮想マシンの正常性状態をチェックするときに使用する宛先ポート。 仮想マシンもこのポートでリッスンしている (つまりポートが開いている) ことを確認する必要があります。 |
| Interval | 正常性プローブの間隔。 仮想マシンに対する連続した正常性チェック試行の時間間隔 (秒) です |
プローブ プロトコル
正常性プローブで使用されるプロトコルは、TCP、HTTP、HTTPS のいずれかのオプションで構成できます。
| シナリオ | TCP プローブ | HTTP / HTTPS プローブ |
|---|---|---|
| 概要 | TCP プローブは、定義済みのポートに 3 ウェイ オープン TCP ハンドシェイクを実行して、接続を開始します。 TCP プローブでは、4 ウェイ クローズ TCP ハンドシェイクによって接続が終了します。 | HTTP と HTTPS は、パスが指定された HTTP GET を発行します。 これら両方のプローブは、HTTP GET に対して相対パスをサポートします。 HTTPS プローブは、トランスポート層セキュリティ (TLS) ラッパーがある点を除き、HTTP プローブと同じです。 プローブ ポートがサービスに対するリスナーでもある場合は、HTTP/HTTPS プローブは、ロード バランサーからインスタンスを削除するお客様独自のロジックを実装するのに役立ちます。 |
| プローブ失敗の動作 | 次の場合に TCP プローブは失敗します: 1。 タイムアウト期間中に、インスタンスで TCP リスナーがまったく応答しない場合。 プローブは、タイムアウトしたプローブ要求の数に基づいてダウンとしてマークされます。これらは、プローブがダウンとしてマークされる前に、応答なしになるように構成されています。 2. プローブがインスタンスから TCP リセットを受信した場合。 |
次の場合に HTTP/HTTPS プローブは失敗します: 1。 プローブ エンドポイントが、200 以外の HTTP 応答コード (403、404、500 など) を返す場合。 2. プローブ エンドポイントは、プローブ間隔の最小値と 30 秒のタイムアウト期間中はまったく応答しません。 プローブが停止中としてマークされる前に、すべてのタイムアウト間隔の合計に達するまで、複数のプローブ要求が応答なしになる可能性があります。 3. プローブ エンドポイントが TCP リセットによって接続を閉じた場合。 |
| プローブのアップ動作 | 次の場合に TCP 正常性プローブは正常と見なされ、バックエンド エンドポイントは正常としてマークされます: 1。 VM の起動後に一度正常性プローブが成功している。 2. 正常な状態のバックエンド エンドポイントは、新しいフローを受け取ることができます。 |
タイムアウト期間内にインスタンスが HTTP ステータス 200 で応答すると、正常性プローブはアップとしてマークされます。 次の場合に HTTP/HTTPS 正常性プローブは正常と見なされ、バックエンド エンドポイントは正常としてマークされます: 1。 VM の起動後に一度正常性プローブが成功している。 2. 正常な状態のバックエンド エンドポイントは、新しいフローを受け取ることができます。 |
Note
HTTPS プローブでは、チェーン全体で SHA256 の最小署名ハッシュを持つ証明書を使用する必要があります。
プローブのダウン動作
| シナリオ | TCP 接続 | UDP データグラム |
|---|---|---|
| 単一インスタンスのプローブでダウン | 新しい TCP 接続は、残りの正常なバックエンド エンドポイントに対して成功します。 このバックエンド エンドポイントへの確立された TCP 接続は続行されます。 | 既存の UDP フローは、バックエンド プール内にある別の正常なインスタンスに移動されます。 |
| すべてのインスタンスのプローブでダウン | 新しいフローはバックエンド プールに送信されません。 Standard Load Balancer では、バックエンド プールに複数のバックエンド インスタンスがある場合、確立された TCP フローを続行できます。 Basic Load Balancer は、バックエンド プールに対するすべての既存の TCP フローを終了します。 | 既存のすべての UDP フローは終了します。 |
プローブの間隔とタイムアウト
間隔の値により、正常性プローブによってバックエンド プール インスタンスからの応答の検査が行われる頻度が決まります。 正常性プローブが失敗した場合、そのバックエンド プール インスタンスはすぐに異常としてマークされます。 正常性プローブが次は正常なプローブで成功した場合、Azure Load Balancer はバックエンド プール インスタンスを正常としてマークします。 正常性プローブは、構成された正常性プローブ ポートを Azure portal の既定では 5 秒ごとにチェックしますが、別の値を明示的に設定することもできます。
タイムリーな応答を確実に受信するために、HTTP/S 正常性プローブには組み込みのタイムアウトがあります。 TCP プローブと HTTP/S プローブのタイムアウト期間を次に示します:
- TCP プローブのタイムアウト期間: N/A (構成されたプローブ間隔の期間が経過し、次のプローブが送信されると、プローブは失敗します)
- HTTP/S プローブのタイムアウト期間: 30 秒
HTTP/S プローブの場合、構成された間隔が上記のタイムアウト期間より長い場合、正常性プローブはタイムアウトし、タイムアウト期間内に応答が受信されない場合は失敗します。 たとえば、HTTP 正常性プローブが 120 秒 (2 分ごと) のプローブ間隔で構成され、最初の 30 秒以内にプローブ応答が受信されない場合、プローブはタイムアウト期間に達し、失敗します。 構成された間隔が上記のタイムアウト期間より短い場合、構成された間隔の期間が完了する前に応答が受信されないと正常性プローブは失敗し、次のプローブが直ちに送信されます。
設計ガイダンス
アプリケーションの正常性モデルを設計するときは、インスタンスおよびアプリケーション サービスの正常性が反映されるバックエンド エンドポイントのポートをプローブする必要があります。 アプリケーション ポートとプローブ ポートが同一である必要はありません。 一部のシナリオでは、アプリケーションで使用するポートとは異なるプローブ ポートを使用することが望ましい場合がありますが、一般的にはプローブは同じポートを使用することをお勧めします。
アプリケーションで正常性プローブ応答を生成し、インスタンスが新しい接続を受け取る必要があるかどうかをロード バランサーに通知するのに役立ちます。 プローブ応答を操作し、正常性プローブを失敗させることで、インスタンスへの新しい接続の提供を調整できます。 アプリケーションのメンテナンスを準備し、アプリケーションへの接続のドレインを開始できます。 Standard Load Balancer では、プローブのダウン信号では常に、アイドル タイムアウトまたは接続の終了まで TCP フローが継続されます。
UDP の負荷分散アプリケーションの場合は、バックエンド エンドポイントからカスタム正常性プローブ シグナルを生成します。 正常性プローブには、対応するリスナーと一致する TCP、HTTP、または HTTPS のいずれかを使います。
Standard Load Balancer を使用した HA ポートの負荷分散ルールです。 すべてのポートが負荷分散され、単一の正常性プローブの応答にインスタンス全体の状態が反映されている必要があります。
仮想ネットワーク内にある別のインスタンスへの正常性プローブを受信するインスタンスで、正常性プローブの変換またはプロキシを行わないでください。 この構成にすると、障害が発生する場合があります。 たとえば、サード パーティのアプライアンスのセットが、拡張性と冗長性のため、ロード バランサーのバックエンド プールにデプロイされています。 正常性プローブは、アプライアンスの内側にある他の仮想マシンへのプロキシまたは変換がサード パーティのアプライアンスによって行われるポートをプローブするように構成されています。 アプライアンスの内側にある他の仮想マシンに対して要求を変換またはプロキシするために使用されるのと同じポートをプローブした場合、単一の仮想マシンからのプローブ応答によって、アプライアンスがダウンとしてマークされます。 この構成では、アプリケーションの障害が連鎖する可能性があります。 プローブの断続的な失敗がトリガーとなって、ロード バランサーがアプライアンスのインスタンスをダウンとしてマークする可能性があります。 この操作により、アプリケーションが無効になる場合があります。 アプライアンス自体の正常性をプローブしてください。 正常性シグナルを特定するプローブの選択はネットワーク仮想アプライアンス (NVA) のシナリオで重要な考慮事項です。 そのようなシナリオに適切な正常性シグナルについては、アプリケーション ベンダーに問い合わせてください。
仮想マシンに複数のインターフェイスを構成してある場合は、プローブを受信したインターフェイスでプローブに応答することを確認します。 VM でインターフェイスごとにこのアドレスをソース ネットワーク アドレス変換することが必要な場合があります。
Azure PowerShell、Azure CLI、テンプレート、または API を使用するとき、プローブ定義は必須ではなく、チェックもされません。 プローブ検証テストは、Azure portal を使用するときにのみ行われます。
正常性プローブが変動する場合、ロード バランサ―は、さらに長い時間待機してから、バックエンド エンドポイントを正常な状態に戻します。 この余分な待機時間は、ユーザーとインフラストラクチャを保護するためであり、意図的なポリシーです。
仮想マシン インスタンスが実行されていることを確認します。 バックエンド プールで実行中のインスタンスごとに、正常性プローブによって可用性がチェックされます。 インスタンスが停止された場合、そのインスタンスは再起動するまでプローブされません。
168.63.129.16 が含まれる Microsoft 所有の IP アドレス範囲を使って、仮想ネットワークを構成しないでください。 この構成は正常性プローブの IP アドレスと競合し、シナリオが失敗する原因になる可能性があります。
正常性プローブの失敗をテストしたり、個々のインスタンスをダウンにしたりするには、ネットワーク セキュリティ グループを使って、正常性プローブを明示的にブロックします。 プローブの失敗をシミュレートするには、宛先ポートまたはソース IP をブロックする NSG 規則を作成します。
負荷分散規則とは異なり、インバウンド NAT 規則には正常性プローブをアタッチする必要はありません。
NSG 規則を使用して Azure Load Balancer の正常性プローブの IP またはポートをブロックすることは推奨されません。 これはサポートされていないシナリオであり、NSG 規則で遅延効果が発生する原因となり、結果的に正常性プローブがバックエンド インスタンスの可用性を不正確に表すようになる可能性があります。
監視
Standard Load Balancer により、エンドポイントおよびバックエンド エンドポイントごとの正常性プローブの状態が Azure Monitor を通じて公開されます。 これらのメトリックは、他の Azure サービスやパートナー アプリケーションによって消費される可能性があります。 Azure Monitor ログは Basic Load Balancer ではサポートされていません。
プローブのソース IP アドレス
Azure Load Balancer の正常性プローブでインスタンスがアップとしてマークされるには、すべての Azure ネットワーク セキュリティ グループとローカル ファイアウォール ポリシーで、168.63.129.16 という IP アドレスを許可する必要があります。 AzureLoadBalancer サービス タグによって、お客様のネットワーク セキュリティ グループ内でこのソース IP アドレスが特定され、正常性プローブのトラフィックが既定で許可されます。 この IP ついて詳しくは、こちらをご覧ください。
お客様のファイアウォール ポリシーでプローブのソース IP を許可しない場合、正常性プローブはお客様のインスタンスに到達できないため失敗します。 その結果、正常性プローブの失敗により、Azure Load Balancer はインスタンスを -ダウン- としてマークします。 この誤った構成は、お客様の負荷分散アプリケーションのシナリオが失敗する原因となる可能性があります。 IPv4 Load Balancer のすべての正常性プローブは、ソースとして IP アドレス 168.63.129.16 から送信されます。 IPv6 プローブは、リンクローカル アドレス (fe80::1234:5678:9abc) をソースとして使用します。 デュアルスタック Azure Load Balancer の場合は、IPv6 正常性プローブが機能するようにネットワーク セキュリティ グループを構成する必要があります。
制限事項
HTTPS プローブは、クライアント証明書との相互認証をサポートしていません。
HTTP プローブは、プローブのバックエンドにホスト名を使用することをサポートしていません。
TCP タイムスタンプを有効にすると、スロットリングやその他のパフォーマンスの問題が発生し、正常性プローブがタイムアウトする可能性があります。
Basic SKU のロード バランサーの正常性プローブは、仮想マシン スケール セットではサポートされていません。
セキュリティ上の問題により、HTTP プローブではポート 19、21、25、70、110、119、143、220、993 でのプローブはサポートされません。