キャッシュの構成

Media CDN は、できる限りユーザーにコンテンツを配信するために、Google のグローバルエッジキャッシングインフラストラクチャを使用してコンテンツをキャッシュに保存し、送信元インフラストラクチャへの負荷を軽減しています。

ルートごとにコンテンツをキャッシュに保存する方法を制御できます。これにより、コンテンツの種類、クライアントのリクエスト属性、鮮度の要件に基づいて動作を最適化できます。

キャッシュへの保存

以下のセクションでは、Media CDN がキャッシュに保存するレスポンスと、キャッシュオフロードを改善する方法について説明します。

デフォルトのキャッシュ動作

デフォルトでは、各キャッシュに次のキャッシュ関連の設定が適用されます。

デフォルトのキャッシュモードは CACHE_ALL_STATIC です。
- 送信元のキャッシュディレクティブ（Cache-Control、Expires など）に従います。
- 静的コンテンツタイプを自動的にキャッシュに保存します。デフォルトの TTL は 3,600 秒です。
- HTTP 200 および 206 ステータスコードをキャッシュに保存します（ネガティブキャッシュは有効になっていません）。
no-cache または no-store ディレクティブを含むレスポンス、またはキャッシュできないレスポンスはキャッシュに保存されません。

静的コンテンツでないレスポンスや、有効なキャッシュディレクティブがないレスポンスは、キャッシュが明示的に構成されていない限りキャッシュに保存されません。デフォルトの動作をオーバーライドする方法については、キャッシュモードに関するドキュメントをご覧ください。

デフォルトの動作は次の cdnPolicy と同等です。明示的な cdnPolicy が構成されていないルートは、次の構成の場合と同様に動作します。

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    includeProtocol: false
    excludeHost: false
    excludeQueryString: false
  signedRequestMode: DISABLED
  negativeCaching: false

キャッシュに保存可能なレスポンス

キャッシュに格納可能なレスポンスとは、Media CDN がキャッシュに保存できる HTTP レスポンスで、すぐに取り出せるので読み込み時間が短縮されます。すべての HTTP レスポンスがキャッシュに保存可能なわけではありません。

送信元がレスポンスのキャッシュ制御ディレクティブを設定していなくても、ルートごとにキャッシュモードを構成してこの動作をオーバーライドできます（たとえば、CACHE_ALL_STATIC キャッシュモードを使用して、一般的なメディアタイプをキャッシュに保存します）。

キャッシュ不可のレスポンスで定義されている基準を満たしているリクエストとレスポンスは、キャッシュ保存よりも優先されます。

次の表は、特定の HTTP レスポンスをキャッシュに保存するための要件を示しています。

HTTP 属性	要件
Status Code	レスポンスステータスコードは、200、203、204、206、300、301、302、307、308、400、403、404、405、410、451、501 のいずれかである必要があります。
HTTP メソッド	GET、HEAD、OPTIONS
リクエストヘッダー	リクエストヘッダーはアイテムのキャッシュ保存には影響しません。詳細については、キャッシュ制御ディレクティブをご覧ください。
レスポンスヘッダー	有効な `Content-Length` ヘッダーが含まれています。有効な HTTP キャッシュディレクティブ（`Cache-Control: max-age=3600, public` など）が含まれています。そのコンテンツをキャッシュするキャッシュモードがあります。または将来の日付の `Expires` ヘッダーがあります。
レスポンスサイズ	最大 50 GiB。

HTTP Age ヘッダーは、メディア CDN がレスポンスを最初にキャッシュに保存したタイミングに基づいて設定されます。通常は、オブジェクトが送信元シールディングのロケーションでキャッシュに保存された時点からの秒数を表します。送信元で Age レスポンスヘッダーが生成される場合は、FORCE_CACHE_ALL キャッシュモードを使用して、Age がキャッシュ TTL を超えたときに再検証されないようにします。

Media CDN が HTTP キャッシュディレクティブをどのように解釈するかの詳細については、キャッシュ制御ディレクティブをご覧ください。

送信元の要件

Media CDN が送信元のレスポンスをキャッシュに保存できるようにするには、指定されていない限り、送信元に HEAD リクエストと GET リクエストの両方のレスポンスヘッダーに以下を含める必要があります。

