サービスルートを構成する

メディア CDN は、トラフィックを特定のエッジ構成と送信元にきめ細かいレベルでマッピングできる高度な HTTP ルーティング機能を提供します。

ルートルールを構成する

Media CDN サービスのルートルールを構成します。

一致したリクエスト数

Media CDN 構成には、EdgeCacheService リソースのルーティングセクションで定義されるルートのセットが含まれます。このルートは（少なくとも）ホストに基づいてリクエストと一致します。トラフィックがオリジンに転送される方法の詳細については、HostRule と PathMatcher をご覧ください。各ルートでは、独自の CDN 構成、書き換え、リダイレクト、CORS ポリシー、カスタム HTTP ヘッダー、送信元マッピングを定義できます。 ルートはオリジンを共有できます。

たとえば、マニフェストに対するリクエストを特定の送信元にルーティングし、有効期間が短いキャッシュ TTL とネガティブ キャッシュ ポリシーを定義できます。ヘッダーとクエリ パラメータを使用して特定のマニフェスト タイプやユーザーを分割して、セグメントに対するリクエストを別の送信元に分割できます。

次の例は、ホスト media.example.com の特定のヘッダー、クエリ パラメータ、パス接頭辞に一致するリクエストをルーティングする方法を示しています。

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 10
      origin: staging-live-origin
      matchRules:
      - prefixMatch: /vod/
        headerMatches:
        - headerName: "x-staging-client"
          presentMatch: true
        queryParameterMatches:
        - name: "live"
          exactMatch: "yes"
      routeAction:
        cdnPolicy:
          defaultTtl: 5s

パスマッチング

Media CDN は、完全（正確な）マッチング、プレフィックス マッチング、ワイルドカード パス マッチングをサポートしています。 パス マッチングをホスト、ヘッダー、クエリ パラメータ ベースのマッチングと組み合わせて、きめ細かいリクエスト ルーティング ルールを構築できます。

URL パスでマッチングする方法は、次の 3 つです。

詳細については、MatchRule の API 仕様をご覧ください。

たとえば、/stream/ で始まるすべてのリクエストを照合するには、次のようなルートルールを作成します。

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    - *.vod.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 1
      matchRules:
      - prefixMatch: /stream/

この例では、一致ルールに末尾のスラッシュが明示的に含まれています。

• media.example.com/stream/id/1234/hls/manifest.m3u8 へのリクエストは、このルートと一致します。
• media.example.com/stream-eu/id/4567/hls/manifest.m3u8 へのリクエストがこのルートと一致しません。

2 番目のケースでは、別のルートまたはキャッチオール ルートが構成されていない限り、Media CDN は HTTP 404 エラーを返します。

類似した接頭辞を持つルートの優先順位の仕組みについては、ルートの優先度と順序指定をご覧ください。

パターン（ワイルドカード）のマッチング

パターン マッチングでは、ワイルドカード構文を使用して、部分的な URL や接尾辞（ファイル拡張子）など、URL の複数の部分を照合できます。

pathTemplateMatch フィールドで 1 つ以上のパスセグメントを名前付き変数に関連付けて、pathTemplateRewrite フィールドで URL を書き換える際にそれらの変数を参照することもできます。これにより、リクエストが送信元に送信される前に、URL セグメントの順序を変更して削除できます。

次の例は、2 つの異なる URL 接尾辞に対する照合方法を示しています。

# EdgeCacheService.routing.pathMatchers[]
    routeRules:
    - priority: 1
      description: "Match video segments"
      matchRules:
      - pathTemplateMatch: "/**.ts"
      - pathTemplateMatch: "/**.m4s"
      origin: prod-video-storage

サポートされている構文は次のとおりです。

注:

• URL を書き換えない場合は、よりシンプルな * 演算子と ** 演算子を使用します。
• 変数を使用してパスセグメントをキャプチャする場合、変数でキャプチャされない URL の部分は、後続の pathTemplateRewrite で参照できません。例については、パス変数のキャプチャのセクションをご覧ください。
• 同じルートの pathTemplateMatch に存在しない変数を、後続の pathTemplateRewrite で参照することはできません。
• 変数は大文字と小文字が区別され、{FORMAT}、{forMAT}、{format} は異なる変数と値を表します。
• 一致条件には最大 10 個の演算子（ワイルドカードまたは変数）を指定できます。pathTemplateMatch フィールドと pathTemplateRewrite フィールドは 255 文字を超えないようにしてください。

