概要

Cloud CDN コンテンツ配信ネットワークは、HTTP(S) 負荷分散と連携してユーザーにコンテンツを配信します。HTTP(S) 負荷分散では、リクエストを受け取るフロントエンドの IP アドレスとポート、リクエストに対応するバックエンドが提供されます。

Cloud CDN コンテンツはさまざまな種類のバックエンドから提供されます。

Cloud CDN では、こうしたバックエンドが送信元サーバーとも呼ばれます。次の図は、VM インスタンス上で稼働している送信元サーバーからのレスポンスがどのように HTTP(S) ロードバランサを通過して Cloud CDN によって配信されるかを示しています。

送信元サーバーから Cloud CDN を通過してクライアントに送信されるレスポンスのフロー
Cloud CDN レスポンス フロー

Cloud CDN の仕組み

ユーザーが HTTP(S) ロードバランサからコンテンツをリクエストする場合、そのリクエストは Google のネットワークのエッジにある Google Front End(GFE)に到着します。これはユーザーに最も近い Google のネットワークのエッジに配置されます。ロードバランサの URL マップによって、Cloud CDN が構成されているバックエンドにトラフィックがルーティングされる場合、GFE では次の方法で Cloud CDN を使用します。

  • GFE は最初に Cloud CDN キャッシュでユーザーのリクエストに対するレスポンスを検索します。GFE がキャッシュに保存されたレスポンスを見つけた場合、GFE はキャッシュに保存されたレスポンスをユーザーに送信します。これはキャッシュ ヒットと呼ばれます

  • GFE がリクエストに対するキャッシュに保存されたレスポンスを見つけられなかった場合、GFE は適切なバックエンド(送信元サーバー)に対するリクエストを作成します。このリクエストに対するレスポンスをキャッシュに保存できる場合、GFE はそのレスポンスを Cloud CDN キャッシュに保存するため、このキャッシュを後続のリクエストに使用できます。

Cloud CDN を使用するには、HTTP(S) ロードバランサでプレミアム ネットワーク サービス層を使用する必要があります。Cloud CDN によってキャッシュに保存されたレスポンスが提供される場合、そのレスポンスはロードバランサの IP アドレスから配信されます。Cloud CDN は URL のリダイレクトを行いません。Cloud CDN キャッシュは GFE に配置されます。これは、Cloud CDN が有効になっているかどうかに関係なく、クライアントがリクエストする URL は同じで、キャッシュ ヒットがあるかどうかに関係なく、URL は同じであることを意味します。

キャッシュからアイテムを削除するには、キャッシュ内のコンテンツを無効にします。

Cloud CDN をバイパスするには、Cloud Storage バケットまたは Compute Engine VM から直接オブジェクトをリクエストします。たとえば、Cloud Storage バケット オブジェクトの URL は次のようになります。

https://storage.googleapis.com/your-storage-bucket/filename

キャッシュのヒット、ミス、フィル、下り

コンテンツが初めてリクエストされたときに、GFE はキャッシュからリクエストを処理できないと判断します。これはキャッシュ ミスと呼ばれます。この場合、GFE は近くにあるキャッシュからコンテンツを取得しようとします。付近のキャッシュにコンテンツが保存されていると、GFE によってキャッシュ間のフィルで最初のキャッシュにコンテンツが送信されます。保存されていない場合には、GFE は HTTP(S) ロードバランサにリクエストを転送します。次に、ロードバランサはこのリクエストをバックエンドの 1 つに転送します。このバックエンドが、このコンテンツの送信元サーバーです。

キャッシュで受信されたコンテンツは、GFE によってユーザーに転送されます。そのコンテンツがキャッシュ可能である場合、将来のリクエストに備えてそのコンテンツをキャッシュに保存できます。キャッシュが新しいコンテンツの保存を拒否することもあります。そのコンテンツを保存した結果として、それよりも人気が高いコンテンツを追い出すことになってしまう場合や、その新しいコンテンツの人気度がわからない場合です。たとえば、大きなコンテンツの初回アクセス時にキャッシュがコンテンツの保存を拒否することがあります。

