キャッシュの概要

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

キャッシュ モード

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

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

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

有効なキャッシュ ディレクティブが存在しない場合でも、エラー レスポンスがキャッシュに保存される可能性があります。

キャッシュ モードを FORCE_CACHE_ALL に設定する前に、次の動作について考慮してください。

• 署名付き URL または署名付き Cookie の場合、FORCE_CACHE_ALL は、Google Cloud Console または gcloud --signed-url-cache-max-age オプションのキャッシュ エントリの最長存続期間の設定で指定された最長存続期間をオーバーライドします。

• FORCE_CACHE_ALL は、以前にキャッシュに保存されたコンテンツの有効期間（TTL）を変更します。この変更により、以前は最新と見なされていた一部のエントリが古いと見なされる可能性があります（送信元のヘッダーの TTL が長くなったため）。また、以前は古いと見なされた一部のエントリが最新と見なされる可能性があります。

• FORCE_CACHE_ALL は、キャッシュ ディレクティブ（Cache-Control と Expires）をオーバーライドしますが、他の送信元のレスポンス ヘッダーはオーバーライドしません。特に、キャッシュ モードが FORCE_CACHE_ALL であっても、Vary ヘッダーによってキャッシュが抑制される可能性があります。詳細については、Vary ヘッダーをご覧ください。

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

静的コンテンツ

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

キャッシュ モードを CACHE_ALL_STATIC に設定し、レスポンスに Cache-Control ヘッダーまたは Expires ヘッダーに明示的なキャッシュ ディレクティブがない場合、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（audio/mpeg）や MP4（audio/mp4）などの音声ファイル
• PDF（application/pdf）などのフォーマットされたドキュメント

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

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

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

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

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

• Cloud Storage は常に Cloud CDN に Cache-Control ヘッダーを提供します。値を明示的に選択しない場合は、デフォルト値が送信されます。そのため、Cloud Storage のすべての成功レスポンスは、Cloud Storage 内のオブジェクトに対してキャッシュ制御メタデータを明示的に制御した場合を除き、Cloud Storage のデフォルト値に従ってキャッシュに保存されます。FORCE_CACHE_ALL モードを使用して Cloud Storage から送信された値をオーバーライドすることもできます。

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

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

他のコンテンツ タイプ（HTML（text/html）や JSON（application/json）など）は、正常なレスポンスの場合デフォルトでキャッシュに保存されません。通常、これらのタイプのレスポンスはユーザーごとに動的に行われます。ショッピング カート、ユーザー パーソナライズされた製品ページ、認証された API レスポンスなどが該当します。ただし、ネガティブ キャッシュが有効になっている場合は、特定のステータス コードの情報がキャッシュに保存されることがあります。

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

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

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

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

以下の要件がすべて true の場合、Cloud CDN はレスポンスをキャッシュに保存します。

Cloud Storage バックエンド バケットの場合は、次の追加の推奨事項に従ってください。

• バケットを公開する。これは、公開コンテンツの場合におすすめの方法です。この設定を使用すると、インターネット上のすべてのユーザーが、オブジェクトとそのメタデータ（ACL を除く）を表示および一覧表示できます。公開オブジェクト専用のバケットを作成することをおすすめします。

• マネージド フォルダを使用して、バケットの一部を一般公開します。

• 個々のオブジェクトを公開するこの方法は、以前の Cloud Storage 固有の権限システムを使用しているため、おすすめしません。

• リクエスト元による支払いが有効になっているバケット、または Virtual Private Cloud サービス境界内にオブジェクトを保存しないでください。

• 顧客管理の暗号鍵や顧客指定の暗号鍵を使用してオブジェクトを暗号化しない。

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

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

最大サイズ

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

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

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

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

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

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

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_HEADERS または CACHE_ALL_STATIC に設定されている場合、Cloud CDN は public、must-revalidate、s-maxage のキャッシュ制御ディレクティブを含むレスポンスのみをキャッシュに保存します。これにより、ユーザー単位のコンテンツや認証が必要なコンテンツが意図せずキャッシュされるのを防ぐことができます。FORCE_CACHE_ALL キャッシュ モードには、この制限はありません。