Last-Modified または ETag HTTP レスポンスヘッダー。
有効な HTTP Date ヘッダー。
有効な Content-Length ヘッダー。
Accept-Ranges: bytes レスポンスヘッダー。
Range GET リクエストに対する Content-Range レスポンスヘッダー。Content-Range ヘッダーには、bytes x-y/z の形式の有効な値が必要です（z はオブジェクトのサイズ）。

デフォルトの送信元プロトコルは HTTP/2 です。送信元が HTTP/1.1 のみをサポートしている場合は、送信元ごとにプロトコルフィールドを明示的に設定できます。

キャッシュ不可のレスポンス

次の表に、レスポンスがキャッシュされないリクエスト属性とレスポンス属性を示します。キャッシュに保存可能なレスポンスが「キャッシュ不可」の条件と一致するレスポンスは、キャッシュに保存されません。

HTTP 属性	条件
Status Code	キャッシュ可能として定義されていないステータスコード（HTTP 400、HTTP 403、HTTP 504 など）。これらのステータスコードは一般的に、クライアント側の問題を表しており、送信元のステータスではありません。これらのレスポンスをキャッシュに保存すると、次のような「キャッシュ汚染」シナリオが発生する可能性があります。このシナリオでは、ユーザーがトリガーした「不正な」レスポンスがすべてのユーザーについてキャッシュに保存されます。
リクエストヘッダー	リクエストヘッダーは、`Authorization` リクエストヘッダーを除いて、アイテムをキャッシュに保存するかどうかに影響を及ぼしません。この場合、レスポンスに `public` キャッシュ制御ディレクティブを含める必要があります。詳細については、キャッシュ制御ディレクティブをご覧ください。
レスポンスヘッダー	`Set-Cookie` ヘッダーがある。 `Accept`、`Accept-Encoding`、`Origin` 以外の `Vary` ヘッダーがある。 `no-store` キャッシュ制御ディレクティブが設定されている以前に `Expires` ヘッダーが設定されている。`Cache-Control` ヘッダーがレスポンスに設定されている場合、`Expires` ヘッダーは無視されます。
レスポンスサイズ	50 GiB 超。

これらのルールは、構成済みのキャッシュモードに加えて適用されます。特に、以下の点に注意してください。

CACHE_ALL_STATIC キャッシュモードを構成すると、静的コンテンツとみなされるレスポンス、またはレスポンスヘッダーに有効なキャッシュディレクティブを含むレスポンスのみがキャッシュに保存されます。その他のレスポンスは「現状のまま」でプロキシされます。
FORCE_CACHE_ALL キャッシュモードでは、レスポンスがキャッシュ可能なステータスコードであれば、すべてのレスポンスが無条件にキャッシュに保存されます。
USE_ORIGIN_HEADERS キャッシュモードの場合、レスポンスは、キャッシュ可能なステータスコードだけでなく、レスポンスヘッダーに有効なキャッシュディレクティブを設定する必要があります。

注:

キャッシュに保存されていないレスポンスは Cache-Control ディレクティブやその他のヘッダーは変更されず、「そのまま」でプロキシされます。
同じ名前の複数のヘッダーフィールドを含む HTTP レスポンスは、必要に応じて 1 つのヘッダーフィールドにまとめられます。たとえば、Cache-Control: no-cache と Cache-Control: no-store という行が別々の行にあるレスポンスは、Cache-Control: no-cache, no-store として折りたたまれます。
キャッシュできないレスポンス（決してキャッシュされないレスポンス）は、課金の観点からはキャッシュ下り（外向き）としてカウントされません。

キャッシュモードの使用

キャッシュモードでは、ディレクティブの設定にかかわらず、Media CDN が送信元 CDN ディレクティブを遵守し、静的コンテンツタイプをキャッシュに保存し、送信元からのすべてのレスポンスをキャッシュに保存するタイミングを構成できます。

キャッシュモードはルートレベルで構成され、TTL オーバーライドと組み合わせることで、ホスト、パス、クエリパラメータ、ヘッダー（一致する任意のリクエストパラメータ）によってキャッシュの動作を構成できます。

