正常性プローブ
重要
Azure Front Door (クラシック) は、2027 年 3 月 31 日に廃止されます。 サービスの中断を回避するには、2027 年 3 月までに Azure Front Door の Standard または Premium レベルに Azure Front Door (クラシック) プロファイルを移行することが重要です。 詳細については、Azure Front Door (クラシック) の廃止に関するページを参照してください。
Note
この記事の "配信元" と "配信元グループ" は、Azure Front Door (クラシック) 構成のバックエンドとバックエンド プールを指します。
それぞれの Front Door プロファイルでは、特定の Azure Front Door 環境の各配信元の正常性と近接性を判定するために、構成されているすべての配信元に対して、合成 HTTP/HTTPS 要求を定期的に送信します。 Front Door は、正常性プローブからの応答を使用して、クライアント要求のルーティング先として "最適な" 配信元を判定します。
警告
Azure Front Door の各エッジ ロケーションが正常性プローブを配信元に送信しているため、配信元に対する正常性プローブの量が多くなる可能性があります。 プローブの数は、顧客のトラフィックの場所と、正常性プローブの頻度によって異なります。 Azure Front Door のエッジ ロケーションがエンド ユーザーから実際のトラフィックを受信しない場合、エッジ ロケーションからの正常性プローブの頻度は、構成された頻度より少なくなります。 すべての Azure Front Door のエッジ ロケーションに対するトラフィックがある場合、正常性プローブの頻度によっては、正常性プローブの量が多くなることがあります。
デフォルト プローブ頻度の 30 秒を使用した場合に、配信元への 1 分あたりの正常性プローブ量を大まかに見積もる例を示します。 各配信元のプローブ量は、1 分あたり 2 つの要求数とエッジ ロケーション数を掛け算した結果と等しくなります。 すべてのエッジ ロケーションにトラフィックが送信されない場合、プローブ要求は少なくなります。 エッジ ロケーションの一覧については、リージョン別のエッジ ロケーションをご覧ください。
サポートされるプロトコル
Azure Front Door では、HTTP または HTTPS プロトコルを使用したプローブの送信をサポートしています。 これらのプローブは、クライアント要求のルーティング用に構成された同じ TCP ポートを介して送信され、オーバーライドすることはできません。 Front Door HTTP/HTTPS プローブは、Edge Health Probe という値の User-Agent ヘッダー セットと共に送信されます。
正常性プローブでサポートされている HTTP メソッド
Azure Front Door では、正常性プローブを送信するための次の HTTP メソッドがサポートされています。
- GET: GET メソッドでは、Request-URI によって識別された情報 (エンティティ形式) がすべて取得されます。
- HEAD: HEAD メソッドは、サーバーの応答でメッセージ本文を返すことが禁止されているという点を除き、GET と同じです。 新しい Front Door プロファイルの場合、既定では、プローブ メソッドは HEAD に設定されます。
ヒント
配信元の負荷とコストを抑えるため、Front Door では正常性プローブに HEAD 要求の使用をお勧めします。
正常性プローブの応答
| Responses | 説明 |
|---|---|
| 正常性の判定 | 200 OK 状態コードは、配信元が正常であることを示します。 その他の状態コードは失敗と見なされます。 何らかの理由で有効な HTTP 応答がプローブに対して受信されない場合、そのプローブは失敗としてカウントされます。 |
| 待ち時間の測定 | 待ち時間は、プローブ要求が送信される直前の瞬間から、Front Door で応答の最終バイトが受信される瞬間までの実時間です。 Front Door では、要求ごとに新しい TCP 接続が使用されます。 測定では、既存のウォーム接続を持つ配信元への偏りはありません。 |
Front Door による配信元の正常性判定方法
Azure Front Door では、すべてのアルゴリズムで 3 段階のプロセスを使用して正常性を判定します。
無効な配信元を除外します。
正常性プローブ エラーが発生した配信元を除外します。
この選択は、最後の n 個の正常性プローブ応答を調べることによって行われます。 少なくとも x 個以上が正常であれば、配信元は正常であると見なされます。
n を構成するには、負荷分散設定の SampleSize プロパティを変更します。
x を構成するには、負荷分散設定の SuccessfulSamplesRequired プロパティを変更します。
配信元グループ内にある正常な配信元のセットの場合、Front Door は各配信元の待機時間を測定して維持します。
Note
1 つのエンドポイントが複数の配信元グループのメンバーである場合、Front Door は配信元に送信される正常性プローブの数を最適化して、配信元の負荷を軽減します。 正常性プローブ要求は、構成されている最小のサンプル間隔に基づいて送信されます。 同じ正常性プローブからの応答によって、すべての配信元グループのエンドポイントの正常性が判定されます。
起動時間の長いコンテナーのプローブ設定の調整
起動時間の長いコンテナーを処理する場合、プローブの設定を調整することで、早期障害を防ぐことができます。
ProbeTimeout と Interval の値を大きくすると、コンテナーを起動してから Front Door によって異常としてマークされるまでの時間を伸ばすことができます。
起動時間の長いコンテナーの値
- ProbeTimeout: タイムアウト期間を 10 から 30 秒に増やします。
- Interval: プローブ間で長い間隔 (30 から 60 秒など) を設定します。
- UnhealthyThreshold: コンテナーが異常と見なされるまでに、連続して失敗したプローブの数を増やします (たとえば、3 から 5 回の再試行)。
Note
ProbeTimeout、Interval、UnhealthyThreshold に示した値は、サンプルの範囲であり、例を示すためのものです。 これらの値は、特定のコンテナーの起動動作と要件に基づいて調整できます。
Note
これらを変更すると、実際の障害が起きたときに、検出されるのが遅くなる可能性があるため、コンテナーの起動動作に応じてこれらの値のバランスを慎重に調整してください。
コンテナー ライフサイクル フェーズ中のプローブの相互作用
コンテナーの開始フェーズ: このフェーズでは、コンテナーがトラフィックを処理する準備ができていない可能性があります。 正常性プローブは、コンテナーが応答していないことを検出するのに役立ちます。その場合、特定の HTTP 状態コード (たとえば、
200 OK) を確認できます。 プローブの頻度が高すぎたり、タイムアウトが短すぎたりすると、コンテナーは初期化前に異常としてマークされます。 このフェーズにおけるプローブのタイムアウトまたは間隔を増やします。実行中フェーズ: コンテナーが実行されると、プローブは正常性応答のチェックを続行します。 正常性チェックで一貫して
200 OKが返される場合、Front Door は配信元を引き続きトラフィックのローテーションに含めます。 プローブが失敗し続ける場合 (コンテナーのクラッシュが原因など)、Front Door は配信元を異常としてマークします。障害フェーズ: 構成されたしきい値 (たとえば、
UnhealthyThreshold) に対して正常性プローブが失敗した場合、配信元は異常と見なされ、トラフィックは他の正常な配信元にルーティングされます。
正常性プローブの完全なエラー
配信元グループ内のすべての配信元に対して正常性プローブが失敗した場合、Front Door はすべての配信元が異常であると見なし、ラウンド ロビン ディストリビューションで配信元全体にトラフィックをルーティングします。
いずれかの配信元が正常な状態に戻ると、Front Door は通常の負荷分散アルゴリズムを再開します。
正常性プローブを無効にする
配信元グループにある配信元が 1 つの場合は、正常性プローブを無効にして、アプリケーションの負荷を減らすという選択肢もあります。 配信元グループに複数の配信元があり、そのうちの 1 つ以上が有効な状態の場合、正常性プローブを無効にすることはできません。
Note
配信元グループに配信元が 1 つしかない場合、正常性プローブは少なくなります。 これにより、配信元の正常性メトリックが低下する可能性がありますが、トラフィックは影響を受けなくなります。
次のステップ
- Azure Front Door プロファイルを作成する方法について学習します。
- Front Door のルーティング アーキテクチャについて確認します。