キャッシュの概要

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

キャッシュ モード

キャッシュ モードでは、Cloud CDN がコンテンツをキャッシュに保存するかどうかを決定する要素を制御できます。

Cloud CDN には 3 つのキャッシュ モードがあり、レスポンスがキャッシュに保存される方法、Cloud CDN が送信元から送信されたキャッシュ ディレクティブを遵守するかどうか、キャッシュ TTL の適用方法を定義します。

次の表に使用可能なキャッシュ モードを示します。

キャッシュ モード 動作
CACHE_ALL_STATIC no-store または private ディレクティブがない静的コンテンツを自動的にキャッシュに保存します。有効なキャッシュ ディレクティブを設定した送信元のレスポンスもキャッシュに保存されます。

これは、gcloud コマンドライン ツールまたは REST API を使用して作成された Cloud CDN 対応バックエンドのデフォルト動作です。

USE_ORIGIN_HEADERS 有効なキャッシュ ディレクティブと有効なキャッシュ ヘッダーを設定するには、送信元のレスポンスが必要です。これらのディレクティブのないレスポンスは、送信元から転送されます。
FORCE_CACHE_ALL レスポンスを無条件にキャッシュに保存し、送信元で設定されたすべてのキャッシュ ディレクティブをオーバーライドします。このモードに構成された共有バックエンドを使用する場合、非公開のユーザー単位のコンテンツ(ダイナミック HTML や API レスポンスなど)はキャッシュに保存しないでください。

設定手順については、キャッシュ モードの設定をご覧ください。

静的コンテンツ

静的コンテンツとは常に同じコンテンツのことであり、異なるユーザーがアクセスする場合でも同じものが表示されます。サイトのスタイル設定で使用する CSS、インタラクティビティを追加する JavaScript、動画、画像コンテンツは通常、特定の URL(キャッシュキー)にアクセスするユーザーごとに変化しないため、Cloud CDN のグローバル エッジ ネットワーク上でのキャッシュ保存のメリットが得られます。

すべての静的コンテンツをキャッシュに保存するようにキャッシュ モードを設定すると、Cloud CDN は次のレスポンスを自動的にキャッシュに保存します。

  • CSS(text/css)、JavaScript(application/javascript)、WOFF2(font/woff2)などのすべてのウェブフォントを含むウェブアセット
  • JPEG(image/jpg)や PNG(image/png)などの画像
  • H.264、H.265、MP4(video/mp4)などの動画および MP3(image/mpeg)、MP4(audio/mp4)などの音声ファイル
  • PDF(application/pdf)などのフォーマットされたドキュメント

次の表に概要を示します。

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

Cloud CDN は、配信されるコンテンツの MIME タイプを反映した Content-Type HTTP レスポンス ヘッダーを検査します。

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

  • 送信元のウェブサーバー ソフトウェアが各レスポンスで Content-Type を設定する必要があります。多くのウェブサーバーは、NGINX、Varnish、Apache などの Content-Type ヘッダーを自動的に設定します。

  • Cloud Console または gsutil ツールを使用してコンテンツをアップロードすると、Cloud Storage により Content-Type ヘッダーがアップロード時に自動的に設定されます。

  • レスポンスが MIME タイプに基づいてキャッシュ可能であるものの、private または no-storeCache-Control レスポンス ヘッダー、または Set-Cookie ヘッダー(ルールの完全なリストを参照)がある場合は、キャッシュに保存されません。

Cloud CDN では、有効なキャッシュ可能なレスポンスの多くが URL に反映されないため、レスポンスがキャッシュ可能かどうかを判断するために URL パスでファイル拡張子を使用しません。

text/html および application/json のコンテンツ タイプをキャッシュに保存する場合は、1 人のユーザーのデータを誤ってキャッシュに保存して、すべてのユーザーに提供しないようにするために、レスポンスに明示的な Cache-Control ヘッダーを設定する必要があります。

キャッシュに保存可能なコンテンツ

Cloud CDN では、このセクションの要件をすべて満たすレスポンスをキャッシュに保存します。この要件の一部は RFC 7234 で規定されています。その他の要件は Cloud CDN 固有のものです。

Cloud CDN は、コンテンツをキャッシュに保存する条件のセットを定期的に変更することがあります。Cloud CDN がコンテンツをキャッシュに保存できないようにする場合は、RFC 7234 のガイドラインに従って、キャッシュ不可のレスポンスを指定する方法を決定します。送信元ヘッダーに基づくキャッシュ保存ができないコンテンツもご覧ください。

次の要件がすべて true の場合、Cloud CDN の現在の実装ではレスポンスがキャッシュに保存されます。

属性 要件
提供元 バックエンドサービス、バックエンド バケット、またはカスタム送信元(Cloud CDN が有効になっているもの)
何に対するレスポンスか GET リクエスト
ステータス コード 200203204206300301302307308404405410421451、または 501
キャッシュ ディレクティブ

CACHE_ALL_STATIC キャッシュ モードの場合、Cache-Control: public ディレクティブ、Expires ヘッダー、または静的コンテンツ タイプを含むレスポンス。

