オリジンへのトラフィック ルーティング方法

適用対象: ✔️ Front Door Standard ✔️ Front Door Premium ✔️ Front Door (クラシック)

重要

Azure Front Door (クラシック) では、プロファイルの作成、新しいドメインオンボード、またはマネージド証明書はサポートされておらず、2027 年 31 月 31 日 で廃止されます。 サービスの中断を回避するには、Azure Front Door Standard または Premium に移行してください。 詳細については、「Azure Front Door (クラシック) の提供終了を参照してください。

Azure Front Door では、HTTP/HTTPS トラフィックをさまざまな配信元に分配する方法を管理するための 4 つのトラフィック ルーティング方法がサポートされています。 ユーザー要求が Front Door のエッジに到達すると、構成されているルーティング方法によって、要求が最適なバックエンド リソースに転送されるようになっています。

この記事において、"配信元" とはバックエンドを指し、"配信元グループ" とは Azure Front Door (クラシック) 構成内のバックエンド プールを指します。

次の 4 つのトラフィック ルーティング方法があります。

  • 待機時間: 許容される感度範囲内の待機時間が最も短い配信元に要求をルーティングし、ネットワーク待機時間の観点から最も近い配信元に要求が送信されるようにします。

  • 優先度: 配信元に対して優先度を設定し、すべてのトラフィックを処理するプライマリ配信元と、プライマリが利用できなくなった場合のためのセカンダリ配信元をバックアップとして指定することができます。

  • 重み付け: 各配信元に重みを割り当てて、トラフィックを均等に、または指定された重み係数に従って分配します。 トラフィックが重みの値に基づいて分配されるのは、配信元の待機時間が許容される感度範囲内にある場合です。

  • セッション アフィニティ: フロントエンド ホストまたはドメインのセッション アフィニティを構成することで、同じエンド ユーザーからの要求が同じ配信元に送信されることを保証します。

Azure Front Door Standard および Premium レベルにおいて、エンドポイント名とは、Azure Front Door (クラシック) でのフロントエンド ホストのことを指しています。

Front Door のすべての構成には、バックエンドの正常性監視と自動のグローバル フェールオーバーが含まれています。 詳細については、Front Door のバックエンド監視に関する記事を参照してください。 Azure Front Door では、アプリケーションのニーズに基づいて、1 つのルーティング方法を使用することも、複数の方法を組み合わせて最適なルーティング トポロジを作成することもできます。

Front Door ルール エンジンを使用すると、Azure Front Door Standard レベルと Premium レベルのルート構成をオーバーライドしたり、要求の Azure Front Door (クラシック) のバックエンド プールをオーバーライドしたりするルールを構成できます。 ルール エンジンによって設定された配信元グループまたはバックエンド プールは、この記事で説明するルーティング プロセスをオーバーライドします。

全体的な意思決定フロー

次の図は、全体的な決定フローを示しています。

Azure Front Door の優先度、待機時間、重みの設定に基づいて配信元がどのように選択されるかを説明する図。

決定手順は次のとおりです。

  1. 利用可能な配信元: 有効かつ正常性プローブ上で正常 (200 OK) であるすべての配信元を選択します。
    • 例: 6 つの配信元 A、B、C、D、E、F があり、C が異常で、E が無効な場合、利用可能な配信元は A、B、D、F です。
  2. 優先度: 利用可能なものから最も優先度の高い配信元を選択します。
    • 例: 配信元 A、B、D が優先度 1 を持ち、配信元 F が優先度 2 を持つ場合、選択される配信元は A、B、D となります。
  3. 遅延シグナル (正常性プローブに基づく): リクエストが到達した Front Door 環境で、許容される遅延範囲内のオリジンを選択します。 この範囲は、オリジングループの遅延感度設定と、最も近いオリジンの遅延に基づいています。
    • 例: 配信元 A に対する待機時間が 15 ミリ秒、B が 30 ミリ秒、D が 60 ミリ秒であり、待機時間感度が 30 ミリ秒に設定されている場合、D は 30 ミリ秒の範囲を超えるため、選択される配信元は A と B になります。
  4. 重み: 指定された重みの比率に基づいて、最終的に選択された配信元間でトラフィックを分配します。
    • 例: 配信元 A の重みが 3 で、配信元 B の重みが 7 である場合、トラフィックは 3/10 が配信元 A に、7/10 が配信元 B に分配されます。

セッション アフィニティを有効にした場合、セッションの最初の要求は、前に説明したフローに従います。 後続の要求は、最初の要求で選択された配信元に移動します。

最低遅延に基づくトラフィック ルーティング

複数のグローバルな場所に配信元をデプロイすると、エンド ユーザーに "最も近い" 配信元にトラフィックをルーティングすることで、アプリケーションの応答性を向上させることができます。 待機時間によるルーティング方法は、Azure Front Door 構成の既定値です。 この方法は、最も近い地理的な場所ではなく、ネットワーク待機時間が最も短い配信元にユーザー要求を送信し、最適なパフォーマンスを確保します。

Azure Front Door のエニーキャスト アーキテクチャは、待機時間によるルーティング方法との組み合わせによって、各ユーザーが自身の場所に基づいて最高のパフォーマンスを得られることを保証します。 各 Front Door 環境は、配信元の待機時間を個別に測定するため、さまざまな場所にいる各ユーザーは、自分の具体的な環境に最適なパフォーマンスを提供する配信元にルーティングされます。

