キャッシュ動作を構成する

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

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

キャッシュへの保存

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

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

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

• CACHE_ALL_STATIC のデフォルトのキャッシュ モード:

  • 構成可能な最大 TTL まで、Cache-Control や Expires などの送信元キャッシュ ディレクティブを尊重します。
  • 送信元キャッシュ ディレクティブがない場合、静的メディア タイプを自動的にキャッシュに保存します。デフォルトの TTL は 3, 600 秒です。
  • HTTP 200、204、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 Age ヘッダーは、Media CDN がレスポンスを最初にキャッシュに保存したタイミングに基づいて設定されます。通常は、オブジェクトが送信元シールディングのロケーションでキャッシュに保存された時点からの秒数を表します。送信元で Age レスポンス ヘッダーが生成される場合は、FORCE_CACHE_ALL キャッシュ モードを使用して、Age がキャッシュ TTL を超えたときに再検証されないようにします。

Media CDN が HTTP キャッシュ ディレクティブを解釈する方法については、キャッシュ制御ディレクティブをご覧ください。

オリジンの要件

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

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

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

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

次の表に、レスポンスがキャッシュされないリクエスト属性とレスポンス属性を示します。キャッシュに保存できるレスポンスでも、「キャッシュに保存できない」基準に一致する場合はキャッシュに保存されません。

これらのルールは、構成されたキャッシュ モードに加えて適用されます。詳細は以下のとおりです。

• 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（max-age または s-maxage ディレクティブ）が設定されていないレスポンスに適用されるキャッシュ TTL を増減できます。
• 不成功のレスポンスが意図したよりも長くキャッシュされないよう、2xx 以外（不成功）のステータス コードは Content-Type（MIME タイプ）に従ってキャッシュに保存されず、デフォルトの適用された TTL がありません。

次の表に、各ルートの cdnPolicy.cacheMode で設定される使用可能なキャッシュ モードを示します。

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

CACHE_ALL_STATIC キャッシュ モードを使用すると、Media CDN は、Content-Type HTTP レスポンスで返された MIME タイプに基づいて、動画、音声、画像、一般的なウェブアセットなどの一般的な静的コンテンツを自動的にキャッシュに保存できます。ただし、メディアタイプに関係なく、Media CDN は送信元レスポンスの明示的な Cache-Control ヘッダーまたは Expires ヘッダーを優先します。

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

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

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

• 送信元のウェブサーバー ソフトウェアが各レスポンスで Content-Type を設定する必要があります。多くのウェブサーバーは、NGINX、Varnish、Apache などの Content-Type ヘッダーを自動的に設定します。
• Google Cloud コンソールまたは gcloud CLI を使用してコンテンツをアップロードすると、Cloud Storage により Content-Type ヘッダーがアップロード時に自動的に設定されます。
• Cloud Storage は常に Media CDN に Cache-Control ヘッダーを提供します。値を明示的に選択しない場合は、デフォルト値が送信されます。そのため、Cloud Storage のすべての成功レスポンスは、Cloud Storage のデフォルト値に従ってキャッシュに保存されます。ただし、Cloud Storage 内のオブジェクトに対してキャッシュ制御メタデータを明示的に制御したり、FORCE_CACHE_ALL モードを使用して Cloud Storage から送信された値をオーバーライドしたりすることもできます。

レスポンスが MIME タイプに基づいてキャッシュ可能でも、private、no-store、または Set-Cookie ヘッダーの Cache-Control レスポンス ヘッダーがある場合、キャッシュに保存されません。

HTML（text/html）や JSON（application/json）など、その他のメディア タイプはデフォルトでキャッシュに保存されません。通常、これらのタイプのレスポンスはユーザーごとに動的に行われます。また、Media CDN のアーキテクチャにも適していません。ウェブ アセットの配信と API レスポンスのキャッシュ保存には、Cloud CDN の使用をおすすめします。

キャッシュ TTL を構成する

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

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

次の表に、3 つの 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 が使用されていない場合の各ステータス コードのデフォルト値を示します。

