正常性プローブ

[アーティクル]
08/12/2024

重要

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 は各配信元の待機時間を測定して維持します。

注意

1 つのエンドポイントが複数の配信元グループのメンバーである場合、Front Door は配信元に送信される正常性プローブの数を最適化して、配信元の負荷を軽減します。正常性プローブ要求は、構成されている最小のサンプル間隔に基づいて送信されます。すべての配信元グループのエンドポイントの正常性は、同じ正常性プローブからの応答によって判定されます。

正常性プローブの完全なエラー

配信元グループ内のすべての配信元に対して正常性プローブが失敗した場合、Front Door はすべての配信元が異常であると見なし、ラウンドロビンディストリビューションで配信元全体にトラフィックをルーティングします。

いずれかの配信元が正常な状態に戻ると、Front Door は通常の負荷分散アルゴリズムを再開します。

正常性プローブを無効にする

配信元グループにある配信元が 1 つの場合は、正常性プローブを無効にして、アプリケーションの負荷を減らすという選択肢もあります。配信元グループに複数の配信元があり、そのうちの 1 つ以上が有効な状態の場合、正常性プローブを無効にすることはできません。

Note

配信元グループに配信元が 1 つしかない場合、1 つの配信元の正常性プローブは非常に少なくなります。これにより、配信元の正常性メトリックが低下する可能性がありますが、トラフィックは影響を受けなくなります。

次のステップ

Azure Front Door プロファイルを作成する方法について学習します。
Front Door のルーティングアーキテクチャについて確認します。

次の方法で共有