次の方法で共有


配信元へのトラフィック ルーティング方法

重要

Azure Front Door (クラシック) は、2027 年 3 月 31 日に廃止されます。 サービスの中断を回避するには、2027 年 3 月までに Azure Front Door の Standard または Premium レベルに Azure Front Door (クラシック) プロファイルを移行することが重要です。 詳細については、Azure Front Door (クラシック) の廃止に関するページを参照してください。

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

Note

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

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

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

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

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

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

Note

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

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

Note

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 環境は、配信元の待機時間を個別に測定するため、さまざまな場所にいる各ユーザーは、自分の具体的な環境に最適なパフォーマンスを提供する配信元にルーティングされます。

Note

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

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

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

組織は多くの場合、高可用性を確保するために、プライマリ サービスが失敗した場合に引き継ぎを行うバックアップ サービスをデプロイします。 このセットアップは、アクティブ/スタンバイまたはアクティブ/パッシブ デプロイと呼ばれます。 Azure Front Door の "優先度" によるトラフィック ルーティング方法は、このフェールオーバー パターンを効果的に実装することを可能にします。

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

配信元の優先順位の構成

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

加重トラフィック ルーティング方法

"重み付け" によるトラフィック ルーティング方法では、事前定義された重みに基づいてトラフィックを分配できます。

この方法では、Azure Front Door 配信元グループ内の各配信元に重みを割り当てます。 この重みは 1 から 1000 の整数であり、既定値は 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 は ASLBSA および ASLBSACORS という名前の Cookie をユーザーのセッションに追加します。 これらの Cookie は、異なるユーザーが同じ IP アドレスを共有している場合でも、それらのユーザーを区別するのに役立ち、配信元間でトラフィックをより均等に分配することを可能にします。

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

Note

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

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

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

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

次のステップ