要求とルート構成のマッチング方法

  • [アーティクル]

Azure Front Door では、受信要求が Azure Front Door エッジに到着したときのトラフィックの処理方法が "ルート" によって定義されます。 ルート設定を使用して、ドメインと配信元グループとの間の関連付けが定義されます。 "一致させるパターン" や "ルール セット" などの高度な機能を使用することで、バックエンド リソースへのトラフィックを細かく制御できます。

注意

Front Door ルール セットを使用する場合は、要求の配信元グループをオーバーライドするルールを構成できます。 ルール セットによって設定される配信元グループによって、この記事で説明しているルーティング処理がオーバーライドされます。

重要

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

Azure Front Door (クラシック) エッジに要求が到着したとき、Front Door が最初に行うことの 1 つは、マッチする要求をバックエンド リソースにルーティングし、ルーティング構成で定義されたアクションを実行する方法を決定することです。 以下のドキュメントは、要求の処理において、Front Door がどのルート構成を使用するかを判断する方法について説明します。

Front Door のルート構成の構造

Front Door のルーティング規則は、大きく分けて "左側" と "右側" の 2 つの部分から成っています。 受信要求はルートの左側とマッチングされます。一方、その要求をどう処理するかは右側で定義されます。

着信の照合 (左側)

以下のプロパティにより、着信要求がルーティング規則 (または左側) と一致するかどうかが判断されます。

  • HTTP プロトコル (HTTP または HTTPS)
  • ドメイン (例: www.foo.com、*.bar.com)
  • パス (例: /*、/users/*、/file.gif)

これらのプロパティは、内部で展開されているので、Protocol/Domain/Path のすべての組み合わせがマッチングの対象となります。

ルーティングの決定 (右側)

要求の処理方法は、ルートに対してキャッシュが有効になっているかどうかで決まります。 キャッシュされた応答を使用できない場合、要求は適切な配信元に転送されます。

ルートの照合

このセクションでは、Front Door によるルーティング規則のマッチング方法について説明します。 基本的な概念は、Front Door は必ず、まず "左側" のみを見て、最も具体的な要求をマッチングするということです。 マッチングはまずプロトコルに基づいて行われ、次にドメインに、そして最後にパスに基づいて行われます。

フロント エンド ホストの照合

Azure Front Door がフロントエンド ホストをマッチングする際には、次のロジックが使用されます。

  1. フロントエンド ホストに完全一致するルートがあるかどうかを確認します。
  2. 完全に一致するフロントエンド ホストがない場合、要求は拒否され、400 (無効な要求) エラーが送信されます。

次の表には、3 つの異なるルーティング規則が、フロントエンド ホストおよびパスと共に示されています。

ルーティング ルール フロント エンド ホスト Path
A foo.contoso.com /*
B foo.contoso.com /users/*
C www.fabrikam.com、foo.adventure-works.com /*、/images/*

次の表は、上記のルーティング規則のマッチング結果を示しています。

着信のフロント エンド ホスト 一致するルーティング規則
foo.contoso.com A、B
www.fabrikam.com C
images.fabrikam.com Error 400: 正しくない要求
foo.adventure-works.com C
contoso.com Error 400: 正しくない要求
www.adventure-works.com Error 400: 正しくない要求
www.northwindtraders.com Error 400: 正しくない要求

Path の照合

Front Door によって特定のフロントエンド ホストが決定され、候補となるルーティング規則がフィルターで抽出された後、要求されたパスに基づいてルーティング規則が選択されます。 要求パスは、フロントエンド ホストと同様のロジックを使用してマッチングされます。

  1. 要求パスと完全に一致するルーティング規則があるかどうかを判断します。
  2. 完全に一致するパスがない場合、Front Door は一致するワイルドカード パスを持つルーティング規則を検索します。
  3. 一致するパスでルーティング規則が見つからない場合、要求は拒否され、400 (無効な要求) エラーが送信されます。

Note

ワイルドカード文字 * は、その後に他の文字がないパスでのみ有効です。 さらに、ワイルドカード文字 * の前にスラッシュ / を付ける必要があります。 ワイルドカードがないパスは、完全一致のパスとみなされます。 スラッシュ / で終わるパスも完全一致パスです。 エラーを回避するには、パスがこれらの規則に従うようにします。

Note

  • ワイルドカードがないパスはすべて完全一致のパスと見なされます。 / で終わるパスは完全一致と見なされます。
  • パスに一致するパターンでは大文字と小文字が区別されません。つまり、大文字と小文字が異なるパスは重複として扱われます。 たとえば、パスが /FOO および /foo で同じプロトコルを使用する同じホストがあるとします。 これらのパスは重複と見なされ、[一致するパターン] 設定では許可されません。

次の表は、ルーティング規則、フロントエンド ホスト、およびパスの組み合わせの一覧です。

ルーティング ルール フロントエンド ホスト Path
A www.contoso.com /
B www.contoso.com /*
C www.contoso.com /ab
D www.contoso.com /abc
E www.contoso.com /abc/
F www.contoso.com /abc/*
G www.contoso.com /abc/def
H www.contoso.com /path/

次の表は、受信要求が Front Door エッジに到着したときにマッチングされるルーティング規則を示しています。

着信要求 一致するルート
www.contoso.com/ A
www.contoso.com/a B
www.contoso.com/ab C
www.contoso.com/abc D
www.contoso.com/abzzz B
www.contoso.com/abc/ E
www.contoso.com/abc/d F
www.contoso.com/abc/def G
www.contoso.com/abc/defzzz F
www.contoso.com/abc/def/ghi F
www.contoso.com/path B
www.contoso.com/path/ H
www.contoso.com/path/zzz B

警告

キャッチオール ルートの Path (/*) でフロント エンド ホストと完全に一致するルーティング規則が存在しない場合、いずれのルーティング規則とも一致しません。

構成の例

ルート Host Path
A profile.contoso.com /api/*

照合テーブル

着信要求 一致するルート
profile.domain.com/other [なし] : Error 400: 正しくない要求

ルーティングの決定

マッチするルーティング規則が 1 つ見つかった場合、Front Door は、次にその要求の処理方法を選択する必要があります。 一致したルーティング規則に対して使用できるキャッシュ応答が Azure Front Door にある場合、要求は処理されてクライアントに返されます。

最後に、一致したルーティング規則用に構成されたルール セットがあるかどうかが評価されます。 ルール セットが定義されていない場合、要求は変更されることなく配信元グループに転送されます。 それ以外の場合は、構成されている順序でルール セットが処理されます。 ルール セットは、ルートをオーバーライドして、トラフィックを特定の配信元グループに強制的に振り向けることができます。

Front Door (クラシック) に、一致したルーティング規則に対するキャッシュされた応答が存在しない場合は、一致したルーティング規則に対して URL 書き換えが構成されているかどうかが評価されます。 カスタム転送パスがない場合、その要求は変更されることなく、構成されたバックエンド プール内の適切なバックエンドに転送されます。 カスタム転送パスが定義されている場合、その要求パスは、定義されたカスタム転送パスに従って更新された後、バックエンドに転送されます。

次のステップ