メディア CDN は、トラフィックを特定のエッジ構成と送信元にきめ細かいレベルでマッピングできる高度な HTTP ルーティング機能を提供します。
ルートルールを構成する
Media CDN サービスのルートルールを構成する。
Console
Google Cloud コンソールで、[Media CDN] ページに移動します。
ルートルールを構成するサービスの [詳細] ページを開くには、サービス名をクリックします。
編集モードに切り替えるには、[編集] ボタンをクリックします。
[ルーティング] セクションに移動するには、[次へ] をクリックします。
ホストルールを少なくとも 1 つ指定します。[ホストルールを追加] をクリックします。次に、以下の操作を行います。
[ホスト] に、マッチングするホストを少なくとも 1 つ指定します。
[説明] に、ホストルールの簡単な説明を入力します。
または、ホストルールを編集するには、矢印をクリックして展開します。
ルートルールを少なくとも 1 つ指定します。[ルートのルールを追加] をクリックします。
または、ルートルールを編集するには、それぞれの行で [編集] をクリックします。
[ルートルールを編集] ペインの [優先度] で、ルートの優先度の値を設定します。
[説明] に、ルールのリストでルールを識別できる簡単な説明を入力します。
[一致] セクションで、一致条件を 1 つ以上指定します。[一致条件を追加] をクリックします。次に、以下の操作を行います。
- [一致タイプ] で、任意のパスの一致オプションを選択します。
[パスの一致] で、名前、パス、またはテンプレートを指定します。ワイルドカード パターン マッチングの使用を検討してください。
必要に応じて、[パス値の大文字と小文字の区別を有効にする] も選択します。
省略可: [ヘッダーの一致] と [クエリ パラメータの一致] を選択します。次に、関連するボタンをクリックして、ヘッダーとクエリ パラメータを追加します。それぞれに名前、一致タイプ、値を指定します。
詳細については、ヘッダーとクエリ パラメータの一致をご覧ください。
一致条件を保存するには、[完了] をクリックします。
[プライマリ アクション] で、次のいずれかのオプションを選択します。
送信元から取得: リクエストを特定の送信元に転送するには、このオプションを選択し、送信元を選択します。
URL リダイレクト: リクエストをリダイレクトするには、このオプションを選択します。次に、リダイレクトのタイプ、パス、ステータス コードを指定します。
必要に応じて、すべてのレスポンスを HTTPS にリダイレクトするか、クエリを削除するオプションを選択します。
[詳細構成] をクリックします。
[ヘッダー アクション] セクションで、[項目を追加] をクリックします。
アクションのタイプを選択し、名前と値のペアとしてヘッダーを指定します。次に [完了] をクリックします。
[ルートのアクション] セクションで、[項目を追加] をクリックします。
アクションのタイプと関連するオプションを指定します。次に [完了] をクリックします。
[HTTP メソッドのフィルタリング] で、[HTTP メソッドのフィルタリングをカスタマイズする] を選択します。
次に、オリジンにプロキシする HTTP メソッドを選択します。
ルートルールを保存するには、[保存] をクリックします。
サービスへの変更を保存するには、[サービスを更新する] をクリックします。
gcloud と YAML
Media CDN 構成を YAML ファイルにエクスポートします。
gcloud edge-cache services exportコマンドを使用します。gcloud edge-cache services export SERVICE_NAME \ --destination=FILENAME.yaml次のように置き換えます。
SERVICE_NAME: サービスの名前FILENAME: YAML ファイルの名前
このページのセクションで説明されているように、必要な構成で YAML ファイルを更新します。
サービスを更新するには、YAML ファイルから Media CDN 構成をインポートします。
gcloud edge-cache services importコマンドを使用します。gcloud edge-cache services import SERVICE_NAME \ --source=FILENAME.yaml
一致したリクエスト数
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 つです。
| フィールド | 説明 | 例 |
|---|---|---|
matchRules[].fullPathMatch
|
fullPathMatch 条件は、クエリ文字列を含まない完全な URL パスと一致します。必要に応じて、末尾のスラッシュを指定する必要があります。 |
一致ルールが
|
matchRules[].prefixMatch
|
prefixMatch 条件は URL パスの接頭辞、すなわち同じ文字列で始まる URL と一致します。
|
|
matchRules[].pathTemplateMatch
|
pathTemplateMatch 条件ではワイルドカード演算子がサポートされます。これにより、複雑な URL パターンやパスセグメントを照合したり、URL を書き換えるための名前付き変数をキャプチャしたりできます。
|
その他の例については、パターン マッチングのセクションをご覧ください。 |
詳細については、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 の複数の部分を照合できます。
1 つ以上のパスセグメントを pathTemplateMatch フィールドの名前付き変数に関連付けて、pathTemplateRewrite フィールドで URL を書き換える際にそれらの変数を参照することもできます。これにより、リクエストが送信元に送信される前に URL セグメントの順序を変更して削除できます。
次の例は、2 つの異なる URL 接尾辞に対する照合方法を示しています。
# EdgeCacheService.routing.pathMatchers[] routeRules: - priority: 1 description: "Match video segments" matchRules: - pathTemplateMatch: "/**.ts" - pathTemplateMatch: "/**.m4s" origin: prod-video-storage
サポートされている構文は次のとおりです。
| 演算子 | 一致 | 例 |
|---|---|---|
*
|
次のパス区切り文字 / までの 1 つのパスセグメントと一致します。
|
/videos/*/*/*.m4s matches
/videos/123414/hls/1080p5000_00001.m4s.
|
**
|
0 個以上のパスセグメントを照合します。存在する場合は、最後の演算子にする必要があります。 |
/**.mpd matches
/content/123/india/dash/55/manifest.mpd.
|
{name} or {name=*}
|
1 つのパスセグメントに一致する名前付き変数。
次のパス区切り文字 |
/content/{format}/{lang}/{id}/{file}.vtt は /content/hls/en-us/12345/en_193913.vtt と一致し、format="hls"、lang="en-us"、id="12345"、file="en_193913" を変数としてキャプチャします。
|
{name=videos/*}
|
複数のパスセグメントに一致する名前付き変数。videos/* に一致するパスセグメントは、名前付き変数としてキャプチャされます。
|
/videos/{language=lang/*}/* は /videos/lang/en/video.m4s と一致し、パス変数 language に値 lang/en を入力します。
|
{name=**}
|
0 個以上のパスセグメントに一致する名前付き変数。 存在する場合は、最後の演算子にする必要があります。 |
|
注:
- URL を書き換えない場合は、よりシンプルな
*演算子と**演算子を使用します。 - 変数を使用してパスセグメントをキャプチャする場合、変数でキャプチャされていない URL の部分は、後続の
pathTemplateRewriteで参照できません。例については、パス変数のキャプチャのセクションをご覧ください。 - 同じルートの
pathTemplateMatchに存在しない変数を、後続のpathTemplateRewriteで参照することはできません。 - 変数では大文字と小文字が区別され、
{FORMAT}、{forMAT}、{format}は異なる変数と値を表します。 - マッチには最大 10 個のオペレーター（ワイルドカードまたは変数）を指定できます。
pathTemplateMatchフィールドとpathTemplateRewriteフィールドは 255 文字以下にする必要があります。
例: ファイル拡張子による一致
次の例は、ワイルドカード演算子の一般的なユースケースを示しています。接尾辞までのすべてのパスセグメントを照合します。
この場合は、次の操作を行います。
- マニフェストの送信元から
.m3u8と.mpdで終わる動画マニフェスト（プレイリスト）を取得します。これらのレスポンスは定期的に変更されるため、短い（5 秒）TTL を適用します。 - セグメントの送信元から
.tsと.m4sで終わる動画セグメントを取得し、これらのレスポンスに長い（1 日）TTL を適用します。
このアプローチは、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}変数は、オリジンのディレクトリ構造と一致しないため、明示的に省略します。
この例では、次のことが行われます。
- 受信したリクエスト URL
/us/en/hls/123139139/segment_00001.tsはpathTemplateMatchと一致し、送信元に送信される前に/123139139/hls/segment_00001.tsに書き換えられます。 - 受信リクエスト URL
/us/123139139/master.m3u8はpathTemplateMatchと一致せず、HTTP404 (Not Found)レスポンスを受信します。 - 受信リクエスト URL
/br/es/dash/c966cbbe6ae3/subtitle_00001.vttも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 メソッドのみを送信元にプロキシし、送信元を変更できるメソッドを除外します。
特定のルートルールに対してこのデフォルトの動作をオーバーライドするには、オリジンにプロキシするメソッドを指定します。Media CDN は、GET、HEAD、OPTIONS のほか、PUT、POST、DELETE、PATCH もサポートしています。
ルートルールのメソッドセットのサポートを構成するには、メソッドごとに 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 の複数の表現を 1 つの正規表現に統合する方法について説明します。
パスの正規化は、同じコンテンツを表すリクエスト URL の数を減らし、正規化されたパスを想定する送信元の送信元エラーを軽減することで、キャッシュ ヒット率を直接改善できます。
受信リクエストは次のように正規化されます。
- 連続する複数のスラッシュは 1 つのスラッシュに統合されます。たとえば、URL パス
/videos///12345/manifest.mpdは/videos/12345/manifest.mpdに正規化されます。 - パスセグメントは、RFC 3986 セクション 6.2.2.3 に従って正規化されます。
たとえば、パス
/a/b/c/./../../gは、RFC 3986 で定義されている「ドットセグメントを削除」アルゴリズムに基づいて/a/gに正規化されます。この正規化は、キャッシュのチェックやリクエストの送信元への転送の前に行われます。 - リクエストはパーセントで正規化されません。たとえば、パーセント スラッシュ（
%2F）エンコードを含む URL の場合、エンコードされていない形式にデコードされません。
URL の大文字と小文字は区別されません。多くの URL には、署名付きリクエストトークンを含む URL など、大文字と小文字が区別される base64 エンコードが含まれています。
書き換えとリダイレクト
以降のセクションでは、リクエストの書き換えとリダイレクトの構成方法の例を示します。
リクエスト URL の書き換え
Media CDN は、ホストとパスの書き換えをサポートしています。書き換えは、オリジンに送信される URL を変更し、必要に応じてホストとパスを変更できるようにします。ホストとパスの書き換えはルートレベルで行われるため、パス、クエリ パラメータ、リクエスト ヘッダーなど、任意のマッチング条件に基づいて、書き換えられる特定のリクエストを定義できます。
詳細については、RouteAction.UrlRewrite の API 仕様をご覧ください。
リクエストを書き換える方法は次の 3 つです。
| フィールド | 説明 |
|---|---|
urlRewrite.pathPrefixRewrite
|
パスを書き換え、リクエストに一致する
1 つのルートルールで指定できるのは、 |
urlRewrite.pathTemplateRewrite
|
1 つのルートルールで指定できるのは、 |
urlRewrite.hostRewrite
|
リクエストを送信元サーバーに送信する前にホストを書き換えます。 |
注:
- 書き換えられた URL ではキャッシュキーは変更されません。キャッシュキーは、クライアントが送信したリクエスト URL に基づきます。
- 書き換えは、ルートの照合と署名付きリクエストの検証の後に実行されます。ルートは別の一致ルールに対して再照合されません。
例: パス接頭辞を削除する
たとえば、クライアント リクエスト URL を /vod/videos/hls/1234/abc.ts から /videos/hls/1234/abc.ts に書き換える（パスから /vod を削除する）には、pathPrefixRewrite 機能を使用します。
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: my-origin matchRules: - prefixMatch: "/vod/videos/" routeAction: urlRewrite: pathPrefixRewrite: "/videos/"
pathPrefixRewrite は、matchRules[].prefixMatch で一致したパス プレフィックス全体を pathPrefixRewrite の値に置き換えることで機能します。
ホスト名を書き換える（cdn.example.com を my-bucket.s3.us-west-2.amazonaws.com に書き換えるなど）には、次のように構成します。
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: my-origin matchRules: - prefixMatch: "/videos/" routeAction: urlRewrite: hostRewrite: "my-bucket.s3.us-west-2.amazonaws.com"
この場合、送信元のリクエスト URL は cdn.example.com/videos/* から my-bucket.s3.us-west-2.amazonaws.com/videos/* に変更されます。
1 つのルート内でホストとパスの両方の書き換えを組み合わせることもできます。
例: 変数を使用して URL を書き換える
pathTemplateMatch と pathTemplateRewrite を使用して受信リクエスト URL の一部を書き換えるには、変数の取得のセクションをご覧ください。
リクエストをリダイレクトする
Media CDN は、次の 3 種類のリダイレクトをサポートしています。
- ホスト リダイレクト: パスとクエリ パラメータは変更せずに、ホスト（ドメイン）のみをリダイレクトします。
- パス リダイレクト: パス全体を置き換えます。
- パス接頭辞リダイレクト: 一致する接頭辞のみを置き換えます。
リダイレクトはデフォルトで HTTP 301 (Moved Permanently) ですが、ルートごとに異なるリダイレクト ステータス コードを返すように構成できます。
次の構成は、https://cdn.example.com/on-demand/* にアクセスしたユーザーを https://cdn.example.com/streaming/* にリダイレクトする接頭辞ベースのリダイレクトの例です。
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 10 matchRules: - prefixMatch: "/on-demand/" urlRedirect: # The prefix matched in matchRules.prefixMatch is replaced # by this value prefixRedirect: "/streaming/" redirectResponseCode: TEMPORARY_REDIRECT # corresponds to a HTTP 307
この例では、リダイレクトを一時リダイレクトに変更して、クライアント（ブラウザなど）がキャッシュに保存しないようにしています。これは、近い将来変更する予定がある場合に便利です。
サポートされている redirectResponseCode 値を次の表に示します。
| リダイレクトのレスポンス コード | HTTP ステータス コード |
|---|---|
MOVED_PERMANENTLY_DEFAULT |
HTTP 301（恒久的に移動） |
FOUND |
HTTP 302 (Found) |
SEE_OTHER |
HTTP 303（他を参照） |
TEMPORARY_REDIRECT |
HTTP 307（一時的なリダイレクト） |
PERMANENT_REDIRECT |
HTTP 308（恒久的なリダイレクト） |
注:
- ルートは、トラフィックを送信元に転送するか、リダイレクトをクライアントに返すことができます。
originフィールドとurlRedirectフィールドの両方を同時に設定することはできません。 - HTTPS にリダイレクトするルートには、少なくとも 1 つの SSL 証明書がサービスにアタッチされている必要があります。
詳細については、RouteRule.UrlRedirect の API 仕様をご覧ください。
すべてのリクエストを HTTPS にリダイレクトする
すべてのリクエストを HTTP ではなく HTTPS にリダイレクトするには、すべてのクライアント リクエストを HTTPS に自動的にリダイレクトするように各サービスを構成します。HTTP 経由で接続しているクライアントは、「http://」の代わりに「https://」を使用して同じ URL に設定した Location ヘッダーで HTTP 301 (Permanent Redirect) レスポンスを送信します。
gcloud
gcloud edge-cache services update MY_SERVICE \ --require-tls
Request issued for: [MY_SERVICE] Updated service [MY_SERVICE].
このコマンドは、サービスの説明を返します。requireTls は true に設定されています。
name: MY_SERVICE requireTls: true
Strict-Transport-Security ヘッダーをレスポンス ヘッダーとして設定し、クライアントが常に HTTPS 経由で直接接続するように指示することもできます。
サードパーティのストレージ バックエンドを使用する
Media CDN は、AWS S3 ストレージ バケット、Azure Blob Storage、その他のストレージ プロバイダなど、Google Cloud の外部にある一般公開されている HTTP エンドポイントへの接続をサポートしています。これは、マルチクラウド アーキテクチャを使用している場合や、Storage Transfer Service を使用して Cloud Storage にデータを移行していない場合に役立ちます。
AWS S3 で仮想ホストバケットを構成する最小限のオリジン構成:
name: MY_S3_ORIGIN originAddress: BUCKET-NAME.s3.REGION.amazonaws.com
EdgeCacheService リソースに構成されたホスト名と一致するバケット名を使用していない場合は、このオリジンに関連付けられたルートのホスト書き換えも構成する必要があります。それ以外の場合は、送信元から取得するときに、クライアント リクエストによって設定された Host ヘッダーが使用されます。
たとえば、パス接頭辞が /legacy/ のすべてのリクエストを外部バケットにマッピングするには、送信元リクエストからこの接頭辞を削除するように hostRewrite と pathPrefixRewrite の両方を構成します。
routeRules: - description: legacy backend matchRules: - prefixMatch: "/legacy/" routeAction: urlRewrite: hostRewrite: BUCKET-NAME.s3.REGION.amazonaws.com pathPrefixRewrite: / cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 3600s
送信元リクエストでホストヘッダーが設定される方法の詳細については、送信元リクエスト ヘッダーのドキュメントをご覧ください。
クロスオリジン リソース シェアリング（CORS）
クロスオリジン リソース シェアリング（CORS）は、クロスオリジン リクエストを安全に行うためのブラウザ中心のアプローチです。CORS ポリシーを使用すると、ルートごとのポリシーに基づいて Access-Control-Allow-Origins などの CORS ヘッダーを自動的に設定できます。
CORS の構成
Media CDN では、EdgeCacheService のルートで CORS ポリシーを定義できます。
CORS ポリシーでは、共通の HTTP ヘッダーのセットでこれらのルールを定義します。レスポンスで一般的な CORS ヘッダー（Access-Control-Allow-Origin、Access-Control-Max-Age、Access-Control-Allow-Headers など）を設定できます。これらのヘッダーを使用すると、メディア CD サービスへのクロスオリジン呼び出しが可能になります。これらは、ウェブサイトのフロントエンドとは異なるドメイン（オリジン）でホストされている可能性があるため、明示的に許可されないクロスオリジン リクエストが阻止される場合があります。
たとえば、player.example.com と api.example.com は（ブラウザの意味で）異なる送信元であり、フロントエンド アプリケーションに api.example.com にリクエストを送信して次の再生リストを取得するか、関連コンテンツのリストを更新するようリクエストできます。同様に、player.example.com は cdn.example.com に連絡して動画再生リストと動画セグメントを取得する必要があります。
cdn.example.com はこれが問題ないこと、および player.example.com が allowed origin および他のルール（許可されるヘッダー、Cookie を含めるかどうか）であることを示す必要があります。
別の例として、stream.example.com を送信元として許可し、CORS リクエストで X-Client-ID ヘッダーを許可する場合は、次のようにルートで corsPolicy を構成できます。
corsPolicy: maxAge: 600 allowOrigins: ["stream.example.com"] allowHeaders: ["X-Client-ID"]
corsPolicy は EdgeCacheService 内の routing.pathMatchers[].routeRules[].routeAction.corsPolicy で構成されます。各 routeRule は、必要に応じて異なる corsPolicy を定義できます。また、まったく定義しないこともできます。
corsPolicy 値を定義し、同じ名前のルートで responseHeadersToAdd フィールドを使用してカスタム レスポンス ヘッダーも設定すると、カスタム レスポンス ヘッダーが優先され、corsPolicy の値の代わりに使用されます。
送信元レスポンスで HTTP ヘッダーが設定され、corsPolicy 値が設定されている場合、代わりに corsPolicy 値が使用されます。値は圧縮または結合されません。これにより、無効なヘッダー値をクライアントに送信したり、意図したよりも許容度の高いポリシーを意図せず設定したりすることを回避します。
特別な {origin_request_header} には、クライアント リクエストの Origin HTTP ヘッダーが入力されます。これは、Access-Control-Allow-Origin ヘッダーのルートでカスタム レスポンス ヘッダー値として設定できます。
詳細については、RouteAction.CORSPolicy の API 仕様をご覧ください。
CORS ポリシーのフィールド
次の表に、CORS ポリシーに含まれるフィールドを示します。
| フィールド | 説明 | 例 |
|---|---|---|
| allowOrigins |
たとえば、動画コンテンツが |
Access-Control-Allow-Origins: https://stream.example.com
|
| maxAge |
一部のブラウザでは、最大値（86, 400 秒）が指定されていても、この値が 2 時間以下に制限されます。 |
Access-Control-Max-Age: 7200
|
| allowMethods |
デフォルトでは、Media CDN は |
Access-Control-Allow-Methods: GET, OPTIONS, HEAD
|
| allowHeaders |
動画プレーヤーは、クロスオリジンで動画コンテンツをリクエストするときに一部のレスポンス ヘッダーにアクセスする必要があるため、多くの場合これが必須です。 |
Access-Control-Allow-Headers: Content-Type, If-Modified-Since,
Range, User-Agent
|
| exposeHeaders |
動画プレーヤーは、クロスオリジンでコンテンツをリクエストするときに、動画コンテンツの特定のレスポンス ヘッダーにアクセスする必要がある場合があるため、多くの場合これが必須です。 |
Access-Control-Expose-Headers: Date, Cache-Status, Content-Type,
Content-Length
|
| allowCredentials |
このヘッダーは、false に設定されている場合は省略されます。 |
Access-Control-Allow-Credentials: true
|
| disabled |
corsPolicy を削除せずに無効にします。プリフライトの OPTIONS リクエストは、送信元にプロキシされます。
|
該当なし |
corsPolicy の例
次の構成例は、基本的な corsPolicy 構成を示しています。
routeRules: - priority: 1 matchRules: - prefixMatch: /stream/ routeAction: cdnPolicy: defaultTtl: 3600s corsPolicy: allowOrigins: - "https://stream.example.com" - "https://stream-staging.example.com" maxAge: 86400s # some browsers might only honor up to 7200s or less allowMethods: - "GET" - "HEAD" - "OPTIONS" allowHeaders: - "Content-Type" - "If-Modified-Since" - "Range" - "User-Agent" exposeHeaders: - "Content-Type" - "Content-Length" - "Date"
ルーティングのトラブルシューティング
一部のリクエストで一致する結果が取得されない、またはエラーが返される場合は、次の点を確認します。
- ルートには、
prefixMatch、fullPathMatch、pathTemplateMatchのいずれか 1 つが定義されたmatchRuleが必要です。これらのフィールドのいずれかを含めない場合、API はエラーを返します。 - 各ルートの
priorityが正しく設定されていることを確認します。より具体的な（長い）ルートは、より短く幅広いルート一致よりも優先度が高くする必要があります。 - デフォルトでは、
GET、HEAD、OPTIONSリクエストのみがサポートされています。他のメソッドのサポートを構成するには、ルート メソッドをご覧ください。特定のルートで有効になっていないメソッドは、HTTP405 (Method Not Allowed)エラーで拒否されます。 GETリクエストではリクエスト本文が許可されないため、本文を含む HTTPGETリクエストまたはトレイラーが含まれるリクエストは、HTTP400エラーで拒否されます。- クエリ パラメータとヘッダーのマッチングは論理「AND」です。指定されたルートに一致するには、リクエストがすべてのクエリ パラメータまたはヘッダーキー（値が指定されている場合は値も）と一致する必要があります。
次のステップ
- キャッシュの構成に関するドキュメントを確認します。
- さまざまな送信元に接続する方法を理解する。
- サービスの TLS（SSL）証明書を設定する。
- コンテンツへのアクセスを認証するように署名付きリクエストを構成します。