既定では、待機時間感度プロパティは 0 ミリ秒に設定されます。 この設定では、要求は常に利用可能な中で最速の配信元に転送されます。 配信元の重みが効果を発揮するのは、2 つの配信元が同じネットワーク待機時間を持つ場合だけです。

詳細については、「Azure Front Door のルーティング アーキテクチャ」を参照してください。

優先順位に基づくトラフィック ルーティング

高可用性を確保するには、プライマリ サービスが失敗した場合に引き継ぐバックアップ サービスをデプロイします。 このセットアップは、アクティブ/スタンバイまたはアクティブ/パッシブ デプロイと呼ばれます。 Azure Front Doorの優先順位トラフィック ルーティング方法は、このフェールオーバー パターンの実装に役立ちます。

既定では、Azure Front Door は、最も優先度の高い (優先度値が低い) 配信元にトラフィックをルーティングします。 これらのプライマリ配信元が利用不可能になった場合、トラフィックは (優先度値が次に低い) セカンダリ配信元にルーティングされます。 プライマリとセカンダリの両方の配信元が利用できない場合、このプロセスは 3 番目の配信元を使用して続行されます。 正常性プローブは、構成された状態と正常性に基づいて、配信元の可用性を監視します。

配信元の優先順位の構成

Azure Front Door配信元グループ内の各配信元には Priority プロパティがあり、1 から 5 の値に設定できます。 値が小さい場合は、優先度が高いことを示します。 複数の配信元で同じ優先度値を共有することができます。

重み付きトラフィック ルーティング方式

RPS (1 秒あたりの要求数) が非常に少ないお客様の場合、分散された AFD の POP とマシンの特性上、Azure Front Door では、設定した重みが厳密に反映されることを保証できないため、負荷分散が偏って見える場合があります。

重み付けトラフィック ルーティング方法は、定義済みの重みに基づいてトラフィックを分散します。

この方法では、Azure Front Door 配信元グループ内の各配信元に重みを割り当てます。 重みは 1 ~ 1,000 の整数で、既定値は 50 です

配信元が許容可能な待機時間の感度を満たしている場合、指定された重み比に基づくラウンド ロビン メカニズムを使用して、使用可能な配信元間でトラフィックが分散されます。 待機時間の感度を 0 ミリ秒に設定した場合、重みは、2 つの配信元のネットワーク待機時間が同じ場合にのみ有効になります。

重み付けによる方法は、以下のようないくつかのシナリオをサポートしています。

  • アプリケーションの段階的なアップグレード: 一定の割合のトラフィックを新しい配信元にルーティングし、時間をかけてそれを徐々に増加させます。
  • Azure へのアプリケーション移行: Azure と外部の配信元の両方を含む配信元グループを作成します。 新しい配信元を優先するように重みを調整し、それらによってほとんどのトラフィックが処理されるようになるまでトラフィックの割合を徐々に増やした後、優先度の低い配信元を無効にして削除します。
  • 容量を増加させるためのクラウド バースト: 配信元を追加または有効にし、トラフィック分散を指定することで、オンプレミスのデプロイをクラウドに拡張します。

セッションアフィニティ

既定では、Azure Front Door は同じクライアントからの要求を異なる配信元に転送します。 しかし、セッション アフィニティは、ステートフル アプリケーションや同じユーザーからの後続の要求を同じ配信元で処理する必要があるシナリオで役に立ちます。 この機能は、ユーザーのセッションを同じ配信元が処理することを保証し、クライアント認証などのシナリオで役に立ちます。

Azure Front Door は、Cookie ベースのセッション アフィニティを使用し、識別子として配信元 URL の SHA256 を使用するマネージド Cookie が使用されます。 このメソッドは、ユーザー セッションから同じ配信元に後続のトラフィックを転送します。

セッション アフィニティは、Azure Front Door Standard レベルと Premium レベルの配信元グループ レベル、および構成されたドメインまたはサブドメインごとに Azure Front Door (クラシック) のフロントエンド ホスト レベルで有効にすることができます。 この機能を有効にすると、Azure Front Door はユーザーのセッションに ASLBSAASLBSACORS という名前の Cookie を追加します。 これらの Cookie は、同じ IP アドレスを共有している場合でも、異なるユーザーを識別するのに役立ちます。これにより、配信元間でトラフィックをより均等に分散できます。

Front Door は現在のところ、セッション Cookie しかサポートしていないため、Cookie の有効期間はユーザーのセッションと一致します。

ブラウザー セッション Cookie は、ドメイン レベルでセッション アフィニティを維持します。 同じワイルドカード ドメインの下にあるサブドメインがセッション アフィニティを共有できるのは、ユーザーのブラウザーが同じ配信元リソースに対して要求を送信する場合だけです。

セッションを確立するには Front Door が応答にセッション アフィニティ Cookie を追加する必要があるため、パブリック プロキシがセッション アフィニティを妨げる可能性があります。 応答がキャッシュ可能な場合、同じリソースを要求する他のクライアントの Cookie が中断されるため、このアクションは実行できません。 この問題を回避するために、配信元 キャッシュ可能な応答を送信する場合、セッション アフィニティは確立されません。 セッションが既に確立されている場合、応答のキャッシュ可能性は関係ありません。

セッション アフィニティは、キャッシュ不可能な標準的なシナリオ以外の次の状況で確立されます。

  • 応答には、no-store を含む Cache-Control ヘッダーが含まれています。
  • 応答に有効な Authorization ヘッダーが含まれている。
  • 応答は、HTTP 302 状態コードです。

次のステップ