USE_ORIGIN_HEADERS キャッシュ モードの場合、Cache-Control: public ディレクティブまたは Expires ヘッダーを含むレスポンス。

FORCE_CACHE_ALL キャッシュ モードの場合、レスポンスが常にキャッシュ保存の対象になります。

鮮度

CACHE_ALL_STATIC キャッシュ モードでは、max-ages-maxage ディレクティブを含む Cache-Control ヘッダー、未来のタイムスタンプを含む Expires ヘッダー、または静的コンテンツ タイプがレスポンスに含まれます。

USE_ORIGIN_HEADERS キャッシュ モードでは、レスポンスには、max-age または s-maxage ディレクティブを含む Cache-Control ヘッダー、または将来のタイムスタンプを含む Expires ヘッダーがあります。

FORCE_CACHE_ALL キャッシュ モードでは、すべてのバックエンド レスポンスが最新とみなされます。

コンテンツ

有効な Content-LengthContent-RangeTransfer-Encoding: chunked ヘッダーのいずれかを含む。

たとえば、レスポンスのサイズに正しく一致する Content-Length ヘッダー。

サイズ 最大サイズ以下である

Cloud Storage バックエンド バケットの場合、これらの要件を満たすいくつかの方法を以下に示します。

デフォルトでは、バケット全体が一般公開されている場合、または個別のオブジェクトが一般公開されており、個別のオブジェクトが Cache-Control メタデータが指定しない場合、Cloud Storage は Cache-Control: public, max-age=3600 ヘッダーをオブジェクトに割り当てます。Cache-Control メタデータを使用することで、さまざまな値を設定できます。

バックエンド バケットを使用して外部 HTTP(S) ロードバランサを構成する方法の例については、バックエンド バケットを使用した Cloud CDN の設定をご覧ください。

最大サイズ

Cloud CDN では、各レスポンスに最大サイズが適用されます。本文のサイズが最大サイズより大きいレスポンスはキャッシュに保存されませんが、クライアントには配信されます。

最大サイズは、送信元サーバーがバイト範囲リクエストをサポートしているかどうかによって異なります。

送信元サーバーがバイト範囲リクエストをサポートしている 送信元サーバーがバイト範囲リクエストをサポートしていない
5 TB(5,497,558,138,880 バイト) 10 MB(10,485,760 バイト)

ほとんどの最新のウェブサーバー(NGINX、Apache、Varnish を含む)は、バイト範囲リクエストをサポートしています。

元のヘッダーに基づいたキャッシュに保存できないコンテンツ

レスポンスがキャッシュに保存されるかどうか確認する方法があります。 Cloud CDN では、コンテンツを保存する一連の条件を定期的に変更するため、Cloud CDN がコンテンツをキャッシュに保存しないようにする場合は、標準のガイドライン(RFC 7234 )に従って、キャッシュ不可のレスポンスを指定する方法を決定します。

現在の Cloud CDN の実装では、キャッシュに保存可能なコンテンツの要件を満たしていない場合や、次のいずれかに該当する場合、レスポンスはキャッシュ保存されません。

属性 要件
提供元 Cloud CDN が有効になっていないバックエンド サービスまたはカスタム送信元
Cookie Set-Cookie ヘッダーがある
Vary ヘッダー AcceptAccept-EncodingOrigin 以外の値が設定されている。
レスポンス ディレクティブ レスポンスに、no-store または private ディレクティブを含む Cache-Control ヘッダーがある(Cache-Control ヘッダーが無視される FORCE_CACHE_ALL キャッシュ モードを使用している場合を除く)
リクエスト ディレクティブ リクエストに Cache-Control: no-store ディレクティブがある
承認のリクエスト リクエストに Authorization ヘッダーがある。ただし、レスポンスの Cache-Control によってオーバーライドされている場合を除きます。
サイズ 最大サイズを超えている

Cache-Control: no-store または private が存在するものの、コンテンツが引き続きキャッシュに保存されている場合は、次のいずれかが原因です。

  • URL 署名が構成されている。
  • Cloud CDN キャッシュ モードが、すべてのレスポンスを強制的にキャッシュに保存するように設定されている。

キャッシュ保存の禁止

個人情報が Cloud CDN キャッシュに保存されるのを防ぐには:

  1. Cloud CDN キャッシュ モードが FORCE_CACHE_ALL モードに設定されていないことを確認してください。このモードでは、すべてのレスポンスが無条件にキャッシュに保存されます。
  2. Cloud CDN キャッシュに保存してはならないレスポンスには Cache-Control: private ヘッダーを含めます。ウェブブラウザのキャッシュを含むすべてのキャッシュに保存してはならないレスポンスには、Cache-Control: no-store ヘッダーを含めます。
  3. 個人情報へのアクセスを提供する URL に署名しないでください。署名付き URL を使ってコンテンツがアクセスされる場合は、レスポンス内の Cache-Control ディレクティブの内容に関係なく、コンテンツがキャッシュ対象になる可能性があります。
  4. Authorization リクエスト ヘッダーを含む送信元(キャッシュ フィル)リクエストの場合、キャッシュ モードが USE_ORIGIN_HEADERSCACHE_ALL_STATIC に設定されていれば、Cloud CDN では、publicmust-revalidate、または s-maxage のキャッシュ制御ディレクティブを含むレスポンスのみをキャッシュに保存します。これにより、ユーザー単位のコンテンツや認証が必要なコンテンツが意図せずキャッシュ保存されるのを防ぐことができます。FORCE_CACHE_ALL キャッシュ モードには、この制限はありません。