デフォルトでは、Media CDN は CACHE_ALL_STATIC キャッシュモードを使用します。このモードでは、一般的な静的コンテンツタイプ、および有効なキャッシュディレクティブを持つキャッシュ可能なレスポンスが 1 時間（3,600 秒間）自動的にキャッシュされます
ルートに cdnPolicy.defaultTtl フィールドを設定することで、明示的なキャッシュ TTL セット（max-age または s-maxage ディレクティブ）を指定せずに、レスポンスに適用されるキャッシュ TTL を増減できます。
2xx 以外（不成功）のステータスコードは、Content-Type（MIME タイプ）に従ってキャッシュに保存されず、デフォルトの TTL が適用されません。これにより、不成功のレスポンスが意図したよりも長くキャッシュされないようになります。

各ルートの cdnPolicy.cacheMode に設定されている使用可能なキャッシュモードは次のとおりです。

キャッシュモード	動作
`USE_ORIGIN_HEADERS`	有効なキャッシュディレクティブと有効なキャッシュヘッダーを設定するには、送信元のレスポンスが必要です。要件の一覧については、キャッシュ可能なレスポンスのドキュメントをご覧ください。
`CACHE_ALL_STATIC`	`no-store`、`private`、または `no-cache` ディレクティブがない静的コンテンツを自動的にキャッシュに保存します。有効なキャッシュディレクティブを設定した送信元のレスポンスもキャッシュに保存されます。静的コンテンツには、`Content-Type`、レスポンスヘッダーの MIME タイプで定義された動画、音声、画像、一般的なウェブアセットが含まれます。
`FORCE_CACHE_ALL`	レスポンスを無条件にキャッシュに保存し、送信元で設定されたすべてのキャッシュディレクティブをオーバーライドします。このモードで構成されている、ユーザー単位のプライベートコンテンツ（ダイナミック HTML や API レスポンスなど）は提供しないでください。
BYPASS_CACHE	このキャッシュモードに構成されたルートに一致するリクエストは、そのキャッシュキーに一致するキャッシュオブジェクトが存在する場合でも、キャッシュをバイパスします。 Media CDN は汎用プロキシではなく、グローバルキャッシュインフラストラクチャとして設計されているため、デバッグにのみ使用することをおすすめします。

静的コンテンツの MIME タイプ

CACHE_ALL_STATIC キャッシュモードを使用すると、Media CDN は、Content-Type HTTP レスポンスで返された MIME タイプに基づいて、動画、音声、画像、一般的なウェブアセットなどの一般的な静的コンテンツを自動的にキャッシュに保存できます。

次の表に、CACHE_ALL_STATIC キャッシュモードで自動的にキャッシュされる MIME タイプを示します。

次の値と一致する値を含む Content-Type レスポンスヘッダーがない場合、レスポンスは自動的にはキャッシュに保存されません。レスポンスで有効なキャッシュディレクティブを設定するか、FORCE_CACHE_ALL キャッシュモードを使用してレスポンスを無条件にキャッシュに保存する必要があります。

