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

  • [アーティクル]

重要

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) を返すすべての配信元を選択します。
    • 例: A、B、C、D、E、F の 6 つの配信元があり、その中で C は異常、E は無効であるとします。 この場合、使用可能な配信元のリストは、A、B、D、F です。
  2. 優先順位: 使用可能なものの中で優先順位が最も高い配信元が選択されます。
    • 例: 配信元 A、B、D は優先順位 1、配信元 F は優先順位 2 であるとします。 その場合、選ばれる配信元は A、B、D になります。
  3. 待機時間シグナル (正常性プローブに基づく): 要求が到着した Front Door 環境から、許容範囲内の配信元を選択します。 このシグナルは、配信元グループの待機時間感度設定と、より近い配信元の待機時間に基づいています。
    • 例: Front Door で、要求が到着する環境から配信元 A までの待機時間が 15 ミリ秒と測定されたのに対し、B の待機時間が 30 ミリ秒、D が 60 ミリ秒だとします。 待機時間感度が 30 ミリ秒に設定されている場合、最低遅延プールは配信元 A と B で構成されます。なぜなら、D は最も近い配信元つまり A から 30 ミリ秒より大きく離れているためです。
  4. 重み: 最後に、Azure Front Door は、指定された重みの比率で、最終的に選ばれた配信元のグループ間でトラフィックをラウンド ロビンします。
    • "例: 配信元 A の重みが 3、配信元 B の重みが 7 である場合、トラフィックは 3/10 が配信元 A に、7/10 が配信元 B に分配されます。"

セッション アフィニティが有効になっている場合、セッションの最初の要求は上記のフローに従います。 後続の要求は、最初の要求で選択された配信元に送信されます。

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

世界中の複数の場所に配信元をデプロイすると、エンド ユーザーに "最も近い" 宛先にトラフィックをルーティングすることで、アプリケーションの応答性を向上させることができます。 待機時間は、Front Door 構成の既定のトラフィック ルーティング方法です。 このルーティング方法では、エンド ユーザーから Azure Front Door の背後にある最も近い配信元に要求を転送します。 このルーティング メカニズムを Azure Front Door のエニーキャスト アーキテクチャと組み合わせると、各エンド ユーザーが場所に基づいて最高のパフォーマンスを得ることができます。

"最も近い" 配信元が必ずしも地理的な距離で最も近いとは限りません。 Azure Front Door は、ネットワーク待機時間を測定して、最も近い配信元を決定します。 詳細については、Azure Front Door のルーティング アーキテクチャを参照してください。

各 Front Door 環境では、配信元の待機時間が個別に測定されます。 つまり、異なる場所のユーザーは、それぞれその環境に最適なパフォーマンスで配信元にルーティングされます。

Note

既定では、待機時間感度プロパティは 0 ミリ秒に設定されます。 この設定では、要求は常に最速の利用可能な配信元に転送され、配信元の重みは、2 つの配信元が同じネットワーク待機時間を使用しない限り有効になりません。

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

多くの場合、組織ではサービスの高可用性を提供したいと考えており、主要なサービスがダウンした場合に備えて複数のバックアップ サービスをデプロイすることでこれを実行しています。 業界では、このトポロジの種類はアクティブ/スタンバイまたはアクティブ/パッシブのデプロイとも呼ばれます。 "優先順位" トラフィック ルーティング方法を使用すると、このフェールオーバー パターンを簡単に実装できます。

既定の Azure Front Door には、優先順位が等しい配信元のリストが含まれています。 既定では、Azure Front Door は配信元のプライマリ セットとして、優先順位が最も高い (最も小さい値) 配信元に対してのみ、トラフィックを送信します。 プライマリの配信元が使用できない場合、Azure Front Door は配信元のセカンダリ セット (2 番目に小さい値) にトラフィックをルーティングします。 プライマリとセカンダリのどちらの配信元も使用できない場合、トラフィックは 3 番目のバックエンドに送信されます。以降も同様です。 配信元の可用性は、構成された状態と、正常性プローブによって決定される継続している配信元の正常性状態に基づきます。

