Media CDN は、Google のグローバル エッジ キャッシング インフラストラクチャを使用してコンテンツをキャッシュに保存し、送信元インフラストラクチャの負荷を軽減することで、可能な限りユーザーに近い場所からコンテンツを配信します。
コンテンツをルートごとにキャッシュに保存する方法を制御できます。これにより、コンテンツの種類、クライアント リクエストの属性、鮮度の要件に基づいて動作を最適化できます。
キャッシュへの保存
以下のセクションでは、Media CDN がキャッシュに保存するレスポンスとキャッシュ オフロードを改善する方法について説明します。
デフォルトのキャッシュ動作
デフォルトでは、次のキャッシュ関連の設定が各 Edge Cache Service に適用されます。
CACHE_ALL_STATICのデフォルトのキャッシュ モード:Cache-ControlやExpiresなどの送信元のキャッシュ ディレクティブを、構成可能な最大 TTL まで考慮します。- 送信元のキャッシュ ディレクティブが存在しない場合、静的メディアタイプをデフォルトの TTL の 3, 600 秒で自動的にキャッシュに保存します。
- HTTP 200 および 206 ステータス コードをキャッシュに保存します（ネガティブ キャッシュは有効になっていません）。
no-storeまたはprivateキャッシュ制御ディレクティブが設定されているレスポンス、またはそれ以外の方法でキャッシュできないレスポンスはキャッシュに保存しません。
静的コンテンツではないレスポンス、または有効なキャッシュ ディレクティブがないレスポンスは、キャッシュが明示的に構成されていない限り、キャッシュに保存されません。デフォルトの動作をオーバーライドする方法については、キャッシュ モードに関するドキュメントをご覧ください。
デフォルトの動作は次の 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 レスポンスをキャッシュに保存するための要件を示したものです。GET と HEAD の両方のレスポンスが、これらの要件に準拠している必要があります。
| HTTP 属性 | 要件 |
|---|---|
| ステータス コード | レスポンス ステータス コードは、200、203、206、300、301、302、307、308、400、403、404、405、410、451、500、501、502、503、504 のいずれかである必要があります。 |
| HTTP メソッド | GET と HEAD |
| リクエスト ヘッダー | ほとんどのキャッシュ リクエスト ディレクティブは無視されます。詳細については、キャッシュ制御ディレクティブをご覧ください。 |
| レスポンス ヘッダー | 有効な HTTP キャッシュ ディレクティブを含む（ そのコンテンツをキャッシュするキャッシュ モードがある。または、将来の日付の |
| レスポンス サイズ | 最大 100 GiB。 |
HTTP Age ヘッダーは、メディア CDN がレスポンスを最初にキャッシュに保存したタイミングに基づいて設定されます。通常は、オブジェクトが送信元シールディングのロケーションでキャッシュに保存された時点からの秒数を表します。送信元で Age レスポンス ヘッダーが生成される場合は、FORCE_CACHE_ALL キャッシュ モードを使用して、Age がキャッシュ TTL を超えたときに再検証されないようにします。
Media CDN による HTTP キャッシュ ディレクティブの解釈の詳細については、キャッシュ制御ディレクティブをご覧ください。
送信元の要件
Media CDN が 1 MiB を超える送信元のレスポンスをキャッシュに保存できるようにするには、指定されていない限り、送信元に HEAD リクエストと GET リクエストの両方のレスポンス ヘッダーに以下を含める必要があります。
Last-ModifiedまたはETagHTTP レスポンス ヘッダー（バリデータ）。- 有効な HTTP
Dateヘッダー。 - 有効な
Content-Lengthヘッダー。 Range GETリクエストに対するContent-Rangeレスポンス ヘッダー。Content-Rangeヘッダーには、bytes x-y/zの形式で有効な値が必要です（zはオブジェクト サイズ）。
デフォルトの送信元プロトコルは HTTP/2 です。送信元が HTTP/1.1 のみをサポートしている場合は、送信元ごとにプロトコル フィールドを明示的に設定できます。
キャッシュに保存不可のレスポンス
次の表に、レスポンスがキャッシュされないリクエスト属性とレスポンス属性を示します。キャッシュ可能でも「キャッシュ不可」の条件に一致するレスポンスはキャッシュに保存されません。
| HTTP 属性 | 要件 |
|---|---|
| ステータス コード | キャッシュ可能として定義されているもの以外のステータス コード（HTTP 401、HTTP 412、HTTP 505 など）。 これらのステータス コードは一般的に、クライアント側の問題を表しており、送信元のステータスではありません。これらのレスポンスをキャッシュに保存すると、次のような「キャッシュ汚染」シナリオが発生する可能性があります。このシナリオでは、ユーザーがトリガーした「不正な」レスポンスがすべてのユーザーについてキャッシュに保存されます。 |
| リクエスト ヘッダー |
リクエスト内の |
| レスポンス ヘッダー |
特定条件
|
| レスポンス サイズ | 100 GiB より大きい。 |
これらのルールは、構成されたキャッシュ モードに加えて適用されます。 特に、以下の点に注意してください。
CACHE_ALL_STATICキャッシュ モードを構成すると、静的コンテンツとみなされるレスポンス、またはレスポンス ヘッダーに有効なキャッシュ ディレクティブを含むレスポンスのみがキャッシュに保存されます。他のレスポンスはそのままプロキシされます。FORCE_CACHE_ALLキャッシュ モードでは、前述のキャッシュ不可の要件に従って、すべてのレスポンスを無条件にキャッシュに保存します。USE_ORIGIN_HEADERSキャッシュ モードの場合、レスポンスは、キャッシュ可能なステータス コードだけでなく、レスポンス ヘッダーに有効なキャッシュ ディレクティブを設定する必要があります。
注:
- キャッシュに保存されていないレスポンスはキャッシュ制御ディレクティブやその他のヘッダーは変更されず、そのままプロキシされます。
- レスポンスは、
Cache-ControlとExpiresのヘッダーを 1 つのCache-Controlフィールドに折りたたんで表示できます。たとえば、Cache-Control: publicとCache-Control: max-age=100が別々の行に記述されているレスポンスは、Cache-Control: public,max-age=100として折りたたまれます。 - キャッシュできないレスポンス（決してキャッシュされないレスポンス）は、課金の観点からは
Cache Egressとしてカウントされません。
キャッシュ モードの使用
キャッシュ モードでは、ディレクティブの設定にかかわらず、Media CDN が送信元 CDN ディレクティブを遵守し、静的メディア タイプをキャッシュに保存し、送信元からのすべてのレスポンスをキャッシュに保存するタイミングを構成できます。
キャッシュ モードはルートレベルで構成され、TTL オーバーライドと組み合わせることで、ホスト、パス、クエリ パラメータ、ヘッダー（一致する任意のリクエスト パラメータ）ごとにキャッシュの動作を構成できます。
- デフォルトでは、Media CDN は
CACHE_ALL_STATICキャッシュ モードを使用します。このモードでは、一般的な静的メディアタイプを 1 時間（3,600 秒間）自動的にキャッシュに保存しながら、キャッシュに保存可能なレスポンスに対してオリジンによって指定されたキャッシュディレクティブを優先します。 - ルートに
cdnPolicy.defaultTtlフィールドを設定すると、明示的にキャッシュ TTL が設定されていないレスポンスに適用されるキャッシュ TTL（max-ageまたはs-maxageディレクティブ）を増減できます。 - 不成功のレスポンスが意図したよりも長くキャッシュされないよう、2xx 以外（不成功）のステータス コードは
Content-Type（MIME タイプ）に従ってキャッシュに保存されず、デフォルトの適用された TTL がありません。
次の表に、各ルートの cdnPolicy.cacheMode で設定されるキャッシュ モードを示します。
| キャッシュ モード | 動作 |
|---|---|
USE_ORIGIN_HEADERS |
有効なキャッシュ ディレクティブと有効なキャッシュ ヘッダーを設定するには、送信元のレスポンスが必要です。要件の一覧については、キャッシュに保存可能なレスポンスをご覧ください。 |
CACHE_ALL_STATIC |
|
FORCE_CACHE_ALL |
成功したレスポンスを無条件にキャッシュに保存し、送信元で設定されたすべてのキャッシュ ディレクティブをオーバーライドします。 このモードで構成されている、ユーザー単位のプライベート コンテンツ（ダイナミック HTML や API レスポンスなど）は提供しないでください。 |
| BYPASS_CACHE | このキャッシュ モードが構成されているルートに一致するリクエストは、そのキャッシュキーに一致するキャッシュ オブジェクトがある場合でも、キャッシュをバイパスします。 Media CDN は汎用プロキシではなく、グローバル キャッシュ インフラストラクチャとして設計されているため、デバッグにのみ使用することをおすすめします。 |
静的コンテンツの MIME タイプ
CACHE_ALL_STATIC キャッシュ モードを使用すると、Media CDN は、Content-Type HTTP レスポンスで返された MIME タイプに基づいて、動画、音声、画像、一般的なウェブアセットなどの一般的な静的コンテンツを自動的にキャッシュに保存できます。ただし、メディアタイプに関係なく、Media CDN は送信元のレスポンス内の明示的な Cache-Control または Expires ヘッダーを優先します。
次の表に、CACHE_ALL_STATIC キャッシュ モードで自動的にキャッシュに保存できる MIME タイプを示します。
次の値と一致する値を含む Content-Type レスポンス ヘッダーがない場合、レスポンスは自動的にはキャッシュに保存されません。レスポンスで有効なキャッシュ ディレクティブが設定されていることを確認するか、FORCE_CACHE_ALL キャッシュ モードを使用してレスポンスを無条件にキャッシュに保存する必要があります。
| カテゴリ | 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 コンソールまたは gcloud CLI を使用してコンテンツをアップロードすると、Cloud Storage により
Content-Typeヘッダーがアップロード時に自動的に設定されます。 - レスポンスが MIME タイプに基づいてキャッシュ可能でも、
private、no-store、またはSet-CookieヘッダーのCache-Controlレスポンス ヘッダーがある場合、キャッシュに保存されません。
キャッシュ TTL を構成する
有効期間（TTL）オーバーライドを使用すると、キャッシュに保存されたコンテンツのデフォルト TTL 値を設定し、max-age および s-maxage キャッシュ制御ディレクティブ（または Expires ヘッダー）に設定された TTL 値をオーバーライドできます。
TTL は、オーバーライドによって設定されるか、キャッシュ ディレクティブを使用するかにかかわらず、楽観的です。アクセス頻度が低いコンテンツや人気のないコンテンツは、TTL に達する前にキャッシュから削除される場合があります。
次の表に、3 つの TTL 設定を示します。
| 設定 | デフォルト | 最小 | 最大 | 説明 | 該当するキャッシュ モード |
|---|---|---|---|---|---|
| Default TTL | 1時間 （3600秒） |
0 秒 | 1 年 （31,536,000 秒） |
送信元が 送信元で
|
|
| Max TTL | 1 日 （86,400 秒） |
0 秒 | 1 年 （31,536,000 秒） |
キャッシュ可能なレスポンスに対して許可される最大 TTL。これより大きい値は、maxTtl の値に制限されます。 |
CACHE_ALL_STATIC |
| Client TTL | デフォルトでは設定されません | 0 秒 | 1 日 （86,400 秒） |
キャッシュ可能なレスポンスで、他の TTL 値とは異なる必要がある場合に、ダウンストリーム（クライアント向け）レスポンスで許可される最大 TTL。 |
|
TTL 値はゼロ（0 秒）に設定すると、レスポンスが処理される前にすべてのリクエストが送信元と再検証され、過度に広く設定すると送信元の負荷が増加します。
キャッシュ モードを Use Origin Headers に設定すると、Media CDN は動作の駆動を送信元に依存するため、TTL 設定を構成することはできません。
注:
- TTL の最大値は、常にデフォルトの TTL の値以上にする必要があります。
- クライアント TTL の値は、常に TTL の上限よりも小さい（または同じ）必要があります。
- Media 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 | 存在しません | 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、500、501、502、503、504）に 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として構成されている場合、すべての場合に送信元ディレクティブは無視されます。
キャッシュ制御ディレクティブ
Cache-Control ディレクティブに関する Media CDN の動作は、ここで定義されます。
ディレクティブが only-if-cached（クライアントのみのディレクティブ）のようにリクエストまたはレスポンスに適用できない場合、その列には「該当なし」とマークされます。
| ディレクティブ | リクエスト | レスポンス |
|---|---|---|
no-cache |
no-cache リクエスト ディレクティブは無視され、クライアントが送信元に対する再検証を開始または強制する可能性が回避されます。 |
この設定は、ルートごとに |
no-store |
no-store を含むリクエストに対するレスポンスはキャッシュに保存されません。 |
この設定は、ルートごとに |
public |
なし |
|
private |
なし |
この設定は、ルートごとに レスポンスのキャッシュへの保存をすべて回避するには、 |
max-age=SECONDS |
max-age リクエスト ディレクティブは無視されます。キャッシュに保存されたレスポンスは、このヘッダーがリクエストに含まれていない場合と同様に返されます。 | max-age ディレクティブを含むレスポンスは、最大で SECONDS までキャッシュに保存されます。 |
s-maxage=SECONDS |
なし |
|
min-fresh=SECONDS |
min-fresh リクエスト ディレクティブは無視されます。キャッシュに保存されたレスポンスは、このヘッダーがリクエストに含まれていない場合と同様に返されます。 |
なし |
max-stale=SECONDS |
キャッシュに保存されたレスポンスは、このヘッダーがリクエストに含まれていない場合と同様に返されます。 |
なし |
stale-while-revalidate=SECONDS |
なし | 影響なし。これは、レスポンスでクライアントに渡されます。 |
stale-if-error=SECONDS |
stale-if-error リクエスト ディレクティブは無視されます。キャッシュに保存されたレスポンスは、このヘッダーがリクエストに含まれていない場合と同様に返されます。 |
影響なし。これは、レスポンスでクライアントに渡されます。 |
must-revalidate |
なし |
|
proxy-revalidate |
なし |
|
immutable |
なし | 影響なし。これは、レスポンスでクライアントに渡されます。 |
no-transform |
なし | Media CDN で変換は適用されません。 |
only-if-cached |
only-if-cached リクエスト ディレクティブは無視されます。キャッシュに保存されたレスポンスは、このヘッダーがリクエストに含まれていない場合と同様に返されます。 |
なし |
可能な場合については、Media CDN が RFC に準拠（HTTP RFC 7234）しますが、キャッシュ オフロードの最適化、ヒット率または全般的な送信元負荷に対してクライアントが与える可能性がある影響を最小限に抑えることを優先します。
HTTP/1.1 Expires ヘッダーを使用するレスポンスの場合:
Expiresヘッダーの値は、RFC 7231 で定義されている有効な HTTP 日付であることが必要です。- 過去の日付値、無効な日付、または
0の値は、コンテンツがすでに期限切れになっており、再検証が必要であることを示します。 - レスポンスに
Cache-Controlヘッダーがある場合、Media CDN はExpiresヘッダーを無視します。
HTTP/1.0 Pragma ヘッダーがレスポンスに存在する場合は無視され、そのままクライアントに渡されます。
キャッシュキー
リクエストを個別に識別し、リクエスト間で頻繁に変更されるコンポーネントを取り除くことで、Media CDN が送信元に問い合わせる回数を減らすことができます。リクエスト コンポーネントのセットは多くの場合、「キャッシュキー」と呼ばれます。
以降のセクションでは、キャッシュキーの構成方法について説明します。
キャッシュキーのコンポーネント
キャッシュキーは、キャッシュされたオブジェクトが参照される一連のリクエスト パラメータ（ホスト、パス、クエリ パラメータなど）です。
デフォルトでは、エッジ キャッシュ サービスのキャッシュキーには、リクエスト ホスト、リクエストのパスパラメータ、クエリ パラメータが含まれ、スコープは特定の EdgeCacheService に設定されます。
| コンポーネント | デフォルトで含まれます。 | 詳細 |
|---|---|---|
| プロトコル | いいえ | HTTP と HTTPS を介したリクエストは、キャッシュ内の同じオブジェクトを参照します。 http: リクエストと https: リクエストに対して異なるレスポンスを返すには、関連するルートで |
| ホスト | ○ | 異なるホストがキャッシュ内の同じオブジェクトを参照することはありません。 複数のホスト名が同じ EdgeCacheService に転送され、同じコンテンツを配信する場合は、 |
| [Path] | ○ | 常にキャッシュキーに含まれており、削除できません。パスは、キャッシュ内のオブジェクトの最小表現です。 |
| クエリ パラメータ | ○ | クエリ パラメータが異なるレスポンスを区別しない場合は、 一部のクエリ パラメータのみをキャッシュキーに含める場合は、必要に応じて |
| ヘッダー | いいえ |
結合されて幅広い値の範囲を持つ複数のヘッダーを指定すると（たとえば、結合されたヘッダー値が単一のユーザーを識別する）、キャッシュのヒット率が劇的に低下し、エビクション率が高くなり、パフォーマンスが低下します。 |
| Cookie | いいえ |
結合されて幅広い値の範囲を持つ複数のヘッダーを指定すると（たとえば、結合された Cookie の値が 1 人のユーザーを識別する）、キャッシュのヒット率が劇的に低下し、エビクション率が高くなり、パフォーマンスが低下します。 |
次の点にご注意ください。
- 構成された送信元に接続されていないため、キャッシュを「フラッシュ」する（たとえば、プロバイダ間で送信元のストレージを移行する場合など）ことなく、送信元の構成を更新（または送信元を完全に置き換える）することができます。
- キャッシュキーは 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 よりも前に並べ替えられます）。並べ替えを無効にすることはできません。
ヘッダーを含める
ヘッダー名では大文字と小文字が区別されず、Media CDN によって小文字に変換されます。
次のヘッダーはキャッシュキーに含めることはできません。
access-control-で始まるヘッダーsec-fetch-で始まるヘッダーx-amz-で始まるヘッダーx-goog-で始まるヘッダーx-media-cdn-で始まるヘッダーaccept-encodingacceptauthorizationcdn-loopconnectioncontent-md5content-typecookiedateforwardedfromhostif-matchif-modified-sinceif-none-matchoriginproxy-authorizationrangerefererreferreruser-agentwant-digestx-csrf-tokenx-csrftokenx-forwarded-for
キャッシュキーに HTTP メソッドを含めるには、特別なヘッダー名 :method を使用します。
Cookie を含める
Cookie 名では大文字と小文字が区別されます。
edge-cache- で始まる Cookie のうち、大文字や小文字のバリエーションはキャッシュキーで使用できません。
再検証、エビクション、有効期限
Media CDN などのコンテンツ配信ネットワークは、人気のあるコンテンツを可能な限りユーザーの近くでキャッシュに保存することで動作します。
Media CDN の広範なストレージと送信元のシールドにより、人気のないコンテンツも削除する必要はありません。1 日に数回アクセスされるコンテンツは、最終的には強制排除される可能性があります。
- 構成された TTL に達したキャッシュ レスポンスは、すぐに強制排除されない場合があります。ポピュラー コンテンツの場合、Media CDN は、キャッシュに保存されたレスポンスが最新バージョンであることを再検証します。これを行うには、送信元に
HEADリクエストを送信し、ヘッダーが変更されていないことを確認します。状況によっては、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: クライアントが受け入れる圧縮タイプを示すために使用します。
- Available-Dictionary: 圧縮に使用できる辞書のハッシュを提供するために使用します
- Origin/X-Origin: 通常はクロスオリジン リソース シェアリングに使用されます
- X-Goog-Allowed-Resources: Google Cloud 組織内アクセス制限をサポートします。
- Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site: メタデータ リクエスト ヘッダーの取得に使用
Media CDN は、ヘッダーの値をキャッシュキーの一部として使用し、レスポンスの Vary ヘッダーを使用してレスポンスをキャッシュに保存します。レスポンスの Vary ヘッダーに複数の値がある場合は、キャッシュキーが確定的になるように辞書順に並べ替えられます。
Media CDN は、特定のキャッシュキーに対して最大 100 個のバリアントをキャッシュします。この上限を超えるバリアントはキャッシュからランダムに削除します。特定の URL またはキャッシュタグのキャッシュを明示的に無効にすると、すべてのバリアントが無効になります。
キャッシュのバイパス
一致したリクエストのキャッシュを意図的にバイパスするよう、ルートに BYPASS_CACHE キャッシュ モードを構成できます。これは、重要性の低いトラフィックのごく一部でキャッシュをバイパスする必要がある場合や、送信元の接続をデバッグする必要がある場合に役立ちます。
API バックエンドなどの動的レスポンスを提供する必要がある場合、外部アプリケーション ロードバランサを構成するようおすすめします。
通常、意図しない送信元の負荷を回避するため、デバッグ シナリオのみを使用することをおすすめします。キャッシュをバイパスするときに送信されるトラフィックには、インターネット下り（外向き）料金が適用されます。
キャッシュの無効化
キャッシュの無効化をご覧ください。
Byte-range requests
Media CDN は、RFC 7233 で定義されているシングルパート HTTP 範囲リクエストをサポートしています。
さらに、Media CDN は範囲リクエストを使用して、送信元からより大きなレスポンスを取得します。これにより、Media CDN はチャンクを個別にキャッシュに保存できます。オブジェクト全体を一度にフェッチする必要はありません。
- 1 MiB を超えるオブジェクトは、それぞれ最大 2 MiB のバイト範囲リクエスト（「チャンク」）としてフェッチされます。
- 送信元でのバイト範囲のサポートなしで、最大 1 MiB のレスポンスを取得できます。
- これより大きいレスポンスは、送信元でバイト範囲がサポートされていないと処理されません。
バイト範囲リクエストの送信元のサポートは、以下によって決まります。
- HTTP ステータス コード 200（OK）または 206（部分コンテンツ）
- 有効な
Content-LengthまたはContent-Rangeレスポンス ヘッダー。 - レスポンス検証ツール（
ETagまたはLast-Modified）。
各「チャンク」（バイト範囲）の個々の送信元フィル リクエストは、個別のログエントリとしてログに記録され、親クライアント リクエストに関連付けられます。これらのリクエストは、jsonPayload.cacheKeyFingerprint での一致したリクエストでグループ化できます。
ログに記録される内容の詳細については、Cloud Logging のドキュメントをご覧ください。
制限のない範囲リクエスト
Media CDN は、リクエストが送信元によって閉じられるか（例: 送信元による全バイトの書き込み完了）タイムアウトするまで、送信元に対する「制限のない」Rangeリクエスト（例: 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
Media CDN が読み取りを行う間隔を構成するには、EdgeCacheOrigin.timeouts.readTimeout 構成値を使用します。これは通常、ターゲット期間の倍数（たとえば 2 倍）に設定する必要があります。
次のステップ
- 高度なルーティングを確認する。
- さまざまな送信元に接続する方法を理解する。
- サービスの TLS（SSL）証明書を設定する。
- コンテンツへのアクセスを認証するように署名付きリクエストを構成する。