例: ファイル拡張子の一致

次の例は、ワイルドカード演算子の一般的なユースケース（接尾辞までのすべてのパス セグメントを照合する）を示しています。

この場合は、次の操作を行います。

• マニフェストのオリジンから .m3u8 と .mpd で終わる動画マニフェスト（プレイリスト）を取得し、これらのレスポンスには短い（5 秒）TTL を適用します。これは、これらのレスポンスが定期的に変更されるためです。
• セグメントの送信元から .ts と .m4s で終わる動画セグメントを取得し、これらのレスポンスに長い TTL（1 日）を適用します。

このアプローチは、SSAI（サーバーサイド広告挿入）または DAI（ダイナミック広告挿入）サービスを使用する場合や、マニフェストが数秒ごとに更新されるライブ動画でよく使用されます。

次の構成は、これをサポートするように Media CDN ルーティングを構成する方法を示しています。

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    # the first route only matches video manifests
    - priority: 1
      matchRules:
      - pathTemplateMatch: "/**.m3u8" # "**" matches all path segments
      - pathTemplateMatch: "/**.mpd"
      origin: manifest-origin
      routeAction:
        cdnPolicy:
          cacheMode: FORCE_CACHE_ALL
          defaultTtl: 5s
    # the second route matches video segments, fetches them
    # from a separate origin server, caching them for a longer
    # duration (1 day).
    - priority: 2
      matchRules:
      - pathTemplateMatch: "/**.ts"
      - pathTemplateMatch: "/**.m4s"
      origin: segment-origin
      routeAction:
        cdnPolicy:
          cacheMode: FORCE_CACHE_ALL
          defaultTtl: 86400s

例: パス変数をキャプチャする

次の例は、名前付き変数を使用して 1 つ以上のパス セグメントを記述する方法を示しています。

これらの変数は、pathTemplateRewrite で使用して、リクエストが送信元に送信される前にパスを書き換えるか、複雑な pathTemplateMatch を自己記述型にすることができます。

routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 1
      matchRules:
      # Matches a request of "/us/en/hls/123139139/segments/00001.ts"
      - pathTemplateMatch: "/{country}/{lang}/{format}/{id}/{file=**}"
      origin: my-origin
      routeAction:
        urlRewrite:
          # Rewrites to "/123139139/hls/segments/00001.ts"
          pathTemplateRewrite: "/{id}/{format}/{file}"

具体的な内容は以下のとおりです。

• 各 {name} 変数は 1 つのパスセグメントをキャプチャします。パスセグメントは、URL パスの /（スラッシュ）のペアの間のすべての文字です。
• {name=**} の変数は残りのすべてのパスセグメントをキャプチャします。この場合、segments/00001.ts と master.m3u8 の両方に一致します。
• 同じルートの pathTemplateRewrite で、pathTemplateMatch でキャプチャした変数の一部を参照します。{country} 変数と {lang} 変数は、オリジンのディレクトリ構造と一致しないため、明示的に省略します。

この例では、次のようになります。

• /us/en/hls/123139139/segment_00001.ts の受信リクエスト URL が pathTemplateMatch と一致し、送信元に送信される前に /123139139/hls/segment_00001.ts に書き換えられます。
• 受信リクエスト URL /us/123139139/master.m3u8 は pathTemplateMatch と一致せず、HTTP 404 (Not Found) ステータス コードを受信します。
• /br/es/dash/c966cbbe6ae3/subtitle_00001.vtt の受信リクエスト URL も pathTemplateMatch と一致し、送信元に送信される前に /c966cbbe6ae3/dash/subtitle_00001.vtt に書き換えられます。

ワイルドカード マッチングと URL の書き換えの相互運用の詳細については、書き換えのセクションをご覧ください。

ホスト マッチング

各サービスは複数のホスト名で照合できます。各ホスト名には、独自のルートグループ（パスマッチャー）が含まれています。最も一般的なケースでは、サービスのすべてのホスト名が、単一のホストリストと単一のパスマッチャーを含む単一の共有ルートセットにマッピングされます。

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    - *.vod.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    # list of routes for the configured hosts
    - priority: 999
      matchRules:
      - prefixMatch: /
      origin: DEFAULT_ORIGIN

