GCP Cloud CDNの深淵：キャッシュフィルと「エッジの賢い立ち回り」を極める
現場でネットワークのトラブルシュートをしていると、「なぜかオリジンへの負荷が下がらない」「CDNを導入したのに初速が遅い」といった相談をよく受けます。その原因の多くは、CDNを単なる「静的コンテンツの置き場」と勘違いし、その裏側にあるキャッシュのライフサイクルや、オリジンへ向かう「キャッシュフィル（Cache Fill）」の挙動をブラックボックスにしていることにあります。
今回は、GCP Cloud CDNにおいて、キャッシュミス時にパケットがどう走り、どのようにオリジンへ到達するのか。そのリアルな挙動を紐解いていきましょう。
—
キャッシュフィル（Cache Fill）の全貌：パケットはどこを走るのか
ユーザーがブラウザでリクエストを投げたとき、Cloud CDNのエッジサーバーが「そのコンテンツを持っていない」と判断すると、エッジは即座にオリジンへリクエストを転送します。これが キャッシュフィル（Cache Fill） です。
ここでのポイントは、この通信が Googleのグローバルプライベートネットワーク（Andromeda）上を走る という点です。
通信フローのシーケンス
1. User → Edge: ユーザーが https://api.example.com/data.json をリクエスト。
2. Cache Lookup: エッジ拠点で Cache-Key を計算し、ヒット判定。
3. Cache Miss: キャッシュミスが発生。
4. Cache Fill: エッジからGoogleの内部ネットワークを経由し、バックエンドサービス（GCE, GKE, Cloud Run, Cloud Storage等）へリクエストが飛ぶ。
5. Origin Response: オリジンがレスポンスを返し、エッジがそれをキャッシュ（Cache-Control ヘッダーに従う）。
このとき、エッジとオリジン間はレイテンシを最小化するために、Googleの巨大なバックボーンが最適化されたルーティングを提供します。
—
マルチリージョンオリジンと負荷分散の力学
Cloud CDNは、HTTP(S) ロードバランサ（GCLB）と密結合しています。マルチリージョンでオリジンを構成している場合、CDNは「どのオリジンからフェッチするか」をロードバランサのトポロジーに基づいて決定します。
負荷分散の肝：Cache-Key と X-Cloud-Trace-Context
デバッグの際、キャッシュがどのリージョンからフィルされたかを知るには、レスポンスヘッダーを確認するのが鉄則です。
# curlでレスポンスヘッダーを確認する
curl -I -H "Host: api.example.com" https://[LB_IP]/v1/resourceここで注目すべきは Via ヘッダーや X-Cache ヘッダーです。もし X-Cache: MISS が頻発するなら、キャッシュキーの設計を見直す必要があります。
—
実践：キャッシュヒット率を最大化する設計
キャッシュミスを減らすためには、Cache-Control ヘッダーの制御がすべてと言っても過言ではありません。
1. HTTPヘッダーの構成例
バックエンド（Python/Flaskの例）で、CDNに対して「キャッシュしてほしい」と伝えるコードです。
from flask import Flask, make_response
app = Flask(__name__)
@app.route('/api/data')
def get_data():
resp = make_response({"status": "success", "data": "..."})
# 3600秒間キャッシュし、共有キャッシュ（CDN）にも保持させる
resp.headers['Cache-Control'] = 'public, max-age=3600, s-maxage=3600'
# 重要なキャッシュキーのバリエーションをVaryで明示
resp.headers['Vary'] = 'Accept-Encoding, Authorization'
return resp2. プレキャッシュ（Pre-caching）戦略の現実
「ユーザーが来る前にキャッシュを温めておきたい」というニーズには、Cloud CDNの直接的な「プレキャッシュ機能」というものは存在しません。しかし、以下の手法で擬似的に実現するのが現場の定石です。
- ウォームアップスクリプト: デプロイ直後に、内部IPからエッジに対して
curlで主要エンドポイントを叩く。 - Cloud Run/GKEのヘルスチェック: ヘルスチェックのついでにキャッシュを温める手法もありますが、これはキャッシュの整合性に注意が必要です。
—
SREとしてのトラブルシューティングTips
最後に、現場で「キャッシュが効かない！」と叫びたくなったときに確認すべき3つのチェックリストを置いておきます。
1. Authorization ヘッダーの有無:
Authorization ヘッダーが含まれていると、Cloud CDNはデフォルトでキャッシュをスキップします。APIで認証が必要な場合、signed-url や signed-cookies を活用してキャッシュを有効化するアーキテクチャへの変更を検討してください。
2. Vary ヘッダーの不一致:
Vary ヘッダーに User-Agent を含めると、キャッシュのバリエーションが爆発し、ヒット率が壊滅的に低下します。デバイス判定は可能な限り X-Device-Type のような独自ヘッダーで正規化しましょう。
3. Cache-Control: private の罠:
バックエンドが private を返していると、CDNは一切キャッシュしません。これは最も多い設定ミスの一つです。
まとめ
Cloud CDNは魔法の箱ではなく、HTTP仕様に忠実なキャッシュサーバーです。パケットがどこを通り、どのヘッダーを見てキャッシュの可否を判断しているかを理解すれば、インフラはもっと軽量で高速になります。
まずは、自分のアプリケーションが返している Cache-Control を curl -v で確認することから始めてみてください。そこには必ず、パフォーマンス改善のヒントが隠れています。
コメント