カスタム レスポンス ヘッダーの追加

カスタム レスポンス ヘッダーを使用すると、外部 HTTP(S) ロードバランサがプロキシされたレスポンスに追加するヘッダーを指定できます。カスタム レスポンス ヘッダーを使用すると、クライアント、クライアントの地理的データ、独自の静的レスポンス ヘッダーにキャッシュ ステータスを反映できます。

ヘッダーのリストについては、ヘッダー値に表示できる変数をご覧ください。

手順については、カスタム レスポンス ヘッダーの使用をご覧ください。

キャッシュキー

Cloud CDN キャッシュの各キャッシュ エントリは、1 つのキャッシュキーで識別されます。リクエストがキャッシュに到達すると、リクエストの URI がキャッシュキーに変換され、さまざまなキャッシュ済みエントリのキーと比較されます。一致するキーが見つかると、そのキーに対応するオブジェクトが返されます。

バックエンド サービスの場合、デフォルトで、Cloud CDN は完全なリクエスト URI をキャッシュキーとして使用します。たとえば、https://example.com/images/cat.jpgcat.jpg オブジェクトを求めるリクエストの完全な URI ですが、この文字列がデフォルトのキャッシュキーとして使用され、文字列が完全に同じリクエストのみが一致します。したがって、http://example.com/images/cat.jpg または https://example.com/images/cat.jpg?user=user1 に対するリクエストは一致しません。

キャッシュキーで使用される URI の部分を変更できます。キーには常にファイル名とパスが含まれている必要がありますが、キャッシュキーをカスタマイズするときには、プロトコル、ホスト、クエリ文字列を任意に組み合わせて含めたり省略したりできます。キャッシュキーのカスタマイズ方法については、キャッシュキーの使用をご覧ください。

URI の各部分 カスタマイズ 同じキャッシュキーを持つ URL の例
プロトコル キャッシュキーからプロトコルを省略します。
  • https://example.com/images/cat.jpg
  • http://example.com/images/cat.jpg
ホスト キャッシュキーからホストを省略します。
  • https://example.com/images/cat.jpg
  • https://example2.com/images/cat.jpg
クエリ文字列

キャッシュキーからクエリ文字列を省略します。

クエリ文字列を部分的に省略または追加します。

  • https://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2

クエリ文字列全体を追加または省略するだけでなく、追加リストと除外リストを使用してクエリ文字列の一部を使用することもできます。

バックエンド バケットの場合、キャッシュキーは、プロトコル、ホスト、クエリ文字列を含まない URI で構成されます。

したがって、特定のバックエンド バケットについて、次の URI はキャッシュ内の同じ 1 つのオブジェクトに解決されます。

  • http://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg?user=user1
  • http://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2
  • https://media.example.com/images/cat.jpg
  • https://www.example.com/images/cat.jpg

クエリ文字列の追加リスト

Cloud CDN がキャッシュキーに追加するクエリ文字列パラメータを選択できます。たとえば、user の追加リストを作成すると、https://example.com/images/cat.jpg?user=user1&color=bluehttps://example.com/images/cat.jpg?user=user1&color=red にも一致する https://example.com/images/cat.jpg?user=user1 のキャッシュキーを作成します。

このオプションを使用するには、クエリ文字列を追加して空でない追加リストを指定する必要があります(除外リストは指定しません)

クエリ文字列の除外リスト

除外リストを使用すると、Cloud CDN が無視するクエリ文字列パラメータを選択的に制御できます。たとえば、user の除外リストを作成すると、user を除くすべてのクエリ文字列パラメータがキャッシュキーで使用されます。

このように除外リストを構成した状態で https://example.com/images/cat.jpg?user=user1&color=blue と入力された場合、Cloud CDN はキャッシュキー https://example.com/images/cat.jpg?color=blue を作成します。このキーは https://example.com/images/cat.jpg?user=user2&color=blue にも一致しますが、https://example.com/images/cat.jpg?user=user1&color=red には一致しません。

このオプションを使用するには、クエリ文字列を追加して空でない除外リストを指定する必要があります(追加リストは指定しません)

キャッシュ制御ディレクティブ

次の表に概要を示すように、HTTP キャッシュ制御ディレクティブは Cloud CDN の動作に影響を与えます。

該当なしは、ディレクティブがリクエストまたはレスポンスに適用されないことを示します。

ディレクティブ リクエスト イベントに
no-store リクエストに含まれている場合、Cloud CDN はこれに従い、レスポンスをキャッシュに保存しません。

