「世界中にあなたのコンテンツを届ける！」GCP Cloud CDNの裏側：キャッシュフィルとプレキャッシュの仕組みを解き明かす
こんにちは！SREとして日々クラウドの裏側を覗き込んでいると、ふと「ユーザーのクリック一つが、地球の裏側でどう処理されているのか」という壮大な旅路に思いを馳せることがあります。
今日は、Webサイトの表示速度を劇的に変える「Cloud CDN」の仕組みについて、少しだけ深掘りしてみましょう。特に、皆さんがインフラを構築する際に一度は悩むであろう「キャッシュミスした時、データはどこから来るの？」という疑問を、身近な例えを交えて紐解いていきます。
—
CDNは「世界中に配置された巨大な本棚」
まず、Cloud CDNをイメージしてみましょう。あなたのWebサーバー（オリジン）を「中央図書館」だとすると、Cloud CDNは「世界各地に置かれた小さな支店」です。
ユーザーが画像や動画をリクエストした時、最寄りの支店に本（コンテンツ）があれば、すぐに貸し出せます。これが「キャッシュヒット」です。では、支店に本がない時はどうなるでしょうか？ これが今回のお題である「キャッシュフィル（Cache Fill）」の出番です。
キャッシュフィル：空っぽの本棚を補充する旅
ユーザーがリクエストしたデータがエッジ（支店）にない場合、Cloud CDNは、中央図書館（オリジン）まで本を取りに行く必要があります。この「データを補充する通信」こそがキャッシュフィルです。
1. ユーザーからエッジへのリクエスト
ユーザーが example.com/image.jpg にアクセスすると、世界中に散らばるGoogleの拠点（エッジ）へパケットが届きます。
2. キャッシュミスの発生
エッジのサーバーは、「あ、この本はまだ棚にないな！」と気づきます。
3. キャッシュフィルの開始（オリジンへの取り次ぎ）
ここで、エッジサーバーはオリジンに向かって「すみません、このデータ送ってください！」とリクエストを送ります。この通信経路は、Googleが自社で張り巡らせた超高速なプライベートネットワーク（Google Global Network）を通ります。つまり、インターネットの渋滞を避けて、専用の「物流網」でデータを運ぶイメージですね。
4. コンテンツの保存とユーザーへの配信
オリジンから届いたデータを、エッジは「次からすぐに出せるように」自分の棚に保管します。これで次回からは爆速で応答できるようになるわけです。
—
マルチリージョン構成での「賢い負荷分散」
もし皆さんが世界中でサービスを展開しているなら、オリジンを一つに絞るのではなく、複数のリージョン（例：東京と米国東部）にサーバーを置くこともありますよね。
ここでCloud CDNは、「どれくらい近いか」を瞬時に判断してリクエストを振り分けます。
- 地理的な近接性: 東京のユーザーからのキャッシュフィルは、自動的に東京リージョンのサーバーへ向かいます。
- 異常時の自動回避: もし東京のサーバーがダウンしていたら？ Cloud CDNは「おっと、この支店は今閉まっているな。じゃあ米国リージョンから取り寄せよう」と、自動的に別のルートを探してくれます。これがクラウドの強みですね。
—
設定のヒント：キャッシュを効率よく制御しよう
Cloud CDNを使いこなすには、どんなデータを、どのくらいの期間キャッシュさせるかの「ルール」が重要です。これを管理するのが Cache-Control ヘッダーです。
以下は、Google Cloudのロードバランサー（Cloud Armor等と連携）で、静的コンテンツを効率的にキャッシュさせるための設定イメージです。
# Cloud CDNでキャッシュを制御するための設定例
# バックエンドサービスの設定に反映させます
cacheMode: "CACHE_ALL_STATIC" # 静的コンテンツを自動的にキャッシュ対象にする
clientTtl: 3600 # ブラウザ側で1時間保持させる
defaultTtl: 3600 # CDN側でも1時間キャッシュする
maxTtl: 86400 # 最大で24時間までキャッシュを許容する
# 開発メモ：
# 頻繁に更新されるファイルには 'no-cache' を指定して、
# 常にオリジンを確認させるのが安全です。プレキャッシュ（Pre-caching）という「先読み」の魔法
最後に、少し上級編のテクニック「プレキャッシュ」に触れましょう。これは、ユーザーが要求する前に、あらかじめエッジにデータを送り込んでおく手法です。
例えば、「新商品のキャンペーン動画を、明日の朝9時に世界中で一斉公開する」といったケースを想像してください。公開直後に全世界からアクセスが集中すると、オリジンがパンクしてしまいますよね？
そんな時、公開前にあらかじめCDNのエッジへデータを流し込んでおくことで、公開と同時に全エッジが「準備万端」の状態を作れます。これがプレキャッシュの真骨頂です。
—
まとめ：一歩ずつ理解を深めよう
Cloud CDNの動きを整理すると、以下のようになります。
1. キャッシュミス：エッジにデータがない！
2. キャッシュフィル：Googleの専用網を使ってオリジンへ取りに行く。
3. 保存：棚にしまって、次のユーザーに備える。
最初は複雑に見えるネットワーク経路も、こうして「郵便配達」や「図書館」の仕組みに例えてみると、少しだけ親近感がわきませんか？
クラウドのインフラは、一度組んで終わりではありません。日々のトラフィックを眺めながら、「もう少しキャッシュ時間を延ばしてもいいかな？」「このデータはキャッシュしない方が安全かな？」とチューニングしていくのが、SREとしての醍醐味です。
皆さんもぜひ、Google CloudコンソールでCDNのログを覗いて、パケットの旅路を想像してみてください。きっと、今までとは違う景色が見えてくるはずですよ！
コメント