はい、承知いたしました！GCP Cloud CDNのネガティブキャッシュについて、インフラやネットワークに初めて触れるエンジニアの方にも分かりやすく、実務で役立つ情報満載のブログ記事を作成します。パケットが駆け巡る様子を、身近な例え話を交えながら、丁寧に解説していきますね。
—
GCP Cloud CDNのネガティブキャッシュで、オリジンサーバーの「不在」を賢く管理しよう！
皆さん、こんにちは！AWSもGCPも、日々進化していて追いつくのが大変ですよね。でも、ちょっとした工夫で、日々の運用がぐっと楽になる、そんな「なるほど！」を皆さんと共有できたら嬉しいです。
今回は、Google Cloud Platform (GCP) の CDN である「Cloud CDN」の、ちょっとマニアックだけど、知っておくと「あ、あの時のエラー、これで防げたかも！」と膝を打つことになるかもしれない、「ネガティブキャッシュ（Negative Caching）」について、じっくり掘り下げていきたいと思います。
「ネガティブキャッシュ？なにそれ？美味しいの？」と思ったあなた、大丈夫！難しい話は一旦置いて、まずは身近な例から考えてみましょう。
郵便配達員さんの「不在票」に学ぶ、ネガティブキャッシュの考え方
想像してみてください。あなたは楽しみにしていたオンラインショッピングの商品が届くのを待っています。でも、ポストには「不在票」が入っていました。
- 「えー、今日届くはずなのに、もう一度来るのかな…」
- 「再配達の手配、面倒だな…」
こんな時、郵便配達員さんが「あ、この家は今、確実に不在だな。次にここに来るときも、もしかしたら不在の可能性が高い。とりあえず、この情報は一旦覚えておこう。」と思ってくれるとしたら、どうでしょう？
もし、配達員さんが「この家は不在」という情報を一時的に覚えていて、次にそこを通るときに、わざわざピンポンを押さずに「やっぱり不在だな」と判断して、次の配達先へ向かってくれたら、配達員さんはもっと効率的に仕事ができますよね。
これが、まさにネガティブキャッシュの考え方です。
ネガティブキャッシュとは？
Cloud CDNにおけるネガティブキャッシュとは、オリジンサーバー（皆さんが開発しているウェブサイトやアプリケーションが動いているサーバーのことです）が「そのファイル（コンテンツ）は存在しませんよ！」や「サーバーが一時的に調子悪いんです…」といったエラーを返したときに、Cloud CDNのエッジサーバーが、その「エラーレスポンス」自体を一時的にキャッシュしてくれる仕組みのことです。
「え、エラーをキャッシュするの？なんか、もっとダメな感じがする…」と思ったかもしれません。でも、これにはとっても大きなメリットがあるんです。
ネガティブキャッシュのメリット：オリジンサーバーへの負担軽減とユーザー体験の向上
1. オリジンサーバーへの負担軽減:
もし、存在しないファイルへのリクエストが大量に来た場合、その都度オリジンサーバーは「404 Not Found（見つかりません）」というエラーを返さなければなりません。これが大量に発生すると、オリジンサーバーは本来の仕事（コンテンツの配信）ができなくなってしまい、パフォーマンスが低下したり、最悪の場合、ダウンしてしまう可能性もあります。
ネガティブキャッシュが有効になっていると、エッジサーバーが「あ、このリクエストは前もエラーになったやつだ」と判断し、オリジンサーバーに問い合わせることなく、すぐに「404 Not Found」などのエラーレスポンスを返してくれます。これにより、オリジンサーバーへの無駄な負荷を減らすことができるのです。
2. ユーザー体験の向上:
ユーザーが間違ったURLにアクセスしたり、一時的にオリジンサーバーが応答できない場合でも、Cloud CDNのエッジサーバーがキャッシュされたエラーレスポンスを返すことで、ユーザーは「ページが表示されない…」という、より直接的なタイムアウトエラーではなく、「Not Found」などの、より分かりやすいエラーメッセージを見ることができます。これにより、ユーザーは「なんかおかしいな」とすぐに気づき、適切な対応（URLの確認など）を取りやすくなります。
さらに、オリジンサーバーが一時的にダウンしている場合など、復旧までの間、ユーザーに「Not Found」というエラーを返し続けることで、ユーザーに「サービスが完全に停止しているわけではない」という安心感を与えることもできます（もちろん、これは状況によりますが）。
どんなエラーがキャッシュされるの？
Cloud CDNのネガティブキャッシュでキャッシュされるのは、主に以下のようなHTTPステータスコードのエラーレスポンスです。
404 Not Found(リソースが見つからない)405 Method Not Allowed(許可されていないHTTPメソッドが使われている)410 Gone(リソースは恒久的に削除された)500 Internal Server Error(オリジンサーバー内部でエラーが発生した)502 Bad Gateway(オリジンサーバーからの無効な応答)503 Service Unavailable(オリジンサーバーが利用できない)504 Gateway Timeout(オリジンサーバーからの応答タイムアウト)
これらのエラーは、ユーザーからのリクエストに対して、オリジンサーバーが「お手上げ状態」であることを示しています。ネガティブキャッシュを有効にすることで、この「お手上げ状態」の情報をエッジサーバーが一時的に覚えておいてくれる、というイメージですね。
Cloud CDNでネガティブキャッシュを有効にする方法
さて、この便利なネガティブキャッシュ、どうやって有効にするのでしょうか？Cloud CDNは、Google Cloud Console（ブラウザから操作できる管理画面）やgcloudコマンドラインツールから設定できます。
ここでは、gcloudコマンドを使った設定方法を見ていきましょう。
1. CDNキャッシュポリシーの作成または更新
Cloud CDNの設定は、「キャッシュポリシー」という単位で行います。既存のキャッシュポリシーを更新するか、新しく作成して、ネガティブキャッシュに関する設定を追加します。
まず、現在のキャッシュポリシーを確認してみましょう。
# 現在のキャッシュポリシー一覧を表示
gcloud compute backend-services describe YOUR_BACKEND_SERVICE_NAME --global --format='yaml(cdnPolicy)'YOUR_BACKEND_SERVICE_NAME は、皆さんがCloud CDNを設定しているバックエンドサービスの実際の名前に置き換えてくださいね。
次に、ネガティブキャッシュを有効にするためのキャッシュポリシーを作成（または更新）します。
# 新しいキャッシュポリシーを作成する場合
gcloud compute url-maps import YOUR_URL_MAP_NAME \
--source=path/to/your/url_map.yaml
# 既存のバックエンドサービスにキャッシュポリシーをアタッチする場合
# (上記 url_map.yaml を作成・編集後、url-maps import するのが一般的です)
# もしくは、既存のバックエンドサービスに直接キャッシュポリシーを設定・更新する場合
gcloud compute backend-services update YOUR_BACKEND_SERVICE_NAME \
--global \
--cdn-policy-cache-mode=CACHE_ALL_STATIC \
--cdn-policy-negative-caching-allowed=true \
--cdn-policy-client-ttl=3600 \
--cdn-policy-default-ttl=86400 \
--cdn-policy-max-ttl=31536000ポイント解説
--cdn-policy-negative-caching-allowed=true: これが、ネガティブキャッシュを有効にするための最も重要な設定です！これをtrueにすることで、先ほど説明したエラーレスポンスのキャッシュが可能になります。--cdn-policy-client-ttl: クライアント（ブラウザなど）がキャッシュを保持する最大時間です。--cdn-policy-default-ttl: キャッシュのデフォルトの有効期間です。--cdn-policy-max-ttl: キャッシュの最大有効期間です。
これらのTTL（Time To Live）設定は、ネガティブキャッシュが「どれくらいの時間、エラー情報を覚えておくか」という期間にも影響してきます。例えば、オリジンサーバーが一時的なメンテナンスで数分間だけダウンしている場合、ネガティブキャッシュのTTLを短く設定しておくことで、サーバー復旧後すぐに正しいコンテンツを配信できるようになります。逆に、恒久的に削除されたリソースであれば、TTLを長めに設定しておいても問題ないでしょう。
2. エラーレスポンス保持期間の設定
ネガティブキャッシュでは、キャッシュされるエラーレスポンスの保持期間（TTL）も設定できます。これは、gcloud compute backend-services update コマンドのパラメータとは別に、より細かく設定できる場合があります。
例えば、url-mapsのYAMLファイルで、特定のエラーコードに対して異なるTTLを設定することも可能です。
# path/to/your/url_map.yaml の例
defaultService: projects/YOUR_PROJECT_ID/global/backendServices/YOUR_BACKEND_SERVICE_NAME
hostRules:
- hosts:
- '*'
pathMatcher: allpaths
...
pathMatchers:
- name: allpaths
defaultService: projects/YOUR_PROJECT_ID/global/backendServices/YOUR_BACKEND_SERVICE_NAME
routeRules:
- priority: 1
matchRules:
- fullPathMatch: /some/resource
# 特定のリソースに対するネガティブキャッシュTTL設定
# この例では、404エラーを60秒間キャッシュします
cdnPolicy:
cacheMode: CACHE_ALL_STATIC
negativeCachingAllowed: true
negativeCacheTtl: 60 # 秒単位
routeAction:
backendService: projects/YOUR_PROJECT_ID/global/backendServices/YOUR_BACKEND_SERVICE_NAME
...このように、negativeCacheTtl パラメータで、該当するエラーレスポンスを保持する秒数を指定できます。この設定は、cdnPolicy の下で、特定のリソースやパス、あるいはルートルールごとに適用できます。
注意点:
negativeCacheTtl の設定は、clientTtl や defaultTtl よりも優先される場合があります。どのようなTTL設定が有効になるかは、Cloud CDNのドキュメントで最新の挙動を確認しながら、実際にテストしてみるのが一番確実です。
実際に試してみよう！
設定はできましたが、本当に動いているのか気になりますよね！
1. オリジンサーバーで意図的にエラーを発生させる:
まず、オリジンサーバーで、存在しないファイルにアクセスするようなリクエストを投げ、404 Not Found などのエラーが返ってくることを確認します。
2. Cloud CDN経由でアクセスする:
次に、Cloud CDNのエンドポイント（CDNが適用されているURL）から、同じリクエストを投げます。
3. キャッシュの確認:
- 初回: エラーレスポンスが返ってくるはずです。
- 2回目以降（TTL内）: ネガティブキャッシュが有効であれば、オリジンサーバーに問い合わせず、エッジサーバーから直接エラーレスポンスが返ってきます。
curl -IコマンドなどでHTTPヘッダーを確認すると、Cache-Controlヘッダーなどにキャッシュに関する情報が表示されることがあります。 - TTL経過後: TTLが切れると、再度オリジンサーバーに問い合わせが行われ、もしオリジンサーバーがまだエラーを返していれば、再びエラーレスポンスが返ってきます。
curl コマンドを使った簡単な確認例
オリジンサーバーのIPアドレスが 192.0.2.1 で、CDNのエンドポイントが cdn.example.com だと仮定します。
まず、オリジンサーバーに直接アクセスして、存在しないファイルへのリクエストでエラーを確認します。
curl -I http://192.0.2.1/non-existent-file.jpg次に、Cloud CDNのエンドポイントにアクセスします。
curl -I https://cdn.example.com/non-existent-file.jpgもしネガティブキャッシュが有効で、TTL内であれば、2回目の curl コマンドでは、オリジンサーバーに負荷をかけることなく、エッジサーバーから直接 404 Not Found が返ってくるはずです。
まとめ：賢く使って、運用を楽に！
Cloud CDNのネガティブキャッシュは、オリジンサーバーへの無駄な負荷を減らし、サービス全体の可用性を高めるための、非常に強力な機能です。特に、短時間で大量に発生する「存在しないリソースへのアクセス」や、オリジンサーバーの一時的な不調からの復旧を早めたい場合に、その真価を発揮します。
もちろん、闇雲に有効にすれば良いというものではありません。
- キャッシュ期間（TTL）の適切な設定: どのくらいの期間、エラー情報を保持すれば、オリジンサーバーへの負荷軽減と、最新情報への反映のバランスが取れるのか、アプリケーションの特性に合わせて検討しましょう。
- エラーの種類に応じた設定: 全てのエラーをキャッシュするのではなく、特定の重要なエラーのみを対象にする、といった細かい制御も可能な場合があります。
今回ご紹介した設定方法や考え方を参考に、ぜひ皆さんの環境でも Cloud CDN のネガティブキャッシュを検討してみてください。きっと、日々の運用が少しでも楽になるはずですよ！
最後までお読みいただき、ありがとうございました！また次の記事でお会いしましょう！
コメント