ネガティブ キャッシュ コードのデフォルト セットは、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（クライアント専用のディレクティブ）など、ディレクティブがリクエストまたはレスポンスに適用されない場合は、その列に「該当なし」とマークされます。

可能な場合については、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 に設定されます。

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

• 構成された送信元に接続されていないため、キャッシュを「フラッシュ」する（たとえば、プロバイダ間で送信元のストレージを移行する場合など）ことなく、送信元の構成を更新（または送信元を完全に置き換える）することができます。
• キャッシュキーは EdgeCacheService に制約されます。EdgeCacheService ごとに異なるキャッシュ Namespace があるため、ホスト、パス、その他のキャッシュキー コンポーネントが一致する場合でも、本番環境、ステージング環境、その他のテスト環境間でオブジェクトが誤ってキャッシュに保存されることはありません。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 のいずれか 1 つを指定できます。

複数のリクエストにわたってコンテンツを一意に識別する目的でクエリ パラメータを使用していない場合、ルートのキャッシュキーからすべてのクエリ パラメータを削除できます。これを行うには、次のように 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- で始まるヘッダー
• accept-encoding
• accept
• authorization
• 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 は、キャッシュに保存されたレスポンスが最新バージョンであることを再検証します。これを行うには、送信元に HEAD リクエストを発行して、ヘッダーが変更されていないことを確認します。
• max-age または s-maxage キャッシュ ディレクティブを設定するレスポンス、または TTL オーバーライドを使用して高い TTL 値（例: 30 日）を指定するレスポンスは、TTL 全期間にわたるキャッシュ格納ができない場合があります。特にアクセス頻度が低い場合、オブジェクトがキャッシュに全期間にわたって格納される保証はありません。

削除率が高い場合は、レスポンスを一意に識別しないパラメータを除外するようにキャッシュキーが構成されていることを確認する必要があります。

その他の考慮事項

キャッシュ保存に関しては、次の考慮事項も適用される場合があります。

Vary ヘッダー

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

• Accept: クライアントが受け入れるメディアタイプを示すために使用されます
• Accept-Encoding: クライアントが受け入れる圧縮タイプを示すために使用されます
• Available-Dictionary: 圧縮に使用できる辞書のハッシュを提供するために使用されます。
• 送信元/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 9110 で定義されている 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 はマルチパート範囲リクエストをサポートしています。これにより、ユーザーは 1 つの HTTP リクエストでファイルの複数の非連続セグメントをリクエストできます（例: Range: bytes=0-499, 1000-1499）。

クライアントのパフォーマンスと送信元のオフロードを最大化するため、Media CDN はリクエストされた個々のバイト範囲をキャッシュから提供し、それらを HTTP 206 Partial Response ステータス コードの単一のレスポンスに統合して、Content-Type が multipart/byteranges に設定されたクライアントに送信します。

キャッシュ可能なレスポンスの場合、クライアントがマルチパート範囲をリクエストすると、Media CDN はリクエストを単一パート範囲リクエストのセットに変換してプロセスを最適化します。各リクエストのサイズは 2 MB で、クライアントがリクエストしたバイト範囲のすべての部分をカバーします。Media CDN は、これらのレスポンスを使用して、エッジで単一のマルチパート レスポンスを生成します。このアプローチにより、キャッシュを効率的に利用し、冗長なオリジン フェッチを減らし、アプリストアのダウンロードや OS のアップデートなどの大容量のユースケースをサポートできます。

キャッシュに保存できないコンテンツの場合、Media CDN はリクエストをオリジンに直接転送します。

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

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

EdgeCacheOrigin.timeouts.readTimeout 構成値を使用して、Media CDN が読み取り間で待機する時間を構成できます。通常、これは目標期間の倍数（2 倍など）に構成する必要があります。

次のステップ

• 高度なルーティングを確認します。
• さまざまな送信元に接続する方法を理解する。
• サービスの TLS（SSL）証明書を設定する。
• コンテンツへのアクセスを認証するように署名付きリクエストを構成します。
• Terraform を使用して EdgeCacheService リソースを構成する方法の詳細については、Terraform レジストリのドキュメントをご覧ください。