ユーザーがリクエストしたコンテンツが、すでにキャッシュに保存されている場合は、キャッシュがそのキャッシュキーでコンテンツを見つけて直接ユーザーにレスポンスを返すので、ラウンド トリップ時間が短くなり、送信元サーバーがリクエストを処理する必要はなくなります。

最初のレスポンスは送信元サーバーから配信されますが、以降のレスポンスは GFE によってキャッシュから配信されます。
キャッシュ ミスとキャッシュ ヒット

キャッシュからクライアントへのデータ転送をキャッシュ下りといいます。キャッシュへのデータ転送を「キャッシュ フィル」といいます。次の図に示すように、キャッシュ フィルの送信元は別の Cloud CDN キャッシュのことも、送信元サーバーのこともあります。

キャッシュ フィルとは、送信元サーバーからキャッシュへの、またはキャッシュから別のキャッシュへのデータ転送です。キャッシュ下りとは、キャッシュからクライアントへのデータ転送です。
キャッシュ フィルとキャッシュ下り

キャッシュ ヒットの場合、キャッシュ下りの帯域幅に対して課金されます。キャッシュ ミスの場合はキャッシュ フィルの帯域幅に対しても課金されます。キャッシュ ミスでキャッシュ フィルが発生した場合も同様です。他の条件がすべて同じ場合、キャッシュ ヒットの費用はキャッシュ ミスよりも低くなります。料金の詳細については、料金ページをご覧ください。

キャッシュ ヒット率

キャッシュ ヒット率は、リクエストされたオブジェクトがキャッシュから提供される回数の割合です。キャッシュ ヒット率が 60% の場合、リクエストされたオブジェクトがキャッシュから 60% の割合で提供され、送信元から 40% の割合で取得する必要があります。

Google Cloud Platform Console で、キャッシュ ヒット率が [キャッシュ ヒット率] 列で各送信元からレポートされます。
Cloud CDN ページに移動
このページに表示されているパーセンテージは、小さな時間枠(最後の数分)に対して計算された率を表します。1 時間から 30 日の期間でのキャッシュ ヒット率を表示するには、送信元の名をクリックし、[モニタリング] タブをクリックします。

キャッシュキーがキャッシュ ヒット率にどのように影響するかの詳細については、キャッシュキーの使用をご覧ください。トラブルシューティング情報については、キャッシュ ヒット率が低いをご覧ください。

キャッシュへのコンテンツの保存

あるオブジェクトが特定のキャッシュに保存されるのは、リクエストがそのキャッシュを通過し、かつレスポンスがキャッシュ可能な場合だけです。このような条件を満たす必要があることから、キャッシュへの保存は事後対応になります。キャッシュに保存されたオブジェクトが他のキャッシュに自動的に複製されることはありません。キャッシュ フィルは、クライアントが作成したリクエストに応じて実行されます。個々のキャッシュがリクエストに応答する場合を除いて、キャッシュを事前に読み込むことはできません。

送信元サーバーがバイト範囲リクエストをサポートしている場合、Cloud CDN が単一のクライアント リクエストに対して複数のキャッシュ フィル リクエストを作成することがあります。キャッシュ フィル リクエストの詳細については、Cloud CDN によって作成されるリクエストをご覧ください。

キャッシュから提供されたコンテンツ

Cloud CDN を有効にすると、キャッシュ可能なすべてのコンテンツが自動的にキャッシュに保存されます。送信元サーバーは、どのレスポンスをキャッシュし、どれをキャッシュしてはならないかを、HTTP ヘッダーを使用して指示します。バックエンド バケットを使用するときは、送信元サーバーは Cloud Storage です。VM インスタンスを使用するときは、送信元サーバーはそのインスタンスを実行しているウェブサーバー ソフトウェアです。 Cloud CDN がキャッシュに保存する内容や保存期間などについては、キャッシュの詳細をご覧ください。