カスタム レスポンス ヘッダー

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

手順については、カスタム レスポンス ヘッダーを構成するをご覧ください。

キャッシュキー

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

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

バックエンド バケットの場合、デフォルトでは、プロトコルまたはホストのない URI でキャッシュキーが構成されます。デフォルトでは、Cloud Storage が認識しているクエリ パラメータのみがキャッシュキーに含まれます（例: generation）。

したがって、特定のバックエンド バケットについて、次の 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

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

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

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

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

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

Cloud Storage キャッシュキーのクエリ文字列の追加リスト

Cloud Storage バケットのキャッシュキーに URL クエリ パラメータを追加すると、キャッシュ無効化をサポートできます。キャッシュ無効化により、以前のバージョンが TTL 設定に基づいてキャッシュに保存されている場合でも、アップロードされたファイルの新しいバージョンをユーザーが取得できます。

バックエンド バケットからのレスポンスを提供するために使用されるキャッシュキーで、クエリ文字列パラメータを含む追加リストを使用できます。Cloud Storage がクエリ パラメータに基づいて異なるコンテンツまたはルートを提供することはありませんが、Cloud Storage バケットに保存されている静的コンテンツのキャッシュ無効化を行えるようにパラメータを追加できます。

たとえば、基になるコンテンツに応じて ?version=VERSION または ?hash=HASH クエリ パラメータを追加できます。これにより、コンテンツを事前に無効にする必要がなくなり、最新のウェブ開発ワークフローに対応できます。ウェブ フレームワークと URL はコンテンツのハッシュを使用するため、デプロイメント全体で古いオブジェクトが提供されなくなります。

キャッシュキーへのクエリ パラメータの追加はオプトインのみです。Cloud CDN では、キャッシュキーからバックエンド バケットへのクエリ パラメータの除外をサポートしていません。

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

除外リストを使用すると、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 には一致しません。

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

クエリ パラメータの順序

生成されるキャッシュキーはクエリ パラメータの順序に依存しません。

たとえば、次のクエリ パラメータは同じキャッシュキーを生成します。

• info=123&variant=13e&geography=US
• geography=US&variant=13e&info=123

HTTP ヘッダーと HTTP Cookie のキャッシュキーの設定

次のキャッシュキーの構成を設定することで、キャッシュ ヒット率と送信元オフロードを改善できます。

• バックエンド サービスとバケットの場合: キャッシュキーの構成に名前付きヘッダーを含めることで、キャッシュキーの一部として HTTP ヘッダーを使用します。
• バックエンド サービスの場合のみ: A/B（多変量）テスト、カナリアなどのシナリオでは、名前付き HTTP Cookie をキャッシュキーとして使用します。

追加の HTTP ヘッダーや HTTP Cookie がキャッシュ リクエストに含まれている場合、そのキャッシュキーのキャッシュの場所に 3 番目のリクエストとしてキャッシュに保存されます。これにより、カーディナリティが高いヘッダーや Cookie の値がキャッシュ エビクション率に与える影響が小さくなります。通常の状況やユーザー トラフィックの状況では、これは目立つものではなく、よく使用されるコンテンツはキャッシュ内に残ります。

リクエスト ヘッダーの追加

レスポンスの追加バリエーションをキャッシュに保存するには、キャッシュキーに追加のリクエスト ヘッダーを含めます。

通常、一部のヘッダーはカーディナリティが非常に高いため、キャッシュキーでは使用できません。ほとんどの場合、これらのヘッダーの値はユーザーごとに一意になるか（Cookie、Authorization）、数千の値になります（Referer、User-Agent、Accept）。たとえば、User-Agent ヘッダーの場合、ブラウザ、ユーザー デバイス、オペレーティング システムが多種多様なため、一意の値が 5,000 を超える場合があります。これらのヘッダーは、キャッシュ ヒット率に重大な影響を及ぼします。