no-store を含むレスポンスはキャッシュに保存されません。

この設定は、ルートごとに FORCE_CACHE_ALL キャッシュ モードでオーバーライドできます。

no-cache no-cache リクエスト ディレクティブは無視され、クライアントがリクエストを開始する、または送信元に対する再検証を強制する可能性が回避されます。

no-cache を含むレスポンスはキャッシュに保存されますが、配信前に送信元で再検証する必要があります。

この設定は、ルートごとに FORCE_CACHE_ALL キャッシュ モードでオーバーライドできます。

public 該当なし

public ディレクティブを含むレスポンスは、レスポンスが全体としてキャッシュ保存可能であるとみなされ、レスポンスが max-age ディレクティブまたは s-maxage ディレクティブを含む場合にキャッシュに保存されます。

CACHE_ALL_STATIC キャッシュまたは FORCE_CACHE_ALL モードを使用している場合は、この動作は必要ありません。

private 該当なし

private ディレクティブを含むレスポンスは、レスポンスがその他の理由でキャッシュ保存可能であるとみなされる場合でも、Cloud CDN によってキャッシュに保存されません。クライアント(ブラウザなど)は、引き続き結果をキャッシュに保存する可能性があります。

この設定は、ルートごとに FORCE_CACHE_ALL キャッシュ モードでオーバーライドできます。レスポンスのキャッシュへの保存をすべて回避するには、no-store を使用します。

max-age=seconds max-age リクエスト ディレクティブは無視されます。キャッシュに保存されたレスポンスは、このヘッダーがリクエストに含まれていないかのように返されます。 max-age ディレクティブを含むレスポンスは、定義済みの seconds を上限とする期間キャッシュに保存されます。
s-maxage=seconds 該当なし

s-maxage ディレクティブを含むレスポンスは、定義済みの seconds を上限とする期間キャッシュに保存されます。

max-ages-maxage の両方が存在する場合、s‑maxage はサーバーで使用されます。

このディレクティブを含む古くなったレスポンスは配信されません。

s-max-age(2 つのハイフン)は、キャッシュを保存する目的に対しては無効です。

min-fresh=seconds min-fresh リクエスト ディレクティブは無視されます。キャッシュに保存されたレスポンスは、このヘッダーがリクエストに含まれていないかのように返されます。 該当なし
max-stale=seconds

max-stale リクエスト ディレクティブは、クライアントが受け入れ可能な最大ステイルネス(秒単位)を指定します。

Cloud CDN はこれを適用し、レスポンスのステイルネスが max-stale ディレクティブより小さい場合にのみ、古いキャッシュ レスポンスを返します。それ以外の場合は、リクエストのサービスを提供する前に再検証します。

該当なし
stale-while-revalidate=seconds 該当なし

stale-while-revalidate を含むレスポンスは、再検証が非同期で行われている間、seconds を上限とする期間クライアントに配信されます。

この動作は、バックエンドで cdnPolicy.serveWhileStale を設定することで、すべてのレスポンスに対して有効にできます。

stale-if-error=seconds stale-if-error リクエスト ディレクティブは無視されます。キャッシュに保存されたレスポンスは、このヘッダーがリクエストに含まれていないかのように返されます。

このレスポンス ヘッダーには効果がありません。

この動作は、ルートで cdnPolicy.serveWhileStale を設定することで、すべてのレスポンスに対して有効にできます。

must-revalidate 該当なし

must-revalidate を含むレスポンスは、有効期限が経過した後に送信元サーバーで再検証されます。

このディレクティブを含む古くなったレスポンスは配信されません。

proxy-revalidate

proxy-revalidate を含むレスポンスは、有効期限が経過した後に送信元サーバーで再検証されます。

このディレクティブを含む古くなったレスポンスは配信されません。

immutable 該当なし 影響なし。これは、レスポンスでクライアントに渡されます。
no-transform 該当なし Cloud CDN で変換は適用されません。
only-if-cached only-if-cached リクエスト ディレクティブは無視されます。キャッシュに保存されたレスポンスは、このヘッダーがリクエストに含まれていないかのように返されます。 該当なし

可能な場合については、Cloud CDN が RFC に準拠(HTTP RFC 7234)するよう努めますが、キャッシュ オフロードの最適化、ヒット率または全般的な送信元負荷に対してクライアントが与える可能性がある影響を最小限に抑えることを優先します。

HTTP/1.1 Expires ヘッダーを使用するレスポンスの場合:

  • Expires ヘッダーの値は、RFC 7231 で定義されている有効な HTTP 日付であることが必要です。
  • 過去の日付値、無効な日付、または 0 の値は、コンテンツがすでに期限切れになっており、再検証が必要であることを示します。
  • Cache-Control ヘッダーがレスポンス内に存在する場合、Cloud CDN は Expires ヘッダーを無視します。

レスポンスに有効な将来の Expires ヘッダーが存在する場合は、レスポンスがキャッシュに保存され、他のキャッシュ ディレクティブを指定する必要はありません。

