キャッシュの概要

キャッシュに保存可能なレスポンスとは、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 のグローバル エッジ ネットワーク上でのキャッシュ保存のメリットが得られます。

キャッシュ モードを CACHE_ALL_STATIC に設定すると、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

鮮度

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

期間のないキャッシュ可能なレスポンスの場合(no-cache など)、public ディレクティブを明示的に指定する必要があります。

CACHE_ALL_STATIC キャッシュ モードで、鮮度ディレクティブが存在しない場合、静的コンテンツ タイプを含む正常なレスポンスは、引き続きキャッシュの対象になります。

FORCE_CACHE_ALL キャッシュ モードでは、正常なレスポンスはすべてキャッシュの対象になります。

ネガティブ キャッシュが有効で、ステータス コードがネガティブ キャッシュで TTL を指定するものと一致する場合、明示的な鮮度ディレクティブがなくても、レスポンスはキャッシュ対象になります。

コンテンツ

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

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

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

10 MB から 5 TB までのレスポンスについては、バイト範囲リクエストで説明されているキャッシュ保存の制約をご覧ください。

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

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

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

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

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

カスタム ヘッダーは、グローバル モードの外部 HTTP(S) ロードバランサでの Cloud CDN デプロイでサポートされていません。

キャッシュキー

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

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

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

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

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 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 の値がキャッシュ エビクション率に与える影響が小さくなります。通常の状況やユーザー トラフィックの状況では、これは目立つものではなく、よく使用されるコンテンツはキャッシュ内に残ります。

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

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

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

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-MatchIf-Modified-Since、または If-None-Match
  • Origin
  • Proxy-Authorization
  • Range
  • Referer(またはReferrer
  • User-Agent
  • Want-Digest
  • Django と Ruby on Rails で使われている X-CSRFTokenX-CSRF-Token
  • X-Forwarded-For(クライアントごと、またはプロキシごと)
  • X-User-IP
  • 以下で始まるヘッダー:
    • Access-Control-Access-Control-Request-HeadersAccess-Control-Request-Method など)
    • Sec-Fetch-
    • Sec-GFE-
    • Sec-Google-
    • X-Amz-
    • X-GFE-
    • X-Goog-
    • X-Google-

注:

  • リクエスト ヘッダー値は、カスタム ヘッダーを追加または変更する前にキャッシュキーを生成するために使用されます。
  • RFC 7230 に従い、有効な HTTP ヘッダー フィールド名のみが受け入れられます。
  • ヘッダー フィールド名で大文字と小文字は区別されません。重複は拒否されます。

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

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

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 名のリストを最大 3 つまで指定できます。

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

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

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

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

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

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

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

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

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

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

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

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

public 該当なし

このディレクティブはキャッシュへの保存に必須ではありませんが、プロキシによってキャッシュに保存されるコンテンツには、このディレクティブを含めることをおすすめします。

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 が Cloud CDN で使用されます。

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

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 リクエスト ディレクティブは無視されます。キャッシュに保存されたレスポンスは、このヘッダーがリクエストに含まれていない場合と同様に返されます。

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

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 が指定されていることを確認してください。

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

キャッシュ エントリの有効期間は、そのキャッシュ エントリが有効であり続ける長さを定めます。s-maxage(または、max-ageexpires)で指定された値により、ユーザーが生成した古いキャッシュ済みコンテンツを自動的に再検証できます。

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

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

キャッシュ モードは、データの鮮度を決定する方法に影響します。

キャッシュ モード 検証動作
CACHE_ALL_STATIC 送信元ヘッダー(Cache-Control: s-maxageCache-Control: max-ageExpires ヘッダー)を参照して鮮度が判断されます。静的コンテンツで送信元ヘッダーが存在しない場合は、構成されている default_ttl によって鮮度が判断されます。静的コンテンツが default_ttl より古くなると、Cloud CDN によってコンテンツが再検証されます。
USE_ORIGIN_HEADERS Cloud CDN キャッシュの各キャッシュ エントリには、有効期間があります。これは RFC 7234 に従って Cache-Control: s-maxageCache-Control: max-age、または Expires ヘッダーで定義されます。
FORCE_CACHE_ALL 送信元ヘッダーではなく、構成されている default_ttl によって鮮度が判断されます。コンテンツが default_ttl より古くなると、Cloud CDN によってコンテンツが再検証されます。

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

デフォルトでは、有効期間の値が 30 日(2,592,000 秒)を超える場合、Cloud CDN は有効期間の値を 2,592,000 秒として処理しますが、ダウンストリーム クライアントには、max-ages-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-ModifiedETag のいずれのヘッダーもない場合、Cloud CDN は期限切れのキャッシュ エントリを無視し、クライアント リクエストをそのままバックエンドに転送します。

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

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

  • ステータス コード: 200 OK または 206 Partial Content
  • ヘッダー: Accept-Ranges: bytes
  • ヘッダー: Content-Length または Content-Range
  • ヘッダー: 強いバリデータを使用した 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 バイト)を超えている。

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

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

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

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

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

リクエストの折りたたみ(結合とも呼ばれます)によって、同じキャッシュキーの複数のユーザー提供のキャッシュ フィル リクエストは、能動的にエッジノードごとに 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)がリクエストに含まれることはありません。

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

キャッシュのバイパス

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

このセクションでは、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"
}

次のステップ