RFC 7230 に従い、有効な HTTP ヘッダー フィールド名のみが受け入れられます。ヘッダー フィールド名で大文字と小文字は区別されません。重複は拒否されます。

必要に応じて、Vary レスポンスに構成されたキャッシュキー リクエスト ヘッダーを含めるように配信元サーバーを構成できます。この操作は、Cloud CDN では不要ですが、ダウンストリーム キャッシュの場合に役立ちます。詳細については、Vary ヘッダーをご覧ください。

Cloud CDN では、ヘッダーのリストに次のヘッダーを含めることはできません。

• Accept
• Accept-Encoding
• Authority、構成（cdnPolicy.includeHost）で制御されるため
• Authorization（通常は、OAuth Bearer トークンとしてユーザーごと）
• CDN-Loop
• Connection
• Content-MD5
• Content-Type
• Cookie
• Date
• Forwarded（クライアントごと、またはプロキシごと）
• From
• Host、構成（cdnPolicy.includeHost）で制御されるため
• If-Match、If-Modified-Since または If-None-Match
• Origin
• Proxy-Authorization
• Range
• Referer（またはReferrer）
• User-Agent
• Want-Digest
• Django と Ruby on Rails で使われている X-CSRFToken と X-CSRF-Token
• X-Forwarded-For（クライアントごと、またはプロキシごと）
• X-User-IP
• 以下で始まるヘッダー:
  • Access-Control-（Access-Control-Request-Headers、Access-Control-Request-Method など）
  • Sec-Fetch-
  • Sec-GFE-
  • Sec-Google-
  • X-Amz-
  • X-GFE-
  • X-Goog-
  • X-Google-

同じヘッダーで値が異なる場合

ユーザーが、次のように、ヘッダー値が異なる同じ名前のヘッダーを複数送信したとします。

My-Header: Value1
My-Header: Value2

この場合、Cloud CDN は、一部のヘッダーに複数の値を使用できる標準規則を遵守するため、リクエストを変更します。Cloud CDN は、これらの値をカンマ区切りのリストにまとめてバックエンドに送信します。このため、クライアントから次のものが送信された場合と同じ動作になります。

My-Header: Value1, Value2

名前付き Cookie の追加

HTTP Cookie は name=value ペアです。リクエストには、同じ行にセミコロンで区切られた複数の HTTP Cookie を含めるか、ヘッダーごとに 1 つの Cookie を持つ個別の Cookie リクエスト ヘッダーを含めることができます。

Cookie の名前が最大 5 個含まれるリストを指定できます。

ユーザー エージェント（ウェブブラウザなど）で、ドメインあたりの Cookie 数が 4 KB に制限されていることがよくあります。ユーザー エージェントがリクエスト内のすべての Cookie を送信しない可能性があるため、大量の Cookie またはサイズの大きい Cookie を送信しないようにしてください。ユーザーがキャッシュ内の特定のレスポンスを受け取るかどうかに影響する可能性があります。

Cookie を発行した別のホスト名から静的コンテンツを配信する場合は、Cookie の Domain 属性（および Path 属性）が、Cookie を静的コンテンツのリクエストで送信できるようにします。

リクエストに同じ Cookie 名の複数のインスタンスが含まれている場合、最初のインスタンスのみが適用されます。

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

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

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

可能な場合については、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 が指定されていることを確認してください。

キャッシュキーで HTTP ヘッダーを使用している場合、Cloud CDN は指定したリクエスト ヘッダーの値に基づいて、レスポンスの複数のコピーをキャッシュに保存します。この方法は Vary でサポートされている方法と似ていますが、配信元サーバーで Vary レスポンス ヘッダーを明示的に指定する必要はありません。配信元が Vary レスポンス内でキャッシュキー ヘッダーを指定した場合、Cloud CDN は Vary レスポンスにヘッダーが記述されていない場合と同じように、レスポンスを適切に処理します。

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

キャッシュ エントリの有効期間とは、そのキャッシュ エントリが有効である時間の長さです。s-maxage（あるいは max-age または expires）の値により、ユーザーが生成した古いキャッシュ済みコンテンツを自動的に再検証できます。

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