一致しないホストには、デフォルトの HTTP 404 ページが配信されます。任意のホストを受け入れるには、hostRules[].hosts[] エントリとしてワイルドカード文字 * を含めます。

ルートのグループ（国別、ライブ動画とオンデマンド動画の比較など）を定義することもできます。各サービスには 1 つのセキュリティ ポリシーがあるため、通常は、マーケット（地域）またはワークロードごとに 1 つのサービスを用意することをおすすめします。

注:

• ポートを含むホスト（または HTTP/2 :authority）ヘッダーは、構成されたホストと暗黙的に照合されます。ポートを明示的に指定する必要はありません。
• リクエストが HTTP 経由の場合、*.vod.example.com の hostRules[].hosts[] エントリは us.vod.example.com と us.vod.example.com:80 と一致します。
• リクエストが HTTPS（TLS）経由の場合、*.vod.example.com の hostRules[].hosts[] エントリは us.vod.example.com:443 と一致します。

詳細については、HostRule の API 仕様をご覧ください。

ヘッダーとクエリ パラメータで照合する

特定のヘッダーとクエリ パラメータ名、およびヘッダー値の存在（接頭辞、接尾辞、完全一致）に一致するようにルートを構成できます。

クエリ パラメータとヘッダーのマッチングは論理「AND」です。リクエストは、指定されたルートと一致するために、すべてのクエリ パラメータとヘッダーキー（値が指定されている場合は値）と一致する必要があります。

たとえば、特定のヘッダー フィールド名とヘッダー値を持つリクエストを alternate-origin という名前の送信元に転送する場合は、routeRules[].matchRules[].headerMatches[] 内で一致条件を構成します。

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 1
      origin: alternate-origin
      matchRules:
      - prefixMatch: "/videos/"
        headerMatches:
        - headerName: "x-device-name"
          exactMatch: "roku"

この例では、URL の先頭に /videos/ があり、x-device-name: roku ヘッダーを含むリクエストがこのルートと一致します。このヘッダー名がないリクエストや、値が異なるリクエストは、このルートと一致しません。

詳細については、HeaderMatch の API 仕様をご覧ください。

同様に、クエリ パラメータと照合するには、次のように 1 つ以上の queryParameterMatches を指定します。

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 1
      origin: eu-live-origin-prod
      matchRules:
      - prefixMatch: "/videos/"
        queryParameterMatches:
        - name: "playback_type"
          exactMatch: "live"
        - name: "geo"
          exactMatch: "eu"

この例では、https://cdn.example.com/videos/1234/abcd/xyz.m3u8?playback_type=live&geo=eu のクライアント リクエストがこのルートと一致します。

詳細については、QueryParameterMatcher の API 仕様をご覧ください。

キャッチオール（デフォルト）ルートを定義する

デフォルトでは、リクエストが構成済みのルートと一致しない場合、Media CDN は HTTP 404 (Not Found) エラーを返します。

特定の pathMatcher（ルートのコレクション）に対してキャッチオールルートを構成するには、次の手順を行います。

• 優先度が最も低い（数値が最も大きい）routeRule を作成します。たとえば、ルートの優先度として可能な最小値である 999 を指定します。
• 接頭辞一致が /（すべてのリクエスト パスと一致）の matchRule を構成します。
• ルートで origin または urlRedirect（いずれか）を構成します。

たとえば、一致しないすべてのリクエストを my-origin という名前のデフォルトの送信元に転送するキャッチオール ルートを構成するには、次のように priority: 999 と / の matchRules[].prefixMatch を含む新しいルートを作成します。

name: prod-service
routing:
  hostRules:
  - hosts:
    - cdn.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: example_routes
    routeRules:
    - priority: 999
      origin: my-origin
      matchRules:
      - prefixMatch: /

必要に応じて、送信元の取得前に URL を書き換えたり、リクエストをそのまま送信元に送信する代わりに、デフォルトのページ（ランディング ページなど）にリダイレクトしたりできます。

ルートの優先度と順序指定

routeRules[] の配列内の各ルートには、関連付けられた priority が必要です。

より具体的なルートには、高い優先度（小さい数値）を設定する必要があります。優先度 1 を持つ /stream/ の接頭辞と一致するルートにより、より具体的な優先度 5 を持つ /stream/live/eu/ のルートは、どのリクエストとも一致しません。

