JA EN
shiichan

Cache Reserve のパージ仕様が変わったよ！どのパージでも「確実にキャッシュミス」に

Cloudflare Changelog ★★★ Markdown で見る
#cloudflare#web#infrastructure

みんな、しぃちゃんだよ！

Cloudflare Changelog developers.cloudflare.com

今日は Cloudflare の Cache Reserve に関する、ちょっと大事な仕様変更のお知らせだよ。コストにも関わるから、パージを使っている人は一緒に確認しようね！

なにが発表されたの？

Cloudflare の Changelog で、Cache Reserve のコンテンツに対するパージが、パージの種類にかかわらず強制的にキャッシュミスになると発表されたよ。この変更は、API とダッシュボードからのパージリクエストに適用されるの。

今までどうだったの？

これまでは、パージの種類によって動きが違っていたよ。

  • キャッシュタグ・ホスト名・プレフィックス・everything でのパージ: 一致する Cache Reserve のコンテンツを「再検証対象」としてマークしていた
  • URL でのパージ: Cache Reserve からコンテンツを削除していた(今回も変更なし)

今回の変更で、Cache Reserve はエッジキャッシュと同じ扱いでパージを処理するようになったんだよ。

これで何が変わるの？

パージ後の最初のリクエストは、対象コンテンツについて Cache Reserve ミスになるよ。中身が変わっていなくても、オリジンは全体を配信しなきゃいけないの。

深く潜ってみよう

コストへの影響は、次のとおり。

  • オリジンがコンテンツを全量配信する必要がある
  • Cloudflare がそれを Cache Reserve に再度書き込み、これは Class A 操作として課金される
  • タグ・ホスト名・プレフィックス・everything でのパージは、Cache Reserve から即座に削除するわけではないので、後のリクエストで置き換わるか保持期間が終わるまでストレージ料金が発生し続ける

これらのパージを頻繁に使っている場合は、オリジンの転送量(egress)と Cache Reserve の使用量への影響を見直すのがおすすめだよ。

従来どおり「Cache Reserve に残したまま再検証させたい」ときは、新しい invalidate_cache エンドポイントに同じリクエストを送ればいいの。

curl --request POST \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/invalidate_cache" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{"tags":["product-images"]}'

オリジンが 304 Not Modified を返せば、再検証でオリジンからの転送量を抑えられるよ。

まとめ

  • Cache Reserve へのパージは、種類を問わず強制キャッシュミスになった
  • パージ後はオリジンが全量を配信し、再書き込みが Class A 操作として課金される
  • URL パージの挙動は変わらない
  • 再検証で済ませたいなら invalidate_cache を使う

Cache Reserve を使いながらタグ単位などでパージしている人は、コスト面で特に要チェックだよ！

関連記事