一部のキャッシュ モードでは、TTL 値を設定できます。詳細については、TTL の設定とオーバーライドの使用をご覧ください。

キャッシュ モードは更新頻度を決定する方法に影響します。

複数のヘッダーが存在する場合には、Cache-Control: s-maxage が Cache-Control: max-age よりも優先され、Cache-Control: max-age が Expires よりも優先されます。

デフォルトでは、有効期限の値が 30 日（2,592,000 秒）を超える場合、Cloud CDN は有効期限の値を 2,592,000 秒として処理しますが、ダウンストリーム クライアントには、max-age と s-maxage の値が 30 日を超える場合でも正しい値がそのまま表示されます。

エビクション

キャッシュ エントリが期限切れになるまでキャッシュに保存されるという保証はありません。新しいコンテンツの場所を確保する目的で、人気のないエントリは期限切れになる前であっても削除される可能性があるためです。上限として、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-Modified と ETag のいずれのヘッダーもない場合、Cloud CDN は期限切れのキャッシュ エントリを無視し、クライアント リクエストをそのままバックエンドに転送します。

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

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

• ステータス コード: 200 OK または 206 Partial Content
• ヘッダー: Accept-Ranges: bytes
• ヘッダー: Content-Length。206 Partial Content レスポンスの場合は、送信元オブジェクトの完全な長さを示す Content-Range 値。たとえば、Content-length: 0-100/999 はキャッシュに保存できますが、Content-length: 0-100/* はキャッシュに保存できません。
• ヘッダー: 強いバリデータを使用した Last-Modified または ETag。

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

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

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

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

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

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

Cloud CDN が独自のバイト範囲キャッシュ フィル リクエストを開始すると、送信元サーバーは 206 Partial Content レスポンスを返します。キャッシュ保存中に 206 Partial Content レスポンスを考慮するには、0-100/999 など、アスタリスクを含まない complete-length ディレクティブを含む Content-Range ヘッダーを含める必要があります。Cloud CDN は、返された 206 Partial Content レスポンスをキャッシュに保存し、そのコンテンツに対する今後のクライアント リクエストに応答するために使用します。

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

分散型の Cloud CDN では、各ロケーションで送信元から最終的なチャンクが複数回取得されることがあります。これは、キャッシュキーあたりの最初のいくつかのリクエストにのみ影響します。

リクエストの折りたたみ（結合）

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

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

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

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

次の図に、リクエストがどのように折りたたまれるかを示します。

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

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

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

Cloud Storage バケットを参照するバックエンド バケットの Google Cloud CLI を使用してアイテム リクエストの折りたたみを無効にするには:

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

Google Cloud CLI を使用して、バックエンド バケットでアイテム リクエストの折りたたみを有効にするには:

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

VM グループやバックエンド サービス（外部バックエンドなど）の Google Cloud CLI を使用してアイテム リクエストの折りたたみを有効にするには:

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-Control と Expires のレスポンス ヘッダーを使用します。

キャッシュミスが発生した場合、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 によって検証リクエストやバイト範囲リクエストが開始されるときに、クライアント固有のヘッダー（たとえば Cookie や User-Agent）がリクエストに含まれることはありません。

Cloud Logging の httpRequest.userAgent フィールドで、Cloud-CDN-Google は Cloud CDN がリクエストを開始したことを意味します。

キャッシュのバイパス

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

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

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

始める前に

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

• 必要に応じて、次のコマンドで Google Cloud CLI を最新バージョンに更新します。

  gcloud components update
  

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

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

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

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

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

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

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

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

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

次のステップ

• キャッシュ モードでコンテンツのキャッシュ保存を容易にする方法については、キャッシュ モードの使用をご覧ください。
• HTTP(S) 負荷分散および負荷分散インスタンス用に Cloud CDN を有効にするには、Cloud CDN の使用をご覧ください。
• キャッシュの無効化については、キャッシュ無効化の概要をご覧ください。
• GFE の接続拠点を確認するには、キャッシュのロケーションをご覧ください。