正常性プローブ

  • [アーティクル]

重要

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 メソッドがサポートされています。

  1. GET: GET メソッドでは、Request-URI によって識別された情報 (エンティティ形式) がすべて取得されます。
  2. HEAD: HEAD メソッドは、サーバーの応答でメッセージ本文を返すことが禁止されているという点を除き、GET と同じです。 新しい Front Door プロファイルの場合、既定では、プローブ メソッドは HEAD に設定されます。

ヒント

配信元の負荷とコストを抑えるため、Front Door では正常性プローブに HEAD 要求の使用をお勧めします。

正常性プローブの応答

Responses 説明
正常性の判定 200 OK 状態コードは、配信元が正常であることを示します。 その他の状態コードは失敗と見なされます。 何らかの理由で有効な HTTP 応答がプローブに対して受信されない場合、そのプローブは失敗としてカウントされます。
待ち時間の測定 待ち時間は、プローブ要求が送信される直前の瞬間から、Front Door で応答の最終バイトが受信される瞬間までの実時間です。 Front Door では、要求ごとに新しい TCP 接続が使用されます。 測定では、既存のウォーム接続を持つ配信元への偏りはありません。

Front Door による配信元の正常性判定方法

Azure Front Door では、すべてのアルゴリズムで 3 段階のプロセスを使用して正常性を判定します。

  1. 無効な配信元を除外します。

  2. 正常性プローブ エラーが発生した配信元を除外します。

    • この選択は、最後の n 個の正常性プローブ応答を調べることによって行われます。 少なくとも x 個以上が正常であれば、配信元は正常であると見なされます。

    • n を構成するには、負荷分散設定の SampleSize プロパティを変更します。

    • x を構成するには、負荷分散設定の SuccessfulSamplesRequired プロパティを変更します。

  3. 配信元グループ内にある正常な配信元のセットの場合、Front Door は各配信元の待機時間を測定して維持します。

注意

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

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

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

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

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

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

次のステップ