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 |
リクエスト ヘッダー | リクエスト ヘッダーはアイテムのキャッシュ保存には影響しません。詳細については、キャッシュ制御ディレクティブをご覧ください。 |
レスポンス ヘッダー |
|
レスポンス サイズ | 最大 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 キャッシュ制御ディレクティブを含める必要があります。詳細については、キャッシュ制御ディレクティブをご覧ください。 |
レスポンス ヘッダー |
|
レスポンス サイズ | 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 リクエストに異なるレスポンスを返すには、関連付けられたルートで |
ホスト | あり | 異なるホストは同じキャッシュ オブジェクトを参照しません。 同じ EdgeCacheService に関連付けられた複数のホスト名があり、同じコンテンツを提供している場合は、 |
[Path] | あり | 常にキャッシュキーに含まれ、削除できません。パスは、キャッシュ内のオブジェクトの最小表現です。 |
クエリ パラメータ | あり | クエリ パラメータでレスポンスを区別できない場合は、 キャッシュキーにクエリ パラメータだけを含める必要がある場合は、必要に応じて |
ヘッダー | なし |
結合されて幅広い値の範囲を持つ複数のヘッダーを指定すると(たとえば、結合されたヘッダー値が単一のユーザーを識別する)、キャッシュのヒット率が劇的に低下し、エビクション率が高くなり、パフォーマンスが低下します。 ヘッダーの追加について詳しくは、ヘッダーの追加をご覧ください。 |
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)証明書を設定する。
- コンテンツへのアクセスを認証するように署名付きリクエストを構成する。