Cloud CDNのキャッシュキーを制する者は、Webパフォーマンスを制す
「なぜ、URLは全く同じなのにキャッシュが効かないのか？」
深夜の運用待機中、Cloud CDNのヒット率（Cache Hit Ratio）が低迷しているグラフを前に、そんな溜息をついた経験はないだろうか。
Cloud CDNは魔法の箱ではない。彼らは「キャッシュキー」という、極めてシビアな照合ルールに基づいてコンテンツを出し分けている。このキーの設計が甘ければ、CDNは単なる「ただの通り道」と化し、バックエンドのオリジンサーバーには常に無駄な負荷がかかり続けることになる。
今日は、GCPにおけるCloud CDNのキャッシュキーを自在に操り、ヒット率を限界まで引き上げるための「実戦的チューニング術」を共有しよう。
—
1. キャッシュキーの「正体」を見極める
デフォルト設定のまま運用していると、Cloud CDNは基本的に「ホスト名 + リクエストパス」をキャッシュキーとして使用する。だが、昨今のモダンなAPIやWebアプリケーションの世界では、これだけでは不十分だ。
例えば、Accept-Encoding ヘッダーや、トラッキング用の utm_ クエリパラメータ。これらをそのままキャッシュキーに含めてしまうと、同じコンテンツなのに「別物」として扱われ、キャッシュが断片化する。逆に、認証トークンやセッションCookieを誤ってキーに含めれば、キャッシュ汚染やセキュリティリスクを招く。
キャッシュキー構成の基本要素
Cloud CDNがキーを作成する際、我々が介入できるのは主に以下の4点だ。
- Host: 送信先のドメイン。
- Query Strings: URL末尾の
?id=123など。 - Request Headers:
AuthorizationやAccept-Encodingなど。 - Cookies: 特定のセッション情報など。
—
2. 実戦設定：Terraformでキャッシュキーを最適化する
管理画面をポチポチするのもいいが、SREたるもの設定はコードで管理すべきだ。以下は、特定のAPIエンドポイントに対して、必要なクエリパラメータだけを抽出し、不要なヘッダーを除外する google_compute_backend_service の設定例だ。
resource "google_compute_backend_service" "api_backend" {
name = "api-backend-service"
port_name = "http"
protocol = "HTTP"
cdn_policy {
cache_mode = "CACHE_ALL_STATIC" # もしくは USE_ORIGIN_HEADERS
# ここがキャッシュキーのカスタマイズの心臓部
cache_key_policy {
include_host = true
# 不要なutm_パラメータを除外し、必要なものだけを指定する
query_string_whitelist = ["version", "format"]
# ヘッダーの制御（Accept-Encodingは圧縮方式の判別に必須）
include_accept_encoding = true
# セッションCookieが原因でキャッシュが効かないのを防ぐ
include_user_cookie = false
}
}
}この設定の肝は query_string_whitelist にある。闇雲に「全て含める」のではなく、「キャッシュのバリエーションとして意味のあるパラメータだけ」をホワイトリスト化するのが鉄則だ。
—
3. 現場で役立つデバッグ：パケットの挙動を追う
設定を変えた後、本当に期待通りにキャッシュが効いているのか？それを確認するための最も信頼できる方法は、curl でレスポンスヘッダーを叩くことだ。
以下のコマンドを打てば、CDNが「何」をキーとして判断したのか、そして「今、キャッシュが当たっているのか」が手に取るようにわかる。
# -Iでヘッダーのみ取得し、キャッシュの状態を確認
curl -Iv -H "Accept-Encoding: gzip" "https://api.example.com/data?version=1&ignored=abc"レスポンスヘッダーに以下の文字列が含まれているかチェックしよう。
Age: キャッシュに保存されてからの秒数（これが表示されていれば、キャッシュヒットしている証拠だ）。X-Cache:HITなら成功、MISSならオリジンへ取りに行っている。
もし、いくら叩いても X-Cache: MISS が続くなら、キャッシュキーに含まれる「不要なヘッダー」が原因の可能性が高い。そんな時は、ブラウザの検証ツールではなく、curl でヘッダーを一つずつ削りながら検証するのが近道だ。
—
4. SREの勘所：キャッシュキー設計のベストプラクティス
最後に、数々の障害対応から得た「黄金律」を伝授する。
1. クエリパラメータの正規化: 同じ意味を持つパラメータでも、順番が入れ替わると別のキーになる可能性がある。可能であれば、クライアント側でパラメータの順序をソートしておくのが理想だ。
2. Vary ヘッダーとの付き合い方: オリジンサーバーが送出する Vary ヘッダーは、CDNのキャッシュキーに強い制約を与える。「Vary: *」などと設定してしまうと、キャッシュが一切効かなくなるため注意が必要だ。
3. 圧縮済みコンテンツのキャッシュ: include_accept_encoding = true を有効にすれば、gzip や br (Brotli) 圧縮済みのデータをCDN側で適切に判別してキャッシュしてくれる。これをしないと、圧縮されていないデータがクライアントに届くという悲劇が起きる。
まとめ
Cloud CDNのキャッシュキー設定は、単なる「設定値の変更」ではない。それは、「どのリクエストを同一とみなし、どのリクエストを個別とみなすか」という、サービスのアーキテクチャそのものの定義だ。
最初は難しく感じるかもしれない。だが、curl でヘッダーを丹念に読み解き、ヒット率のグラフが右肩上がりに改善していく様を見れば、この作業の面白さが理解できるはずだ。さあ、今すぐコンソールを開いて、君のサービスのキャッシュキーを見直してみてほしい。
コメント