Category	MIME タイプ
ウェブアセット	text/css text/ecmascript text/javascript application/javascript
フォント	font/* に一致するすべての Content-Type
画像	image/* に一致するすべての Content-Type
動画	video/* に一致するすべての Content-Type
音声	audio/* に一致するすべての Content-Type
フォーマットされたドキュメントタイプ	application/pdf and application/postscript

次の点にご注意ください。

送信元のウェブサーバーソフトウェアが各レスポンスで Content-Type を設定する必要があります。多くのウェブサーバーは、NGINX、Varnish、Apache などの Content-Type ヘッダーを自動的に設定します。
Google Cloud コンソールまたは gsutil ツールを使用してコンテンツをアップロードすると、Cloud Storage により Content-Type ヘッダーがアップロード時に自動的に設定されます。
レスポンスが MIME タイプに基づいてキャッシュ可能でも、private、no-store、no-cache、または Set-Cookie ヘッダーの Cache-Control レスポンスヘッダーがある場合、キャッシュに保存されません。

キャッシュ TTL を構成する

有効期間（TTL）オーバーライドを使用すると、キャッシュに保存されたコンテンツのデフォルト TTL 値を設定し、max-age および s-maxage キャッシュ制御ディレクティブ（または Expires ヘッダー）に設定された TTL 値をオーバーライドできます。

オーバーライドによって設定されるか、キャッシュディレクティブによって設定されるかに関係なく、TTL は楽観的です。ほとんどアクセスされない、または人気のないコンテンツは、TTL に達する前にキャッシュから削除される可能性があります。

TTL には次の 3 つの設定があります。

設定	Default	最小	最大	説明	該当するキャッシュモード
Default TTL	1 時間（3,600 秒）	0秒	1 年（31,536,000 秒）	送信元で `max-age` または `s-maxage` が指定されていない場合に設定される TTL。送信元で `s-maxage` ヘッダーが指定されている場合は、ここでデフォルトの TTL 値の代わりに使用されます。 `FORCE_CACHE_ALL` を使用してすべてのレスポンスを無条件にキャッシュに保存する場合は、デフォルトの TTL を使用してキャッシュ TTL を設定します。他の値とディレクティブはすべて無視されます。	`CACHE_ALL_STATIC` `FORCE_CACHE_ALL`
Max TTL	1 日（86,400 秒）	0秒	1 年（31,536,000 秒）	許可する最大 TTL。この上限を超える値は、`maxTtl` の値に制限されます。	`CACHE_ALL_STATIC`
Client TTL	デフォルトでは設定されません。	0秒	1 か月（2,592,000 秒）	ダウンストリーム（クライアントに対する）レスポンスで設定される TTL。他の TTL 値と異なる値にする必要がある場合。これは成功（2xx）レスポンスにのみ適用されます。	`CACHE_ALL_STATIC` `FORCE_CACHE_ALL`

TTL 値はゼロ（0 秒）に設定すると、レスポンスが処理される前にすべてのリクエストが送信元と再検証され、過度に広く設定すると送信元の負荷が増加します。

キャッシュモードを [送信元ヘッダーを使用する] に設定すると、Media CDN は動作の駆動を送信元に依存するため、TTL 設定を構成することはできません。

注:

TTL の最大値は、常にデフォルトの TTL の値以上である必要があります。
クライアント TTL の値は、常に最大 TTL の値以下である必要があります。
メディア CDN が送信元の TTL 値をオーバーライドすると、クライアントへの Cache-Control ヘッダーにもその値が反映されます。
送信元が Expires ヘッダーを設定し、Media CDN が（タイムスタンプに基づいて）有効な TTL をオーバーライドすると、Expires ヘッダーは、クライアントへのダウンストリームレスポンスの Cache-Control ヘッダーに置き換えられます。

ネガティブキャッシュ

ネガティブキャッシュは、不成功の HTTP ステータスコード（2xx 以外）が Media CDN によってキャッシュに保存される方法を定義します。

これにより、リダイレクト（HTTP 301 と 308）や未検出（HTTP 404）レスポンスなどのエラーレスポンスをユーザーのより近くにキャッシュできます。また、レスポンスの変更の可能性が低くキャッシュ可能な場合は、送信元の負荷をより大きく軽減できます。

デフォルトでは、ネガティブキャッシュは無効になっています。次の表に、ネガティブキャッシュが有効で、negativeCachingPolicy が使用されていない場合の各ステータスコードのデフォルト値を示します。

ステータスコード	Reason-phrase	TTL
HTTP 300	複数の選択肢があります	10 分
HTTP 301 と HTTP 308	恒久的なリダイレクトです	10 分
HTTP 404	見つかりませんでした	120 秒
HTTP 405	メソッドが見つかりません	60 秒
HTTP 410	Gone	120 秒
HTTP 451	法律上の理由で利用できません	120 秒
HTTP 501	実装されていません	60 秒

ネガティブキャッシュコードのデフォルトのセットは、HTTP RFC 9110 で説明されているヒューリスティックなキャッシュ可能なステータスコードと一致しますが、次の例外があります。

HTTP コード 414（Not Found）は、キャッシュの汚染を避けるため、キャッシュではサポートされていません。
HTTP RFC 7725 で説明されているように、HTTP コード 451（法的理由で利用不可）はキャッシュでサポートされています。

独自のステータスごとのコード TTL を構成し、デフォルトの動作をオーバーライドする必要がある場合は、cdnPolicy.negativeCachingPolicy を構成できます。これにより、Media CDN で許可されるステータスコード（300、301、302、307、308、400、403、404、405、410、451、501）に対して TTL を設定できます。

たとえば、HTTP 404（Not Found）レスポンスに 5 秒という短い TTL を設定し、HTTP 405（Method Not Allowed）レスポンスに 10 秒の TTL を設定するには、適用可能なそれぞれのルートに次の YAML 定義を使用します。

cdnPolicy:
  negativeCaching: true
  negativeCachingPolicy:
    "404": 5s
    "405": 10s
  # other status codes to apply TTLs for

キャッシュの汚染を防ぐために、ステータスコード 400（Bad Request)）と 403（Forbidden）のいずれかに対してキャッシュを有効にすることはおすすめしません。キャッシュキーに含まれるリクエストのコンポーネントのみを調べて、送信元サーバーがいずれかのコードを返すようにします。キャッシュポイズニングは、たとえば送信元サーバーが、正しい Authorization ヘッダーがない場合に 403 エラーレスポンスを返した場合に発生します。この場合、403 エラーレスポンスをキャッシュに保存すると、リクエストが正しい Authorization ヘッダーを持っていても、TTL が切れるまで、Media CDN は後続のすべてのリクエストに対して 403 エラーレスポンスを配信します。

ネガティブキャッシュを無効にするには:

デフォルトのネガティブキャッシュ動作を無効にするには、ルートに cdnPolicy.negativeCaching: false を設定します。有効なキャッシュディレクティブとキャッシュ可能なステータスコードが指定された送信元のレスポンスは、引き続きキャッシュに保存されます。
特定のステータスコードのネガティブキャッシュを回避しながら、送信元のキャッシュディレクティブを遵守するには、negativeCachingPolicy 定義のステータスコード（cdnPolicy.negativeCachingPolicy[].code）を省略します。
特定のステータスコードの送信元キャッシュディレクティブを明示的に無視するには、そのステータスコードの cdnPolicy.negativeCachingPolicy[].ttl を 0（ゼロ）に設定します。

注:

ルートで negativeCaching が有効で、レスポンスに有効なキャッシュディレクティブが定義されている場合、レスポンスのキャッシュディレクティブが優先されます。
明示的な negativeCachingPolicy を構成し、指定されたステータスコードに TTL が定義されている場合、ポリシーで定義された TTL が常に使用されます。
negativeCachingPolicy によって設定される TTL の最大値は 1,800 秒（30 分）ですが、TTL の大きい送信元キャッシュディレクティブが優先されます。
キャッシュモードが FORCE_CACHE_ALL として構成されている場合、送信元のディレクティブはすべて無視されます。

キャッシュキー

リクエストを個別に識別し、リクエスト間で頻繁に変更されるコンポーネントを取り除くことで、Media CDN が送信元に問い合わせる回数を減らすことができます。この一連のリクエストコンポーネントは、「キャッシュキー」と呼ばれます。

以降のセクションでは、キャッシュキーの構成方法について説明します。

キャッシュキーのコンポーネント

キャッシュキーは、キャッシュされたオブジェクトが参照される一連のリクエストパラメータ（ホスト、パス、クエリパラメータなど）です。

デフォルトでは、エッジキャッシュサービスのキャッシュキーには、リクエストホスト、リクエストのパスパラメータ、クエリパラメータが含まれ、スコープは特定の EdgeCacheService に設定されます。

コンポーネント	デフォルトで含まれていますか？	詳細
[Protocol]	なし	HTTP と HTTPS 経由のリクエストは、同じキャッシュオブジェクトを参照します。 http リクエストと https リクエストに異なるレスポンスを返すには、関連付けられたルートで `cacheKeyPolicy.includeProtocol` を true に設定します。
ホスト	あり	異なるホストは同じキャッシュオブジェクトを参照しません。同じ EdgeCacheService に関連付けられた複数のホスト名があり、同じコンテンツを提供している場合は、`cdnPolicy.excludeHost` を true に設定します。
[Path]	あり	常にキャッシュキーに含まれ、削除できません。パスは、キャッシュ内のオブジェクトの最小表現です。
クエリパラメータ	あり	クエリパラメータでレスポンスを区別できない場合は、`cacheKeyPolicy.excludeQueryString` を true に設定します。キャッシュキーにクエリパラメータだけを含める必要がある場合は、必要に応じて `includedQueryParameters` または `excludedQueryParameters` を設定します。
ヘッダー	なし	`cacheKeyPolicy.includedHeaderNames` には、キャッシュキーに含めるヘッダーの名前を設定します。結合されて幅広い値の範囲を持つ複数のヘッダーを指定すると（たとえば、結合されたヘッダー値が単一のユーザーを識別する）、キャッシュのヒット率が劇的に低下し、エビクション率が高くなり、パフォーマンスが低下します。ヘッダーの追加について詳しくは、ヘッダーの追加をご覧ください。
Cookie	なし	`cacheKeyPolicy.includedCookieNames` を、キャッシュキーに含める Cookie の名前に設定します。結合されて幅広い値の範囲を持つ複数のヘッダーを指定すると（たとえば、結合された Cookie の値が 1 人のユーザーを識別する）、キャッシュのヒット率が劇的に低下し、エビクション率が高くなり、パフォーマンスが低下します。 Cookie を含める方法について詳しくは、Cookie を含めるをご覧ください。

キャッシュキーは次のとおりです。

構成された送信元に接続されていないため、キャッシュを「フラッシュ」する（たとえば、プロバイダ間で送信元のストレージを移行する場合など）ことなく、送信元の構成を更新（または送信元を完全に置き換える）することができます。
EdgeCacheService に対して制約があります。キャッシュの名前空間は EdgeCacheService ごとに異なるため、ホスト、パス、その他のキャッシュキーコンポーネントが一致する場合でも、本番環境、ステージング環境、その他のテスト環境間で誤ってオブジェクトをキャッシュすることがなくなります。
EdgeCacheService を削除すると、そのサービスのキャッシュに保存されたオブジェクトがすべて無効になります。
個々のルートにスコープ設定されません。複数のルートが同じキャッシュキーを参照することがあります。特に、ルートがキャッシュキーに含まれていないコンポーネント（リクエストヘッダーや除外パラメータなど）で一致する場合が該当します。これは、複数のルートが同じキャッシュを共有しながら、異なるレスポンスヘッダーまたは CORS 構成を返す場合に役立ちます。
URL の書き換えの構成を含めないでください（たとえば、キャッシュキーは最後の「書き換え」リクエストではなく、ユーザー向けリクエストに基づいています）。
署名付きリクエストがルートで構成されている場合、署名付き属性はキャッシュキーに含まれません。リクエストは、edge-cache-token で始まり、次のパス区切り文字（/）で終わる（署名付きの）クエリパラメータまたはパスコンポーネントは URL の一部ではないものとして処理されます。

クエリパラメータを含める、または除外する

キャッシュキーに特定のクエリパラメータを含める、または除外するには、特定のルートの includedQueryParameters または excludedQueryParameters キャッシュキーの構成にパラメータ名を追加します。

たとえば、contentID および country クエリパラメータを含めて、キャッシュキーから他のすべてを無視するには、次のようにします。

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    includedQueryParameters: ["contentID", "country"]

コンテンツを一意に識別するクエリパラメータを指定し、含まれていないパラメータを除外します。たとえば、分析クエリパラメータ、再生セッション ID、その他のクライアント固有のパラメータを除外します。必要以上にクエリパラメータを含めると、キャッシュヒット率が低下する可能性があります。

キャッシュキーに含めるパラメータを指定する代わりに、キャッシュキーから除外するパラメータを選択することもできます。たとえば、クライアント固有の再生 ID とタイムスタンプ情報をキャッシュキーから除外するには、次のように構成します。

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    excludedQueryParameters: ["playback-id", "timestamp"]

特定のルートに対して、includedQueryParameters または excludedQueryParameters のいずれかを指定できます。

複数のリクエストにわたってコンテンツを一意に識別する目的でクエリパラメータを使用していない場合、ルートのキャッシュキーからすべてのクエリパラメータを削除できます。次のように excludeQueryString を true に設定します。

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    excludeQueryString: true

ルートで署名付きリクエストが有効の場合、署名に使用されるクエリパラメータはクエリ文字列に含まれず、無視されます。署名付きキーをキャッシュキーに含めると、各ユーザーリクエストが実質的に一意になり、各リクエストは送信元から提供する必要があります。

クエリパラメータの並べ替え

クエリパラメータ（クエリ文字列）は、キャッシュヒット率を向上させるためにデフォルトで並べ替えられます。これは、クライアントがクエリパラメータを異なる順序に並べ替えたり、同じクエリオブジェクトをリクエストしたりすることがあるためです。

たとえば、キャッシュキーが取得される前は、クエリパラメータ b=world&a=hello&z=zulu&p=paris と p=paris&a=hello&z=zulu&b=world は a=hello&b=world&p=paris&z=zulu として並べ替えられます。これにより、両方のリクエストを同じキャッシュオブジェクトにマッピングできるため、送信元への不要なリクエスト（および送信元からのレスポンス）を回避できます。

クエリパラメータキーのインスタンスが複数あり、それぞれに異なる値がある場合、パラメータは完全な値で並べ替えられます（たとえば、a=hello は a=world よりも前に並べ替えられます）。並べ替えを無効にすることはできません。

ヘッダーを含める

ヘッダー名では大文字と小文字が区別されません。メディア CDN によって小文字に変換されます。

キャッシュキーに次のヘッダーを含めることはできません。

access-control- で始まるヘッダー
sec-fetch- で始まるヘッダー
x-amz- で始まるヘッダー
x-goog- で始まるヘッダー
x-media-cdn- で始まるヘッダー
accept-encoding
accept
authorization
cdn-loop
connection
content-md5
content-type
cookie
date
forwarded
from
host
if-match
if-modified-since
if-none-match
origin
proxy-authorization
range
referer
referrer
user-agent
want-digest
x-csrf-token
x-csrftoken
x-forwarded-for

キャッシュキーに HTTP メソッドを含めるには、特別なヘッダー名 :method を使用します。

Cookie を含める

Cookie 名では大文字と小文字が区別されます。

大文字または小文字にかかわらず edge-cache- で始まる Cookie は、キャッシュキーでは使用できません。

再検証、エビクション、有効期限

Media CDN などのコンテンツ配信ネットワークは、特に人気のあるコンテンツを可能な限りユーザーの近くのキャッシュに保存することで機能します。

Media CDN の広範なストレージと送信元のシールドにより、人気のないコンテンツも削除する必要はありません。1 日に数回アクセスされるコンテンツは、最終的には強制排除される可能性があります。

構成された TTL に達したキャッシュレスポンスは、すぐに削除されないことがあります。一般的なコンテンツの場合、Media CDN は、If-None-Match または If-Modified-Since リクエストヘッダーを使用して送信元にリクエストを発行し、キャッシュに保存されているレスポンスが最新バージョンであることを検証します。
正しく構成された送信元は、キャッシュにレスポンスの「最新」コピーがある場合、本文バイトなしで HTTP 304（Not Modified）レスポンスを返します。
max-age または s-maxage キャッシュディレクティブを設定するレスポンス、または TTL オーバーライドを使用して高い TTL 値（例: 30 日）を指定するレスポンスは、TTL 全期間にわたるキャッシュ格納ができない場合があります。特にアクセス頻度が低い場合、オブジェクトがキャッシュに全期間にわたって格納される保証はありません。

エビクション率が高い場合は、レスポンスを一意に識別しないパラメータを除外するようにキャッシュキーを構成していることを確認してください。

その他の考慮事項

`Vary` ヘッダー

Vary ヘッダーがある場合は、クライアントのリクエストヘッダーに応じてレスポンスが異なります。Vary ヘッダーがレスポンスに含まれている場合は、次のいずれかの値を指定する必要があります。指定しなかった場合、Media CDN はレスポンスをキャッシュに保存しません。

Accept: クライアントが受け入れるコンテンツタイプを示すために使用します
Accept-Encoding: クライアントが受け入れる圧縮タイプを示すために使用します
送信元: 通常はクロスオリジンリソースシェアリングに使用されます。

Media CDN は、レスポンスに Vary ヘッダーを含むレスポンスをキャッシュに保存します。その際、ヘッダーの値をキャッシュキーの一部として使用します。レスポンスの Vary ヘッダーに複数の値がある場合は、辞書順で並べ替えられ、キャッシュキーは確定的になります。

Media CDN は、特定のキャッシュキーに対して最大 100 個のバリアントをキャッシュします。この上限を超えるバリアントはキャッシュからランダムに削除します。指定した URL またはキャッシュタグのキャッシュを明示的に無効化すると、すべてのバリアントが無効になります。

キャッシュのバイパス

一致したリクエストのキャッシュを意図的にバイパスするよう、ルートに BYPASS_CACHE キャッシュモードを構成できます。これは、重要性の低いトラフィックのごく一部でキャッシュをバイパスする必要がある場合や、送信元の接続をデバッグする必要がある場合に役立ちます。

API バックエンドなどの動的レスポンスを提供する必要がある場合、外部 HTTP(S) ロードバランサを構成するようおすすめします。

通常、意図しない送信元の負荷を回避するため、デバッグシナリオのみを使用することをおすすめします。キャッシュをバイパスする下り（外向き）トラフィックは、インターネット下り（外向き）料金に基づいて課金されます。

キャッシュの無効化

キャッシュの無効化をご覧ください。

Byte-range requests

Media CDN は、RFC 7233 で定義されている HTTP Range リクエスト（単一パート範囲リクエストや複数バイト範囲を含む）をサポートしています。

さらに、Media CDN は楽観的に範囲リクエストを使用して、送信元からより大きなコンテンツを取得します。これにより、Media CDN は個々のチャンクをキャッシュに保存できます。キャッシュ全体を取得するためにオブジェクト全体を一度にフェッチする必要はありません。

2 MB を超えるオブジェクトはバイト範囲リクエスト（「チャンク」）として取得されます。
送信元でのバイト範囲のサポートなしで、最大 2 MB のレスポンスを取得できます。
これより大きいレスポンスは、送信元でバイト範囲がサポートされていないと処理されません。

バイト範囲リクエストの送信元のサポートは、以下によって決まります。

200（OK）または 206（部分的なコンテンツ）の HTTP ステータスコード。
Accept-Ranges: bytes レスポンスヘッダー。
有効な Content-Length または Content-Range レスポンスヘッダー。

各チャンク（バイト範囲）に対する個々の送信元フィルリクエストは、個別のログエントリとしてログに記録され、親クライアントリクエストに関連付けられます。これらのリクエストは、jsonPayload.cacheKeyFingerprint での一致したリクエストでグループ化できます。

ログに記録される内容の詳細については、Cloud Logging のドキュメントをご覧ください。

制限のない範囲リクエスト

Media CDN は、リクエストが送信元によって閉じられるか（例: 送信元による全バイトの書き込み完了）タイムアウトするまで、送信元に対する「制限のない」範囲リクエスト（例: Range: bytes=0- を含むリクエスト）をサポートしています。

制限のないバイト範囲は、通常、Apple の低レイテンシの HLS セグメントをリクエストするクライアントによって使用されます。各 CMAF チャンクは最後まで書き込まれるため、CDN はそのチャンクをキャッシュに保存してクライアントに配信できます。

その他の場合（DASH との相互運用が必要ない場合など）、メディアプレイリストはプレーヤーに対し各チャンクを表すバイトを伝えます。

  #EXTINF:4.08,
  fs270.mp4
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=20000@0
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=23000@20000
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=18000@43000
  #EXT-X-PRELOAD-HINT:TYPE=PART,URI="fs271.mp4",BYTERANGE-START=61000

EdgeCacheOrigin.timeouts.readTimeout 構成値を使用して、メディア CDN が読み込み間で待機する時間を構成できます。通常は、ターゲット期間の倍数（たとえば 2 倍）に構成します。

マルチパートバイト範囲

具体的には、マルチパート範囲リクエスト（bytes=0-300,1200-2000 など）は次の要件を満たす必要があります。

HTTP RFC 7233 に準拠している必要があります。
範囲は昇順にする必要があります。
1 回のリクエストで最大 2 つの範囲を指定できます。

Cloud Storage や Amazon S3 などのほとんどのオブジェクトストアはマルチパート範囲リクエストを直接サポートしておらず、エラーを返すか、暗黙的にオブジェクト全体を返します。Varnish を含む、一般的なリバースプロキシとキャッシュプロキシも、マルチパート範囲リクエストをサポートしていません。

次のステップ

高度なルーティングを確認する。
さまざまな送信元に接続する方法を理解する。
サービスの TLS（SSL）証明書を設定する。
コンテンツへのアクセスを認証するように署名付きリクエストを構成する。