キャッシュの概要

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

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

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

次の条件をすべて満たしている場合にのみ、Cloud CDN キャッシュにレスポンスを保存できます。

属性 要件
提供元 バックエンドサービス、バックエンド バケット、またはカスタム送信元（Cloud CDN が有効になっているもの）
何に対するレスポンスか GET リクエスト
ステータス コード 200、203、206、300、301、302、307、410
キャッシュ ディレクティブ public ディレクティブを含む Cache-Control ヘッダーがある
鮮度 max-age または s-maxage ディレクティブを含む Cache-Control ヘッダー、あるいは将来のタイムスタンプを含む Expires ヘッダーがある
内容 有効な Content-Length、Content-Range、Transfer-Encoding ヘッダーのいずれかを含む

例: レスポンスのサイズに正しく一致する 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 が有効になっていないもの）
Cookie Set-Cookie ヘッダーがある
レスポンス ディレクティブ no-store、no-cache、または private ディレクティブを含む Cache-Control ヘッダーがレスポンスにある
リクエスト ディレクティブ リクエストに Cache-Control: no-store ヘッダーがある
サイズ 最大サイズを超えている

これらの要件は今後緩和される可能性があり、その場合は Cloud CDN のキャッシュに保存されるレスポンスの種類が増えます。

Cache-Control: no-store、no-cache、または private が存在する場合でも、URL 署名が構成されていれば、コンテンツは引き続きキャッシュに保存されます。次のセクションでは、レスポンスがキャッシュに保存されるのを防ぐ方法について説明します。

キャッシュ保存の禁止

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

  1. Cloud CDN キャッシュに保存してはならないレスポンスには Cache-Control: private ヘッダーを含めます。ウェブブラウザのキャッシュを含むすべてのキャッシュに保存してはならないレスポンスには、Cache-Control: no-store ヘッダーを含めます。
  2. 個人情報へのアクセスを提供する URL に署名しないでください。署名付き URL を使ってコンテンツがアクセスされる場合は、レスポンス内の Cache-Control ディレクティブの内容に関係なく、コンテンツがキャッシュ対象になる可能性があります。

キャッシュキー

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

バックエンド サービスの場合、デフォルトで、Cloud CDN は完全なリクエスト URI をキャッシュキーとして使用します。たとえば、https://example.com/images/cat.jpg は cat.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=blue は https://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 には一致しません。

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

Vary ヘッダー

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

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

Vary ヘッダーを含むレスポンスがキャッシュに保存されるのは、キャッシュに保存可能なコンテンツに記載されている値が 1 つでもこのヘッダーに含まれている場合のみです。

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

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

Cloud CDN がリクエストを受信すると、該当するキャッシュ エントリを参照して有効期間を確認します。キャッシュ エントリが存在し、有効期間が残っている場合、キャッシュからレスポンスを提供します。しかし、有効期間が過ぎている場合、Cloud CDN がレスポンスを返すには、まずいずれかのバックエンドと通信する必要があります。

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

以前にキャッシュされたレスポンスに Last-Modified または ETag ヘッダー、あるいはこの両方がある場合、Cloud CDN はこれらのヘッダー内の情報を使用して、バックエンドでキャッシュ エントリを検証できます。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 は期限切れのキャッシュ エントリを無視し、クライアント リクエストをそのままバックエンドに転送します。

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

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

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

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

  • ステータス コード: 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 回目にアクセスされるまでキャッシュに保存されない（初回リクエスト時には拒否される）のは、このようなメカニズムが背景で働いているからです。

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）がリクエストに含まれることはありません。

次のステップ