• 優先度が最も高いルートは「1」、最も低いルートは「999」です。
• 同じ優先度のルートルールを複数構成することはできません。各ルールの優先度は、0～2147483647 の番号に設定する必要があります。
• キャッチオールルートを定義すると、一致しないすべてのリクエストをデフォルトの送信元に送信するか、ランディング ページやエンドポイントにリダイレクトできます。

次の例では、/live/ ルートの優先度が高いため、/live/us/ ルートが一致することはありません。

routeRules:
- priority: 1
  description: "Live routes"
  matchRules:
  - prefixMatch: /live/
  routeAction:
    cdnPolicy:
      defaultTtl: 5s
- priority: 2
  description: "U.S based live streams"
  matchRules:
  # This would never be matched, as the /live/ prefixMatch at priority 1
  # would always take precedence.
  - prefixMatch: /live/us/
  routeAction:
    cdnPolicy:
      defaultTtl: 5s
- priority: 999
  description: "Catch-all route"
  matchRules:
  - prefixMatch: /

この問題に対処するには、より高い優先度でより具体的な（長い）ルートを設定します。

routeRules:
- priority: 1
  description: "U.S based live streams"
  matchRules:
  # The more specific (longer) match is at a higher priority, and now
  # matches requests as expected.
  - prefixMatch: /live/us/
  routeAction:
    cdnPolicy:
      defaultTtl: 5s
- priority: 2
  description: "Live routes"
  matchRules:
  - prefixMatch: /live/
  routeAction:
    cdnPolicy:
      defaultTtl: 5s
- priority: 999
  description: "Catch-all route"
  matchRules:
  - prefixMatch: /

これにより、より具体的なルートがリクエストに正しく一致します。/live/eu/ の接頭辞が付いたリクエストは、引き続き優先度 2 で /live/ ルートに適用されます。

メソッドのフィルタリング

デフォルトでは、Media CDN は GET、HEAD、OPTIONS メソッドのみを送信元にプロキシし、送信元を変更できるメソッドを除外します。

特定のルートルールでこのデフォルトの動作をオーバーライドするには、送信元にプロキシするメソッドを指定します。GET、HEAD、OPTIONS の他に、Media CDN は PUT、POST、DELETE、PATCH をサポートしています。

Media CDN は、GET、HEAD、OPTIONS などの安全な HTTP メソッドを使用するリクエストに対してのみ、再試行またはフェイルオーバーを試みます。

ルートルールのメソッドのセットのサポートを構成するには、各メソッドの allowed_methods 値を含む routeMethods セクションを指定します。

routeRules:
- priority: 5
  description: "Video uploads"
  routeMethods:
    allowedMethods: ["PUT", "POST", "OPTIONS"]
  matchRules:
  - pathTemplateMatch: "/uploads/**.ts"
  origin: prod-video-storage
- priority: 10
  description: "Video serving"
  routeMethods:
    allowedMethods: ["GET", "HEAD"]
  matchRules:
  - pathTemplateMatch: "/videos/**.ts"
  origin: prod-video-storage

パスの正規化

パスの正規化では、特定のシナリオで Media CDN が URL の複数の表現を単一の正規表現に結合する方法について説明します。

パスの正規化により、同じコンテンツを表すリクエスト URL の数を減らし、正規化されたパスを想定する送信元の送信元エラーを軽減することで、キャッシュ ヒット率を直接改善できます。

受信リクエストは次のように正規化されます。

• 連続する複数のスラッシュは 1 つのスラッシュに統合されます。たとえば、/videos///12345/manifest.mpd の URL パスは /videos/12345/manifest.mpd に正規化されます。
• パスセグメントは、RFC 3986 セクション 6.2.2.3 に従って正規化されます。 たとえば、RFC 3986 で定義されている「ドット セグメントを削除する」アルゴリズムに基づいて、パス /a/b/c/./../../g は /a/g に正規化されます。この正規化は、キャッシュの確認またはリクエストの送信元への転送の前に行われます。
• リクエストはパーセントで正規化されません。たとえば、パーセント スラッシュ（%2F）エンコードを含む URL の場合、エンコードされていない形式にデコードされません。

URL の大文字と小文字は区別されません。多くの URL には、署名付きリクエストトークンを含む URL など、大文字と小文字が区別される base64 エンコードが含まれています。

書き換えとリダイレクト