GCP Cloud CDNの深淵：キャッシュ制御とパケットレベルの最適化戦略
インフラエンジニアとして現場に立っていると、「CDNが効かない」「キャッシュの挙動が期待と違う」という相談を死ぬほど受けます。そのほとんどが、Cache-Controlヘッダーの表面的な理解か、あるいはオリジンサーバーから送出されるパケットの意図せぬ挙動に起因しています。
今回は、GCP Cloud CDNという巨大なグローバル・エッジネットワークを「正しく調教」するための、泥臭くもエレガントなキャッシュ戦略について解説します。
—
1. キャッシュの意思決定：Cache-ControlとVaryの解像度
Cloud CDNのキャッシュエンジンは、HTTP/1.1およびHTTP/2の仕様を厳格に遵守します。しかし、我々アーキテクトが意識すべきは「ブラウザキャッシュ」と「CDNキャッシュ」の分離です。
s-maxage vs max-ageの力学
多くのエンジニアが犯す過ちが、max-ageのみを指定し、CDN側のエッジサーバーにキャッシュ時間を委ねてしまうことです。
s-maxage: CDNのエッジサーバーがオブジェクトを保持する時間を指定します。max-age: ブラウザ（クライアント）が保持する時間を指定します。
もしあなたが「CDNには1時間キャッシュさせたいが、ブラウザには即時再検証させたい」と考えるなら、以下のヘッダーをオリジンから送出するのが定石です。
# CDNには1時間キャッシュを許可し、ブラウザには検証を強制する
Cache-Control: public, s-maxage=3600, max-age=0, must-revalidateVaryヘッダーという名の「諸刃の剣」
Vary: Accept-Encodingは圧縮効率を最適化する上で必須ですが、安易にVary: CookieやVary: Authorizationを付与するのは避けてください。これらはキャッシュのヒット率を劇的に下げ、オリジンへの無駄なリクエストを増幅させます。
教訓: キャッシュキーを細分化しすぎると、エッジの分散性と引き換えに「キャッシュミス」という名のレイテンシ地獄が待っています。
—
2. トランスポート層の最適化：TLSハンドシェイクとRTT削減
Cloud CDNはGoogleのグローバルネットワークをフル活用します。しかし、クライアントからエッジまでの「ラストワンマイル」で発生するTCPハンドシェイクの遅延は、我々が制御できる最後の聖域です。
0-RTTとQUIC (HTTP/3) の恩恵
GCPのロードバランサーを通じてCloud CDNを有効化すると、自動的にQUICが有効になります。QUICはUDPベースであり、TCPの3ウェイハンドシェイクとTLS 1.3のハンドシェイクを1往復（または0往復）に集約します。
ネットワークのパケットロスが激しいモバイル環境において、TCPのように再送制御でパイプラインが停止することがないため、体感速度は別次元になります。
TCPバッファチューニングの限界
もしオリジンがGCP内部（GCE等）にある場合、sysctlでのTCPウィンドウサイズ調整は有効ですが、Cloud CDNとオリジン間の通信はGoogleのプライベートバックボーンを通ります。ここは「信頼できるネットワーク」であるため、過度なバッファチューニングよりも、Keep-Aliveの設定を適切に行い、コネクションの再利用効率を最大化することに集中してください。
—
3. 実践：CDNキャッシュを制御するための設定例
Terraformを用いてCloud CDNのキャッシュポリシーを定義する際、client_ttlとdefault_ttlの使い分けが重要になります。
# Cloud CDNのキャッシュポリシー設定の例
resource "google_compute_backend_service" "default" {
name = "my-web-backend"
# ... 省略 ...
cdn_policy {
# オリジンがヘッダーを指定しない場合のデフォルトキャッシュ時間
default_ttl = 3600
# クライアントが要求する最大キャッシュ時間
max_ttl = 86400
# オリジンの Cache-Control を尊重しつつ制御する設定
cache_mode = "CACHE_ALL_STATIC"
# 重要なセキュリティ設定：ヘッダーのキャッシュキー構成
bypass_cache_on_request_headers {
header_names = ["Authorization"]
}
}
}—
4. セキュリティとネットワーク脆弱性の回避策
CDNは攻撃の最前線です。Cloud Armorとの連携は必須ですが、キャッシュ戦略におけるセキュリティリスクとして「キャッシュ汚染（Cache Poisoning）」を忘れてはいけません。
X-Forwarded-Forの信頼性
バックエンドでIP制限を行う場合、X-Forwarded-Forを安易に信用してはいけません。必ずCloud Armorを通じて、信頼できるIPレンジからのリクエストであることを確認するか、ロードバランサーが付与するX-Forwarded-Forの最後尾を確認するロジックを実装してください。
ヘッダーインジェクションの防止
Varyヘッダーにユーザー入力を含めるような実装は論外です。キャッシュキーを操作されることで、特定ユーザーのキャッシュが他者に漏洩するリスクがあります。常にホワイトリスト形式でヘッダーを処理する設計を徹底してください。
—
結びに：パケットは嘘をつかない
Cloud CDNをチューニングするということは、単に数値をいじることではありません。リクエストがエッジに到達し、キャッシュヒットし、あるいはオリジンまで旅をして戻ってくるまでの、ミリ秒単位のパケットの旅を想像することです。
tcpdumpやWiresharkでパケットを眺め、curl -Iでレスポンスヘッダーを確認する。その泥臭い作業の先にしか、真のパフォーマンス向上はありません。皆さんのインフラが、より堅牢で、より速いものになることを願っています。
次の記事では、Cloud CDNにおける「キャッシュパージの同期遅延と、その際のオリジン負荷対策」について、さらに深掘りしていこうと思います。質問があれば、いつでもコメント欄へどうぞ。
コメント