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