配信元の優先順位の構成

Azure Front Door 構成の配信元グループの各配信元は、"優先順位" と呼ばれるプロパティを持っていて、設定できる値は 1 から 5 です。 Azure Front Door では、各配信元のこのプロパティを使用して、配信元の優先順位を明示的に構成できます。 このプロパティの値の範囲は、1 から 5 です。 数値が小さいほど優先順位が高くなります。 配信元は同じ優先順位の値を共有できます。

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

"重み付け" トラフィック ルーティング方法を使うと、トラフィックを均等に分散したり、事前定義された重み付けを使ったりできます。

重み付けトラフィック ルーティング方法では、配信元グループの Azure Front Door の構成で各配信元に重みを割り当てます。 重みは 1 から 1000 の範囲の整数です。 このパラメーターの既定の重みは 50 です。

許容される待機時間感度の使用可能な配信元のリストで、トラフィックは指定された重みの比率を使用してラウンドロビン方式で分散されます。 待機時間感度が 0 ミリ秒に設定されている場合、同じネットワーク待機時間の配信元が複数存在しない限り、このプロパティは反映されません。

重み付け方式を使用することで、有用なシナリオをいくつか実現できます。

  • アプリケーションの段階的アップグレード: 新しい配信元にルーティングするトラフィックのパーセンテージを指定し、他の配信元と同等になるまで、トラフィックを時間と共に段階的に増やします。
  • Azure へのアプリケーション移行: Azure と外部の配信元の両方を含む配信元グループを作成します。 配信元の重みを調整して新しい配信元を優先します。 最初に新しい配信元を無効に設定し、次に最低の重みを割り当て、少しずつ増やしながらほとんどのトラフィックを受け取るレベルまで段階的に上げることができます。 最後に優先順位の低い配信元を無効にして、グループから削除します。
  • 追加容量のクラウド バースト: Front Door に対応させることで、オンプレミスのデプロイをクラウドにすばやく拡張します。 クラウドに追加容量が必要なときに、配信元を追加または有効にして、各配信元に送るトラフィックの割り当てを指定できます。

セッション アフィニティ

既定では、セッション アフィニティを使用しない場合、Azure Front Door は同じクライアントからの要求を別の配信元に転送します。 特定のステートフルなアプリケーションや、同じユーザーからの要求が続く特定のシナリオでは、最初の要求を処理したのと同じ配信元が優先されます。 Cookie ベースのセッション アフィニティ機能は、同じ配信元上にユーザー セッションを保持する場合に便利です。 配信元の URL の SHA256 で、マネージド Cookie を Cookie の識別子として使用すると、Azure Front Door は後続のトラフィックをユーザー セッションから、処理のために同じ配信元に送ることができます。

構成されている各ドメイン (またはサブドメイン) に対して、Azure Front Door Standard および Premium レベルの配信元グループ レベルと、Azure Front Door (クラシック) のフロントエンド ホスト レベルで、セッション アフィニティを有効にすることができます。 有効にすると、Azure Front Door はユーザーのセッションに Cookie を追加します。 Cookie は ASLBSA と ASLBSACORS と呼ばれます。 Cookie ベースのセッション アフィニティでは、Front Door は同じ IP アドレスの背後にある場合でも異なるユーザーを識別することができ、それにより異なる配信元間でトラフィックをより均等に分散できます。

現在 Front Door はセッション Cookie のみをサポートしているので、Cookie の有効期間はユーザーのセッションと同じです。

Note

セッション アフィニティは、構成されている場所に関係なく、ドメイン レベルでブラウザー セッション Cookie を通じて記憶されます。 同じユーザー ブラウザーが同じ配信元リソースに対して要求を送信する限り、同じワイルドカード ドメインの下にあるサブドメインは、セッション アフィニティを共有できます。

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

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

  • 応答には、Cache-Controlストアなしのヘッダー を含める必要があります。
  • 応答に Authorization ヘッダーが含まれている場合は、期限切れにならないようにしてください。
  • 応答は、HTTP 302 状態コードです。

次のステップ