Cloud CDN の概要

Cloud CDN(コンテンツ配信ネットワーク)は、Google のグローバル エッジ ネットワークを使用して、ユーザーの近くからコンテンツを配信します。これにより、ウェブサイトやアプリケーションが高速化されます。

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)に到着します。

ロードバランサの URL マップが Cloud CDN が構成されたバックエンド サービスまたはバックエンド バケットにトラフィックをルーティングする場合、GFE は Cloud CDN を使用します。

キャッシュ ヒットとキャッシュミス

キャッシュは、コンテンツを保存および管理するサーバーのグループで、そのコンテンツでの今後のリクエストを高速で処理できるようにします。キャッシュされたコンテンツは、配信元サーバーに保存されているキャッシュ可能なコンテンツのコピーです。

GFE は Cloud CDN のキャッシュを検索し、ユーザーのリクエストに対するレスポンスを見つけると、キャッシュに保存されているそのレスポンスをユーザーに送信します。これは「キャッシュ ヒット」と呼ばれます。キャッシュ ヒットが発生すると、GFE がそのキャッシュキーを基準にコンテンツを検索してユーザーにレスポンスを直接返すので、ラウンド トリップ時間が短くなり、配信元サーバーがリクエストを処理する必要もなくなります。

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

その後、ロードバランサはいずれかの配信元サーバーにリクエストを転送します。キャッシュでコンテンツが受信されると、そのコンテンツが GFE によってユーザーに転送されます。

次の図は、キャッシュ ヒットとキャッシュミスを示しています。

  1. VM インスタンス上で稼働している配信元サーバーが、HTTP(S) レスポンスを送信します。
  2. 外部 HTTP(S) ロードバランサが、レスポンスを Cloud CDN に配信します。
  3. Cloud CDN が、レスポンスをエンドユーザーに配信します。
最初のレスポンスは送信元サーバーから提供されますが、以降のレスポンスは GFE によってキャッシュから提供されます。
キャッシュ ヒットとキャッシュミス

キャッシュ下りとキャッシュ フィル

このリクエストに対する配信元サーバーのレスポンスがキャッシュ可能な場合、Cloud CDN は以降のリクエストに備えてレスポンスを Cloud CDN キャッシュに保存します。

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

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

キャッシュ ヒットの場合、キャッシュからの下り(外向き)帯域幅に対して課金されます。キャッシュミス(キャッシュ間フィルが発生したミスを含む)の場合、キャッシュ フィルの帯域幅に対しても課金されます。つまり、キャッシュ ヒットの費用はキャッシュミスより低くなります。詳しい料金情報については、料金をご覧ください。

URL リダイレクトなし

Cloud CDN は URL リダイレクトを行いません。Cloud CDN のキャッシュは GFE にあります。これは、次のことを意味します。

  • Cloud CDN が有効であるかどうかにかかわらず、クライアントがリクエストする URL は同じ URL のままです。
  • キャッシュ ヒットの有無にかかわらず、URL は同じ URL のままです。

キャッシュ ヒット率

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

Google Cloud Console では、[キャッシュ ヒット率] 列に送信元ごとのキャッシュ ヒット率がレポートされます。

Cloud CDN ページに移動

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

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

キャッシュへのコンテンツの挿入

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

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

キャッシュからのコンテンツの配信

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

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

Cloud CDN がキャッシュから何を配信しているかを確認するには、ログを表示します。

キャッシュからコンテンツを削除する

キャッシュからアイテムを削除するには、キャッシュに保存されたコンテンツを無効にします。詳細については、次の情報をご覧ください。

キャッシュ バイパス

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

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

エビクションと有効期限

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

エビクションと有効期限は異なるコンセプトです。このどちらも、何が配信されるかに影響を与えますが、相互に直接影響を与えることはありません。

エビクション

各キャッシュに保存されるコンテンツの量には上限があります。ただし 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 マネージド証明書を使用できます。

Google Cloud Armor と Cloud CDN

Google Cloud Armor と Cloud CDN を併用している場合、セキュリティ ポリシーが適用されるのは、動的コンテンツやキャッシュミスに対するリクエスト、または送信元サーバーを宛先とするその他のリクエストに限られます。そのリクエストが送信元サーバーに到達することをダウンストリーム Google Cloud Armor セキュリティ ポリシーが禁止している場合であっても、キャッシュ ヒットは配信されます。

次のステップ