HTTP/1.0 Pragma ヘッダーは、レスポンスに存在する場合は無視され、そのままクライアントに渡されます。このヘッダーを含むクライアント リクエストは送信元に渡され、Cloud CDN でレスポンスがどのように処理されるかには影響しません。

Vary ヘッダー

Vary ヘッダーがある場合は、クライアントのリクエスト ヘッダーに応じてレスポンスが異なります。Cloud CDN では、リクエスト URI だけでなく、送信元サーバーがレスポンスに追加する Vary ヘッダーも考慮されます。たとえば、レスポンスで Vary: Accept が指定されている場合、Cloud CDN は、Accept: image/webp,image/*,*/*;q=0.8 が指定されているリクエストと Accept: */* が指定されているリクエストに別々のキャッシュ エントリを使用します。

キャッシュに保存できないコンテンツ セクションの表には、コンテンツをキャッシュに保存できるようにする Vary ヘッダーが一覧表示されます。その他の Vary ヘッダー値は、コンテンツがキャッシュに保存されることを禁止します。

FORCE_CACHE_ALL キャッシュ モードはこの動作をオーバーライドしません。Vary ヘッダーは、複数の送信元サーバー レスポンス間でキャッシュが汚染されるのを回避するうえで重要です。FORCE_CACHE_ALL が存在するために、こうしたレスポンスがキャッシュに保存されると危険な状態になります。

Vary ヘッダーは、圧縮済みコンテンツを配信するときに使用されることもあります。Cloud CDN はレスポンスそのものを圧縮、解凍しませんが、送信元サーバーが圧縮したレスポンスを配信できます。Accept-Encoding リクエスト ヘッダーの値に基づいて、送信元サーバーが圧縮、非圧縮コンテンツのどちらを配信するかを選択する場合は、レスポンスで Vary: Accept-Encoding が指定されていることを確認してください。

有効期間と検証リクエスト

USE_ORIGIN_HEADERS キャッシュ モードの場合、Cloud CDN キャッシュの各キャッシュ エントリには RFC 7234 に従って Cache-Control: s-maxageCache-Control: max-ageExpires ヘッダーで定義された有効期間が存在します。複数のヘッダーが存在する場合には、Cache-Control: s-maxageCache-Control: max-age よりも優先され、Cache-Control: max-ageExpires よりも優先されます。

CACHE_ALL_STATIC キャッシュ モードでは、送信元ヘッダーはデフォルトでチェックされ、情報の鮮度が特定されます。送信元ヘッダーが存在しない場合は、静的コンテンツがすべて新しいものとみなされます。

FORCE_CACHE_ALL キャッシュ モードでは、すべてのバックエンド レスポンスが最新とみなされます。

Cloud CDN がリクエストを受信すると、該当するキャッシュ エントリを参照して有効期間を確認します。キャッシュ エントリが存在し、有効期間が残っている場合、キャッシュからレスポンスを提供します。ただし、有効期間が経過している場合、Cloud CDN はバックエンドのいずれかに接続してキャッシュ エントリの再検証を試行します。これは、レスポンスを配信する前に行われます。ただし、serve-while-stale を有効にしている場合、再検証は非同期で実行されます。

Cloud CDN は、キャッシュに滞在する日数が 30 日を超えているオブジェクトを再検証します。ユーザーが生成した古いキャッシュ コンテンツは、この方法によって自動的に無効になり、削除されます。max-age または s-maxage の値が 30 日(2,592,000 秒)を超える場合、Cloud CDN はその値を 2,592,000 秒として処理しますが、ダウンストリーム クライアントには、max-ages- maxage の値が 30 日を超える場合でも正しい値がそのまま表示されます。

Cloud CDN は、キャッシュ内のレスポンス ヘッダーに含まれる情報を使用して、バックエンドでキャッシュ エントリを検証できます。これは、次の両方に該当する場合に発生します。

  • 以前にキャッシュに保存されたレスポンスに Last-Modified または ETag ヘッダーが含まれている。
  • クライアント リクエストが、If-Modified-Since または If-None-Match ヘッダーを含まない GET リクエストである。

Cloud CDN がこの検証を行う方法は、バイト範囲リクエストを使ってレスポンスがキャッシュされたかどうかによって少々異なります。

  • バイト範囲リクエストを使ってレスポンスがキャッシュに保存された場合、Cloud CDN は If-Modified-Since または If-None-Match ヘッダー、あるいはこの両方を含む 1 つの別個の検証リクエストを開始します。
  • そうでない場合、Cloud CDN は If-Modified-Since または If-None-Match ヘッダー、あるいはこの両方をクライアント リクエストに追加し、変更したリクエストをバックエンドに転送します。

キャッシュ内のコピーがまだ最新の状態であれば、バックエンドは 304 Not Modified レスポンスを送信することで既存のキャッシュ エントリを検証できます。この場合、バックエンドから送信されるのはレスポンス ヘッダーのみであり、レスポンスの本文は送信されません。Cloud CDN は、新しいレスポンス ヘッダーをキャッシュに挿入して有効期間を更新し、新しいレスポンス ヘッダーとキャッシュ内のレスポンス本文をクライアントに送信します。

以前にキャッシュに保存されたレスポンスに Last-ModifiedETag のいずれのヘッダーもない場合、Cloud CDN は期限切れのキャッシュ エントリを無視し、クライアント リクエストをそのままバックエンドに転送します。

キャッシュ エントリの有効期間とは、そのキャッシュ エントリが有効である時間の長さの上限です。キャッシュ エントリが期限切れになるまでキャッシュに保存されるという保証はありません。新しいコンテンツの場所を確保する目的で、人気のないコンテンツのキャッシュ エントリが削除される場合もあります。指定された有効期間に関係なく、30 日間アクセスされていないキャッシュ エントリは自動的に削除されます。

詳しくは、エビクションと有効期限をご覧ください。

TTL の設定とオーバーライド

コンテンツを再検証するまでの Cloud CDN の待機時間について、Cloud CDN の動作を微調整できます。

詳細については、TTL の設定とオーバーライドを使用するをご覧ください。

バイト範囲リクエストのサポート

レスポンスが次の条件を満たしている場合、送信元サーバーはバイト範囲リクエストをサポートしていることになります。

  • ステータス コード: 200 OK または 206 Partial Content
  • ヘッダー: Accept-Ranges: bytes
  • ヘッダー: Content-Length または Content-Range
  • ヘッダー: 強いバリデータを使用した ETag
  • ヘッダー: Last-Modified

Cloud Storage は、ほとんどのオブジェクトに関してバイト範囲リクエストをサポートしています。ただし、Content-Encoding: gzip メタデータを持つオブジェクトについては、クライアント リクエストの中に Accept- Encoding: gzip ヘッダーがある場合を除き、バイト範囲リクエストがサポートされません。Cloud Storage オブジェクトが 10 MB を超える場合は、Content-Encoding: gzip メタデータがないことを確認してください。オブジェクトのメタデータの編集方法については、オブジェクトのメタデータの表示と編集をご覧ください。

一般的なウェブサーバー ソフトウェアでも、バイト範囲リクエストがサポートされています。サポートを有効にする方法の詳細については、お使いのウェブサーバー ソフトウェアのドキュメントをご覧ください。バイト範囲リクエストの詳細については、HTTP 仕様をご覧ください。

送信元サーバーがバイト範囲リクエストをサポートしている場合、次のいずれかの条件が当てはまると、Cloud CDN キャッシュは、本来ならばキャッシュ保存可能なレスポンスでも、初回リクエスト時にはキャッシュへの保存を拒否します。

  • クライアントがコンテンツの一部分だけをリクエストしたことが理由で、レスポンス本文が不完全である。
  • レスポンス本文が 1 MB(1,048,576 バイト)を超えている。

レスポンスが通常のキャッシュ保存の要件を満たしているにもかかわらず、前述の拒否が発生した場合は、送信元サーバーがそのキャッシュキーに対してバイト範囲リクエストをサポートしていることがキャッシュに記録され、送信元サーバーのレスポンスがクライアントに転送されます。

キャッシュミスが発生した場合、キャッシュは、送信元サーバーがバイト範囲リクエストをサポートしているという記録があるかどうかを調べます。そのキャッシュキーでバイト範囲リクエストがサポートされていることがわかれば、クライアント リクエストがキャッシュから外部 HTTP(S) ロードバランサに転送されることはありません。代わりに、コンテンツの不足部分を求めてキャッシュ自体がバイト範囲キャッシュ フィル リクエストを開始します。送信元サーバーからの 206 Partial Content レスポンスで、リクエストされたバイト範囲が返された場合、キャッシュはその範囲を将来のリクエストに備えて保存できます。

キャッシュが 206 Partial Content レスポンスを保存するのは、キャッシュ自体がバイト範囲リクエストを開始し、それに対してこのレスポンスを受け取った場合のみです。送信元サーバーがバイト範囲リクエストをサポートしていることが記録されている限り、キャッシュはそのキャッシュキーについてバイト範囲リクエストを開始できます。1 MB を超える大きなサイズのコンテンツが 2 回目にアクセスされるまでキャッシュに保存されない(初回リクエスト時には拒否される)のは、このようなメカニズムが背景で働いているからです。

リクエストの折りたたみ(結合)

リクエストの折りたたみ(結合とも呼ばれます)によって、同じキャッシュキーの複数のユーザー提供のキャッシュ フィル リクエストは、能動的にエッジノードごとに 1 つの送信元リクエストに折りたたまれます。これにより、送信元の負荷を積極的に軽減できます。この機能は、アイテム リクエスト(直接取得されるレスポンス)とチャンク リクエストの両方に適用されます。その際に、Cloud CDN は Range リクエストを使用して、サイズの大きいオブジェクトをより効率的に取得します。

リクエストの折りたたみは、デフォルトで有効になっています。

折りたたまれたリクエストは、次のように動作します。

  • 折りたたまれたリクエストは、クライアント側のリクエストと(折りたたまれた)キャッシュ フィル リクエストの両方をログに記録します。
  • 折りたたみセッションのリーダー は、元のフィル リクエストを行うために使用されます。
  • キャッシュキーに含まれていないリクエスト属性(User-Agent ヘッダーや Accept-Encoding ヘッダーなど)は、折りたたまれたセッションのリーダーのみを反映しています。
  • 同じキャッシュキーを持たないリクエストは、折りたためません。

次の図に、リクエストがどのように結合されるかを示します。

リクエストの折りたたみが有効になっている Cloud CDN(クリックして拡大)
リクエストの折りたたみが有効になっている Cloud CDN(クリックして拡大)

これと比較して、折りたたみが無効になっているリクエスト、または結合できないリクエストの場合、送信元のリクエストとレスポンスの数は、現在キャッシュに保存されていないオブジェクトの取得を試行しているクライアントの数と同じになる可能性があります。

リクエストの折りたたみを有効にしていない Cloud CDN(クリックして拡大)
リクエストの折りたたみを有効にしていない Cloud CDN(クリックして拡大)

すべてのタイプのリクエストで、折りたたみはデフォルトで有効になっています。項目リクエスト タイプの場合、折りたたみは無効にできます。送信元の負荷が考慮されないような広告配信など、レイテンシの影響を受けやすいシナリオでは、アイテム リクエストの折りたたみを無効にすることをおすすめします。

次の表では、各リクエスト タイプのデフォルト動作と構成可能性を示します。

リクエストの種類 デフォルトの動作 構成可能 折りたたみのメリット
チャンク リクエスト 有効 × 送信元の帯域幅を大幅に削減できる
項目リクエスト 有効 送信元のリクエストの量を削減できる

Cloud Storage バケットを参照するバックエンド バケットの Cloud SDK を使用してアイテム リクエストの折りたたみを無効にするには、次の操作を行います。

gcloud

gcloud compute backend-services コマンドまたは backend-buckets コマンドを使用します。

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-request-coalescing

Cloud SDK を使用してアイテム リクエストの折りたたみを有効にするには、次の操作を行います。

gcloud

gcloud compute backend-buckets コマンドを使用します。

gcloud compute backend-buckets update BACKEND_BUCKET_NAME \
    --request-coalescing

VM グループやカスタム送信元などのバックエンド サービス用に Cloud SDK を使用してアイテム リクエストの折りたたみを有効にするには、次の操作を行います。

gcloud

gcloud compute backend-services コマンドを使用します。

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --request-coalescing

Cloud CDN によって作成されるリクエスト

送信元サーバーがバイト範囲リクエストをサポートしている場合、単一のクライアント リクエストに対して Cloud CDN から複数のリクエストが送信元サーバーに送信されることがあります。Cloud CDN が作成できるリクエストには、検証リクエストとバイト範囲リクエストの 2 種類があります。

送信元サーバーが特定のキャッシュキーのバイト範囲リクエストをサポートしていることがレスポンスで示されていたものの、そのレスポンスの有効期間が過ぎている場合は、Cloud CDN が検証リクエストを開始します。その目的は、コンテンツが変化していないこと、また送信元サーバーが引き続きそのコンテンツの範囲リクエストをサポートしていることの確認です。送信元サーバーから 304 Not Modified レスポンスが返された場合、Cloud CDN はそのバイト範囲を使用してコンテンツを配信します。そうでない場合、Cloud CDN は送信元サーバーのレスポンスをクライアントに転送します。有効期限を制御するには、Cache-ControlExpires のレスポンス ヘッダーを使用します。

キャッシュミスが発生した場合、Cloud CDN はクライアント リクエストと重複する一連のバイト範囲に対するキャッシュ フィル リクエストを開始します。クライアントからリクエストされたコンテンツの範囲の一部がキャッシュにある場合、Cloud CDN はできる限りキャッシュから配信し、不足している範囲についてのみ、バイト範囲リクエストを送信元サーバーに送ります。

Cloud CDN が開始するバイト範囲リクエストには、それぞれ範囲が指定され、範囲の開始オフセットは 2,097,136 バイトの倍数になります。最後の範囲を除いて、各範囲も 2,097,136 バイトです。コンテンツのサイズがこのバイト数の倍数でない場合、最後の範囲がこれより小さくなります。バイト範囲リクエストで使用されるサイズとオフセットは、将来変更される可能性もあります。

例として、クライアントがコンテンツの 1,000,000 バイト目から 3,999,999 バイト目までをリクエストしたが、キャッシュにはそれが存在しないとします。この例では、Cloud CDN は 2 つの GET リクエストを開始します。1 つはコンテンツの最初の 2,097,136 バイト用、もう 1 つは 2 番目の 2,097,136 バイト用です。つまり、クライアントがリクエストしたのは 3,000,000 バイトだけでも、4,194,272 バイト分のキャッシュ フィルが行われます。

Cloud Storage バケットを送信元として使用するときは、GET リクエストごとに独立したクラス B オペレーションとして料金が発生します。料金は、Cloud Storage によって処理されたすべての GET リクエストについて発生します。これには、Cloud CDN によって作成されたリクエストも含まれます。1 つのレスポンス全体が Cloud CDN キャッシュから提供されるときは、GET リクエストが Cloud Storage に送信されないので、Cloud Storage オペレーションの料金は発生しません。

Cloud CDN によって検証リクエストやバイト範囲リクエストが開始されるときに、クライアント固有のヘッダー(たとえば CookieUser-Agent)がリクエストに含まれることはありません。

キャッシュのバイパス

キャッシュ バイパスでは、コンテンツが以前にキャッシュに保存された場合でも、特定のリクエスト ヘッダーを含むリクエストによるキャッシュのバイパスが許可されます。

このセクションでは、PragmaAuthorization などの HTTP ヘッダーによるキャッシュのバイパスについて紹介します。この機能は、ユーザーまたはお客様が、送信元のサーバーから最新のコンテンツを常に取得できるようにする必要がある場合に有用です。これは、テスト、ステージング ディレクトリ、スクリプトのセットアップを実施する場合に行うことをおすすめします。

指定されたヘッダーが一致する場合は、FORCE_CACHE_ALL であっても、すべてのキャッシュ モード設定に対してキャッシュがバイパスされます。多数のリクエストに共通するヘッダーが指定された場合は、キャッシュ バイパスによって多数のキャッシュミスが発生します。

始める前に

  • Cloud CDN が有効になっていることを確認します。手順については、Cloud CDN の使用をご覧ください。

  • 必要に応じて、Cloud SDK を最新バージョンに更新します。

    gcloud components update
    

キャッシュ バイパスの構成

最大 5 つの HTTP ヘッダー名を指定できます。値では大文字と小文字が区別されません。 ヘッダー名は、有効な HTTP ヘッダー フィールド トークンである必要があります。追加されたヘッダーのリストに、ヘッダー名を複数回使用することはできません。 有効なヘッダー名に関する規則については、カスタム ヘッダーの仕組みをご覧ください。

Console

  1. Google Cloud Console で、[負荷分散] ページに移動します。

    [負荷分散] ページに移動

  2. 外部 HTTP(S) ロードバランサの名前をクリックします。
  3. [編集] をクリックします。
  4. [バックエンドの構成] でバックエンドを選択し、[編集] をクリックします。
  5. [Cloud CDN を有効にする] が選択されていることを確認します。
  6. ウィンドウの下部にある [詳細構成] をクリックします。
  7. [リクエスト ヘッダーでキャッシュをバイパスする] で、[ヘッダーを追加] をクリックします。
  8. ヘッダー名(例: PragmaAuthorization)を入力します。
  9. [更新] をクリックします。
  10. [更新] をもう一度クリックします。

gcloud

バックエンド バケットには、--bypass-cache-on-request-headers フラグを指定して gcloud compute backend-buckets create コマンドまたは gcloud compute backend-buckets update コマンドを使用します。

バックエンド サービスには、--bypass-cache-on-request-headers フラグを指定して gcloud compute backend-services create コマンドまたは gcloud compute backend-services update コマンドを使用します。

gcloud compute backend-buckets (create | update) BACKEND_BUCKET_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER
gcloud compute backend-services (create | update) BACKEND_SERVICE_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

次に例を示します。

gcloud compute backend-services update my-backend-service
    --bypass-cache-on-request-headers=Pragma
    --bypass-cache-on-request-headers=Authorization

api

バックエンド バケットには、Method: backendBuckets.insert API 呼び出し、Method: backendBuckets.update API 呼び出し、または Method: backendBuckets.patch API 呼び出しを使用します。

バックエンド サービスには、Method: backendServices.insert API 呼び出し、Method: backendServices.update API 呼び出し、または Method: backendServices.patch API 呼び出しを使用します。

例:

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets

JSON リクエストの本文に次のスニペットを追加します。

"cdnPolicy": {
  "bypassCacheOnRequestHeaders": [
    {
      "headerName": string
    }
  ]
}

キャッシュ バイパスを無効にする

gcloud

バックエンド バケットには、--no-bypass-cache-on-request-headers フラグを指定して gcloud compute backend-buckets create コマンドまたは gcloud compute backend-buckets update コマンドを使用します。

バックエンド サービスには、--no-bypass-cache-on-request-headers フラグを指定して gcloud compute backend-services create コマンドまたは gcloud compute backend-services update コマンドを使用します。

gcloud compute backend-services (create | update) (BACKEND_SERVICE_NAME | BACKEND_BUCKET_NAME)
    --no-bypass-cache-on-request-headers

api

バックエンド バケットには、Method: backendBuckets.insert API 呼び出しまたは Method: backendBuckets.update API 呼び出しを使用します。

バックエンド サービスには、Method: backendServices.insert API 呼び出しまたは Method: backendServices.update API 呼び出しを使用します。

次のいずれかの API 呼び出しを使用します。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE

JSON リクエストの本文に次のスニペットを追加します。

"cdnPolicy": {
  "fields": "bypassCacheOnRequestHeaders"
}

次のステップ