エッジで「失敗」を定義する：GCP Cloud CDNのネガティブキャッシュがもたらす極限のアーキテクチャ
SREの現場において、ネットワークの最適化とは「いかに速く成功を届けるか」だけではない。「いかに美しく失敗を処理し、オリジンを保護するか」こそが、大規模トラフィックを捌くアーキテクトの腕の見せ所だ。
今回は、GCP Cloud CDNにおける「ネガティブキャッシュ（Negative Caching）」に焦点を当てる。多くのエンジニアがこの機能を単なる「エラーのキャッシュ」と捉えているが、その内側では、TCP/TLSのハンドシェイクコストの削減、オリジンの負荷分散、そしてDDoS対策という、極めて戦略的なパケット制御が行われている。
—
1. ネガティブキャッシュの「実体」とパケットレベルの挙動
通常、CDNは 200 OK のレスポンスをキャッシュ対象とする。しかし、オリジンサーバーが 404 Not Found や 502 Bad Gateway を返した際、そのリクエストのたびにオリジンへ往復するのは、ネットワークのオーバーヘッドとしてあまりに無駄だ。
ネガティブキャッシュが有効な場合、CDNのエッジサーバーは「エラーレスポンス」を一定期間メモリ上に保持する。ここで重要なのは、「キャッシュヒットすればオリジンへのTCPコネクションを一切開かない」という点だ。
RTT削減とTLSハンドシェイクの排除
もしネガティブキャッシュが無ければ、クライアントからのリクエストに対して、エッジサーバーは毎回オリジンと再接続を試みる。
1. TCP 3-Way Handshake: 往復のRTT（Round Trip Time）が少なくとも1回発生。
2. TLS 1.3 Handshake: 暗号スイートのネゴシエーションと証明書の検証にさらにRTTが発生。
エッジでエラーを保持していれば、これら全てのトランスポート層のオーバーヘッドを、エッジのメモリ読み取りのみで完結させられる。これは特に、オリジンが不安定な状況下で、ネットワーク全体を保護するための強力な防波堤となる。
—
2. なぜ今、ネガティブキャッシュなのか？
現場の視点で見ると、この機能は単なるキャッシュ効率化ではない。「オリジンの保護」と「攻撃の減衰」というセキュリティ上の防衛戦術だ。
- オリジン保護: 存在しないリソースへの大量のスキャン（
404攻撃）が来た際、ネガティブキャッシュがあれば、オリジンへパケットが到達することはない。 - バックオフ戦略の簡素化: 502エラーをキャッシュすることで、オリジンのリカバリ期間中に発生する無駄なリトライをエッジで食い止められる。
—
3. 実践：Cloud CDNにおけるネガティブキャッシュの設定
Google Cloudの BackendService でネガティブキャッシュを有効にするのは非常にシンプルだが、そのパラメータチューニングには戦略が必要だ。
# Backend Serviceに対してネガティブキャッシュを有効化する
# 404, 502, 503, 504などのステータスコードをキャッシュ対象とする
gcloud compute backend-services update [YOUR_BACKEND_SERVICE_NAME] \
--global \
--enable-negative-caching \
--negative-caching-policy='404:300,502:60,503:60' # 404は300秒, 502/503は60秒キャッシュパラメータの設計哲学
404: 比較的長く設定しても安全なケースが多い。アプリケーション側の変更がない限り、キャッシュヒット率は非常に高くなる。502/503: これらは「一時的な故障」を示す。長すぎると復旧を検知できずユーザー体験を損なうため、60秒程度でオリジンへの疎通確認（ヘルスチェック）と同期させるのが定石だ。
—
4. パフォーマンスを極限まで高める：HTTPヘッダーと圧縮
エッジでエラーを返す際、Content-Length を適切に制御し、Brotli や Gzip によるヘッダー圧縮が効いているかを確認することも重要だ。
特に、エラーレスポンスであっても、クライアントの Accept-Encoding ヘッダーを尊重することで、エッジサーバーからの転送パケットを最小化できる。
# エッジが返すレスポンスヘッダーの例
HTTP/2 404 Not Found
content-type: text/html; charset=UTF-8
cache-control: public, max-age=300
age: 120
x-cache: HIT # ここが重要。オリジンに行かずエッジで完結している証拠もし x-cache: MISS が頻発しているなら、それはネガティブキャッシュの設定値が短すぎるか、Cache-Control ヘッダーが no-store 等で上書きされている可能性がある。curl -I での確認を怠らないことだ。
—
5. 注意点：セキュリティとキャッシュ汚染
ネガティブキャッシュには明確なリスクもある。「キャッシュ汚染（Cache Poisoning）」だ。
万が一、攻撃者がキャッシュ可能なエラーレスポンスを意図的に引き起こし、それを正当なキャッシュとして汚染した場合、正常なリクエストまでエッジでエラー扱いされてしまう。これを防ぐには、以下のセキュリティ原則を遵守してほしい。
1. Vary ヘッダーの活用: Vary: Accept-Encoding だけでなく、必要に応じて Vary: Cookie や Vary: Authorization を適切に設定し、キャッシュのコンテキストを細分化する。
2. CDNキーの検討: 特定のパラメータのみをキャッシュキーに含めることで、無差別なキャッシュ汚染を防ぐ。
3. 監視の強化: 5xx エラーのキャッシュヒット率を Cloud Monitoring で可視化すること。急激なキャッシュヒットの増加は、攻撃の予兆である可能性がある。
—
最後に：ネットワークアーキテクトへの提言
ネットワークは「パケットが通る道」を作るだけではない。エッジという境界線で「何を拒絶し、何を保持するか」を定義することこそが、堅牢なシステムを作る。
ネガティブキャッシュは、一見すると地味な機能だ。しかし、パケットの往復を数ミリ秒削り、オリジンのCPU負荷を数％下げ、障害発生時の連鎖的なダウンを防ぐ。その積み重ねが、何万人ものユーザーがストレスなくサービスを利用できる「強靭なインフラ」を支えているのだ。
さあ、あなたの環境でも gcloud コマンドを叩き、エッジの挙動を最適化してみてほしい。ネットワークの深淵は、設定ファイルの一行から始まる。
コメント