メディア CDN は、トラフィックを特定のエッジ構成と送信元にきめ細かいレベルでマッピングできる高度な HTTP ルーティング機能を提供します。
一致したリクエスト数
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}は異なる変数と値を表します。 - 1 つの一致で最大 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 の書き換えの相互運用の詳細については、書き換えのセクションをご覧ください。
ホスト マッチング
各サービスは複数のホスト名で照合できます。各ホスト名には、独自のルートグループ（パスマッチャー）が含まれています。最も一般的なケースでは、サービスのすべてのホスト名が、単一のホストリストと 1 つのパスマッチャーを使用した単一の共有ルートセットにマッピングされます。
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 をサポートしています。
ルートルールの一連のメソッドのサポートを構成するには、各メソッドに 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 は v1alpha1 Network Services API を使用してこの構成を更新および表示できます。または、gcloud alpha edge-cache services export コマンドおよび gcloud alpha edge-cache services import コマンドを使用して、サービス構成の YAML ファイルを更新するします。
パスの正規化
パスの正規化は、Media CDN が特定のシナリオで URL の複数の表現を単一の正規表現に結合する方法を表します。
パスの正規化では、同じコンテンツを表すリクエスト URL の数を減らし、正規化されたパスを想定する送信元のエラーが軽減されるため、キャッシュ ヒット率を直接改善できます。
受信リクエストは次のように正規化されます。
- 複数の連続スラッシュは単一のスラッシュに統合されます。たとえば、
/videos///12345/manifest.mpdという URL パスは/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 は、Google Cloud の外部にあり、AWS S3 ストレージ バケット、Azure Blob Storage、その他のストレージ プロバイダなど、一般公開された 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 ヘッダーのセットを使用してこれらのルールを定義します。Access-Control-Allow-Origin、Access-Control-Max-Age、Access-Control-Allow-Headers などの共通の CORS ヘッダーをレスポンスに設定できます。これらのヘッダーを使用すると、メディア 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 を含めるかどうか）であることを示す必要があります。
別の例として、CORS リクエストで stream.example.com を送信元として、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 |
一部のブラウザでは、最大値（86400s）が指定されていても、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)エラーで拒否されます。 - 本文付きの HTTP
GETリクエストや、トレーラー付きのリクエストは、リクエスト本文がGETリクエストで許可されていないため、HTTP400エラーで拒否されます。 - クエリ パラメータとヘッダーのマッチングは論理「AND」です。つまり、リクエストは、指定されたルートに一致するすべてのクエリ パラメータまたはヘッダーキー（および指定されている場合は値）に一致する必要があります。
次のステップ
- キャッシュの構成に関するドキュメントを確認する。
- さまざまな送信元に接続する方法を理解する。
- サービスの TLS（SSL）証明書を設定する。
- コンテンツへのアクセスを認証するように署名付きリクエストを構成する。