Cloud CDN は、世界各地の多数のロケーションにあるキャッシュを使用します。キャッシュの特性上、特定のリクエストがキャッシュから提供されるかどうかを予測することはできません。ただし、キャッシュ可能なコンテンツに対するリクエストが多い場合は、そのリクエストへのレスポンスがキャッシュから返される可能性が高くなり、レイテンシの大幅な短縮やコストの削減と、送信元サーバーへの負荷の軽減が期待できます。

ログを表示すると、Cloud CDN がどのコンテンツをキャッシュから配信しているかがわかります。キャッシュからコンテンツを削除するには、キャッシュの無効化を実行します。

エビクションと有効期限

コンテンツをキャッシュから配信するには、コンテンツをキャッシュに保存し、コンテンツの削除や期限切れを防ぐ必要があります。

エビクションと有効期限は異なるコンセプトです。いずれも提供されるコンテンツに影響を及ぼしますが、相互に直接影響を与えることはありません。

  • エビクション: キャッシュに保存されるコンテンツの量には上限があります。Cloud CDN は、キャッシュがいっぱいになった後もコンテンツを追加します。保存量の上限に達しているキャッシュにコンテンツを挿入する場合、キャッシュ内のデータを削除して空き領域を確保します。この処理をエビクションといいます。キャッシュは常にいっぱいになっているため、常にエビクションが行われています。通常はコンテンツの有効期限に関係なく、最近アクセスされていないコンテンツが削除されます。削除されるコンテンツは期限切れの場合もあれば、そうでない場合もあります。有効期限を設定してもエビクションに影響はありません。

    人気のないコンテンツとは、しばらくアクセスされていないコンテンツのことです。「しばらく」と「人気のない」は、どちらもキャッシュ内の他のアイテムと比較した場合の相対的な基準になります。キャッシュに送信されるトラフィックが増加するにつれ、エビクションで削除されるコンテンツも増加します。

    サイズの大きなキャッシュも同様です。エビクションでコンテンツが予期せず削除される可能性があるため、リクエストがキャッシュから処理されるとは限りません。

  • 有効期限: HTTP(S) キャッシュ内のコンテンツには有効期限を構成できます。有効期限により、コンテンツ内の古いコンテンツが処理されなくなります。エビクションで削除されていないコンテンツも同様です。

    たとえば、撮影されて 1 時間以内の写真を保存する URL の場合、レスポンスの有効期限を 1 時間以内に設定します。このような設定を行わないと、キャッシュから古い写真が提供される可能性があります。

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

送信元サーバーがバイト範囲リクエストをサポートしている場合、単一のクライアント リクエストに対して Cloud CDN から複数のリクエストが送信元サーバーに送信されることがあります。バイト範囲リクエストのサポートで説明しているように、Cloud CDN が作成できるリクエストの種類には、検証リクエストとバイト範囲リクエストの 2 つがあります。バイト範囲リクエストについて詳しくは、上述のドキュメントをご覧ください。

他の Cloud Platform サービスのデータ ロケーションの設定

Cloud CDN を使用すると、送信元サーバーのリージョンやゾーンとは別のロケーションにデータが保存される場合があります。これは正常な状態であり、HTTP キャッシュはこのようにしてインターネット上で機能します。Google Cloud Platform 利用規約のサービス固有の規約により、他の Google プロダクトやサービス(この場合は Cloud CDN サービス)と併用する場合、特定の Cloud Platform サービスで使用可能なデータ ロケーションの設定は、それぞれの Cloud Platform サービスの主要お客様データに適用されません。この条件に承諾できない場合には、Cloud CDN サービスを使用しないでください。

Google マネージド SSL 証明書のサポート

Cloud CDN が有効になっている場合は、Google マネージド証明書を使用できます。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Cloud CDN のドキュメント