GCP Cloud CDNのキャッシュ無効化：その「即時性」と「泥臭い現実」を解き明かす
現場のSREとして働いていると、開発チームからこんなSOSが届くことがあります。
「管理画面から画像を差し替えたのに、本番環境で見ると古い画像のままなんです！」
CDN（Content Delivery Network）という強力な武器は、時として我々の足元をすくう「更新の遅延」という罠を仕掛けてきます。今回は、Google Cloud (GCP) の Cloud CDN における「キャッシュ無効化（Cache Invalidation）」の仕組みと、現場で必ずハマる落とし穴について、実務的な視点から深掘りしていきましょう。
—
キャッシュ無効化の正体：パケットの向こう側で何が起きているのか
Cloud CDN におけるキャッシュ無効化とは、一言で言えば「Googleのグローバルエッジサーバー全域に対して、特定のパスに関連付けられたキャッシュを強制的に無効（または削除）にする」命令を送る処理です。
勘違いしやすいポイントですが、このAPIを叩いた瞬間に「世界中の全ノードから物理的にデータが消える」わけではありません。正確には、該当キャッシュに対して「次回のアクセス時には必ずオリジンサーバーまで確認しに行け（Revalidation）」というフラグを立てる、あるいは破棄するプロセスが走ります。
ワイルドカード * の甘い誘惑と現実
Cloud CDN の無効化リクエストで最も注意すべきなのが、パス指定におけるワイルドカード * の扱いです。
/images/*：これはimagesディレクトリ以下の全ファイルを指します。/images/logo_*.png：これも有効です。
ここで重要なのは、「APIの呼び出し頻度には制限（Quota）がある」という点です。例えば、全ファイルを無効化したいからといって、無闇に /* を連発すれば、すぐにクォータ制限に引っかかります。また、大規模なディレクトリに対して広範囲なワイルドカードを投げると、内部的な伝搬処理に時間がかかり、「即時」とは呼べないラグが発生することもあります。
—
実際に叩いてみる：gcloud CLI と API の挙動
では、実際にどのように無効化リクエストを送るのか。最も一般的な gcloud コマンドを使った例を見てみましょう。
# 特定のパスを指定して無効化リクエストを投げる
# --path パラメータには、キャッシュキーとして登録されているパスを指定します
gcloud compute url-maps invalidate-cdn-cache [URL_MAP_NAME] \
--path "/images/hero_banner_v2.png" \
--globalもし、デプロイパイプライン（GitHub ActionsやJenkinsなど）から自動的に実行したい場合は、Pythonの google-cloud-compute クライアントを使うのが定石です。
from google.cloud import compute_v1
def invalidate_cache(project_id, url_map_name, path_to_invalidate):
# 接続設定
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}")
# 実行例
# invalidate_cache("my-project-id", "my-load-balancer", "/static/css/style.css")—
現場のSREが教える「ハマりどころ」とデバッグ手順
キャッシュ無効化を実行したはずなのに反映されない。そんな時は、往々にして「CDNではない別の場所」に問題があります。
1. ブラウザキャッシュの呪縛
CDN側のキャッシュをクリアしても、クライアントのブラウザが強力な Cache-Control ヘッダーを握りしめていることがあります。まずは、シークレットモードで確認するか、Chrome DevToolsの「Disable cache」を試してください。
2. Via ヘッダーを確認せよ
デバッグの基本は curl -I でレスポンスヘッダーを確認することです。
curl -I https://example.com/images/logo.pngここで X-Cache: HIT と表示されていればCDNのキャッシュが効いています。無効化リクエストが正常に処理されていれば、直後のリクエストでは X-Cache: MISS になるはずです。もし何度試しても HIT し続けるなら、パス指定が間違っているか、Cloud CDN ではなくブラウザ/プロキシ側に原因があります。
3. 反映速度（伝搬）の仕様
Google Cloud のドキュメントには「数分以内」と記載されていますが、これはあくまでグローバルな伝搬を含めた目安です。特定のリージョンで即座に反映されても、地球の裏側では数秒の遅れが生じることがあります。ミッションクリティカルな更新であれば、「パスにバージョン番号を付与する（例: style.v2.css）」という、キャッシュ無効化に依存しない設計を優先すべきです。
—
まとめ：運用設計の勘所
キャッシュ無効化は、いわば「外科手術」です。乱用すればAPI制限に阻まれ、運用コストも嵩みます。
- 基本はバージョン管理： ファイル名にハッシュ値を付与する（Fingerprinting）のが最も安全で確実です。
- 無効化は最終手段： どうしても変更が必要な場合のみ、API経由でピンポイントに無効化する。
- 監視を忘れずに： キャッシュヒット率を Cloud Monitoring で可視化し、無効化リクエストが正しく機能しているか（MISSのスパイクが発生しているか）を常に監視下に置いてください。
クラウドのインフラは「信じるな、確認せよ（Trust, but verify）」。この精神が、皆さんのサービスを堅牢に保つ鍵となります。次回のデプロイ時に、ぜひこの挙動を思い出してみてください。
コメント