Cloud CDNのキャッシュ無効化で「ハマる」前に知っておくべき、エッジの深淵と実務解
現場のエンジニア諸君、お疲れ様。本番環境でコンテンツを更新したのに「画面が古いままですよ」とユーザーから突っ込まれ、冷や汗をかいた経験はないだろうか？
GCPのCloud CDNは強力だ。Googleの広大なエッジネットワークを借りて、オリジンサーバーを保護しつつ爆速でコンテンツを配信できる。しかし、CDN運用において避けて通れない最大の難所、それが「キャッシュ無効化（Cache Invalidation）」だ。
今回は、教科書には載っていない「現場の泥臭い仕様」と、トラブルを回避するための実践的な知見を共有しよう。
—
1. キャッシュ無効化の「正体」を理解する
まず大前提として、Cloud CDNにおける無効化は「即時削除」ではない。グローバルに分散する何百ものエッジサーバーに対して、「そのキャッシュはもう古いぞ」という指令を伝播させるプロセスだ。
なぜ「パスベース」なのか
Cloud CDNの無効化APIは、特定のファイル（例: /images/logo.png）だけでなく、ワイルドカード（例: /images/*）を用いた指定が可能だ。ここで重要なのは、「指定したパスに合致するキャッシュが、エッジサーバー上の検索対象になる」ということだ。
- 完全一致: 指定したパスのみを即座に無効化対象とする。最も確実で、影響範囲が最小限。
- ワイルドカード:
*を末尾につけることで、配下のコンテンツを一括で無効化する。便利だが、濫用するとエッジへの負荷や、意図しないキャッシュの消去を招く可能性がある。
—
2. 実践：キャッシュ無効化のリクエストを投げる
実務では、CI/CDパイプラインにこの処理を組み込むのが定石だ。手動でコンソールをポチポチしているようでは、SREとは呼べない。
gcloud コマンドによる無効化
最も手軽なのは gcloud コマンドだ。デプロイ終了後にフックさせて実行するのが一般的だ。
# 特定のパスのみを無効化（ピンポイントで確実）
gcloud compute url-maps invalidate-cdn-cache [URL_MAP_NAME] \
--path="/static/css/main.css"
# ワイルドカードで配下を一括無効化（大規模更新時）
# 注意: 負荷がかかるため、頻繁な実行は避けること
gcloud compute url-maps invalidate-cdn-cache [URL_MAP_NAME] \
--path="/images/products/*"Python (Google Cloud Client Library) での自動化
管理画面のボタン操作ではなく、アプリケーションの管理画面から「キャッシュクリアボタン」を作りたい場合は、以下のようにPythonで実装する。
from google.cloud import compute_v1
def invalidate_cache(project_id, url_map_name, path_to_invalidate):
# URLマップクライアントの初期化
client = compute_v1.UrlMapsClient()
# 無効化リクエストの定義
invalidation_rule = compute_v1.CacheInvalidationRule(path=path_to_invalidate)
# APIコール
operation = client.invalidate_cache(
project=project_id,
url_map=url_map_name,
cache_invalidation_rule_resource=invalidation_rule
)
# 完了まで待機（本番コードではタイムアウト設定を忘れずに）
operation.result()
print(f"キャッシュ無効化リクエスト成功: {path_to_invalidate}")—
3. 現場のSREが教える「ハマりどころ」
① 「即時」の定義を履き違えるな
無効化リクエストを送った瞬間、世界中のエッジサーバーのキャッシュが消えるわけではない。ネットワークの伝播遅延がある。curl -I で確認しても、キャッシュが消えるまで数秒から数十秒かかることはザラだ。これを「バグだ！」と叫ぶ前に、まずは深呼吸しよう。
② Cache-Control ヘッダーとの兼ね合い
そもそも、キャッシュ無効化APIを頻繁に叩くような設計はアンチパターンだ。
もし頻繁に更新されるAPIレスポンスをCDNに乗せているなら、Cache-Control: max-age=0, must-revalidate を適切に設定し、ブラウザとCDNに「再検証」を促すべきだ。CDNを「強制削除」で制御しようとすると、スパイク時にAPIサーバーが落ちるという悲劇を招く。
③ キャッシュキーの罠
Cloud CDNはデフォルトでホスト名とパスをキーにするが、Query String を含めるかどうかで挙動が変わる。
もしクライアントが ?v=1.0.1 のようなクエリを投げている場合、無効化リクエストを投げる際は、そのクエリを含めたパスを指定しないとキャッシュが残ったままになる可能性がある。
—
まとめ：運用設計の鉄則
1. 可能な限り「無効化」に頼らない: Cache-Control や ETag を駆使し、CDNを賢く使え。
2. ワイルドカードは計画的に: 特定のファイル単位での無効化を優先し、一括無効化は「最後の手段」とする。
3. 冪等性を意識する: 無効化リクエストが失敗した際に、再試行可能な設計になっているかを確認すること。
ネットワークの挙動は、見えないだけに「なんとなく」で運用しがちだ。しかし、こうした細かい仕様を理解しておくことで、障害発生時の切り分け速度が圧倒的に変わる。
君たちが管理するインフラが、今日もユーザーに快適な体験を届けていることを祈る。また何かあれば、現場の最前線で語り合おう。
コメント