【実務・中級編】 Cloud CDNのNegative Caching(ネガティブキャッシュ)の挙動 – クラウドインフラと仮想化ネットワーク実践ガイド

障害発生時の「最後の砦」：Cloud CDNのNegative Cachingでオリジンを守り抜く技術

現場のSREなら一度は経験があるはずだ。深夜3時に鳴り響くアラート。ログを確認すると、存在しないURLへの執拗なリクエスト攻撃や、オリジンサーバーが一時的にダウンした際の「404の嵐」が、バックエンドのデータベースやアプリケーションサーバーを叩き潰している。

「オリジンを守れ」。クラウドインフラエンジニアにとって、この命題は永遠の課題だ。今日は、GCPのCloud CDNが持つ隠れた名機能、Negative Caching（ネガティブキャッシュ）について、現場の泥臭い知見を交えて深掘りしていく。

—

1. なぜ「失敗」をキャッシュするのか？

通常、CDNは「成功したコンテンツ（200 OK）」をキャッシュしてオリジンを保護する。しかし、エラーレスポンスは「失敗」であるため、CDNはデフォルトではキャッシュせず、全てオリジンへ透過させようとする。

もし、悪意あるクローラーや設定ミスが「存在しないパス」へ毎秒数千リクエストを送ってきたらどうなるか？毎回オリジンまでリクエストが到達し、そのたびにアプリケーションはデータベースを検索し、無駄なCPUサイクルを消費する。

そこで登場するのが Negative Caching だ。これは、エラーレスポンス（HTTP 404, 502など）をCDNのエッジサーバーで一時的に保持し、同じエラーを繰り返すリクエストをエッジで即座に遮断する仕組みだ。これにより、オリジンの負荷を劇的に下げることができる。

—

2. 実装のキモ：Negative Cachingの挙動と設定

GCPのCloud CDNにおいて、この設定は BackendService の構成の一部として定義する。ここでは、Terraformを例に見てみよう。

resource "google_compute_backend_service" "default" {
  name        = "my-app-backend"
  # ... 他の設定 ...

  # Negative Cachingの設定ブロック
  negative_caching = true

  # どのステータスコードをキャッシュ対象にするか（例：404, 502）
  # 502をキャッシュするのは賛否あるが、短時間なら有効な場合が多い
  negative_caching_policy {
    code = 404
    ttl  = 300 # 300秒間（5分間）エッジでキャッシュする
  }

  negative_caching_policy {
    code = 502
    ttl  = 10  # 502は障害の可能性が高いため、短めのTTLにするのが定石
  }
}

パラメーター選定の現場的アドバイス

404 (Not Found): 非常に安全だ。存在しないリソースが数分間増えたところで、ユーザー体験に影響はない。300秒〜3600秒程度の長めでも良い。
502 (Bad Gateway): 慎重になれ。オリジンが復旧した瞬間に、CDNがまだエラーを返し続ける可能性がある。TTLは短く（10秒〜60秒）設定し、オリジンの復旧を待つバランス感覚が必要だ。

—

3. デバッグの現場：本当にキャッシュされているか確認する

設定を入れたら、必ず「意図通りにキャッシュされているか」を検証しなければならない。curl を使って、CDNエッジの挙動を追跡しよう。

# -I オプションでヘッダーのみを取得
# 1回目：オリジンへアクセスされる（Cache-Miss）
curl -I https://example.com/not-exist-path

# 2回目：エッジでキャッシュされているか確認（Cache-Hit）
curl -I https://example.com/not-exist-path

ここで注目すべきは Via ヘッダーや Age ヘッダー、そしてGCP特有の X-Cache 系のレスポンスヘッダーだ。Age がカウントアップされていれば、エッジでしっかり保持されている証拠である。

もし検証がうまくいかない場合は、Cache-Control ヘッダーがオリジンから「不適切な値（no-store など）」で返っていないかを確認してほしい。CDNはRFCの仕様に従うため、オリジンが「キャッシュするな」と命じている場合は、Negative Caching設定よりも優先されてしまうことがある。

—

4. 陥りやすい罠：CDNは「万能薬」ではない

最後に、シニアSREとして警告しておきたい。Negative Cachingは強力だが、「エラーの隠蔽」になり得る。

1. モニタリングの盲点: Negative Cachingを有効にすると、CDNエッジでエラーが止まってしまい、オリジンのエラーログに何も出力されなくなることがある。障害検知のトリガーがCDNのメトリクス（GCP Monitoring）にあるか、必ず確認すること。
2. キャッシュのパージ: 設定変更や、誤ってキャッシュしてしまったエラーを解除したい場合は、gcloud コマンドでキャッシュの無効化（Invalidation）を行う必要がある。

# 特定のパスのキャッシュを強制的にパージする
gcloud compute url-maps invalidate-cdn-cache my-url-map \
    --path "/not-exist-path" \
    --host "example.com"

—

まとめ

Cloud CDNのNegative Cachingは、単なる「エラーの保持」ではない。それは、オリジンサーバーという「心臓部」を守るための防波堤だ。

設計の際は、常に「このTTLでユーザー体験を損なわないか？」「障害検知のスピードは落ちないか？」を自問自答してほしい。教科書通りの設定値を入力するのではなく、自分のサービスのトラフィックパターンに合わせて数値をチューニングする。それこそが、現場で戦うエンジニアの腕の見せ所だ。

君たちのインフラが、今日も安定して稼働し続けることを祈っている。それでは、また現場で会おう。