Workers Cache を知る

「Cloudflare Workers実践LT 〜移行から運用、コストの話まで〜」の発表資料です！
https://findy.connpass.com/event/405562/

Transcript

1. Workers Cache を知る 2026-9-24 TECH BATON in 東京 〜 Cloudflare Workers実践LT 〜 @syumai
2. whoami syumai LayerX ソフトウェアエンジニア バクラクヘルプデスク エージェントを開発中 『[入門] Cloudflare Workers』著者 Asakusa.go / ECMAScript 仕様輪読会 主催 X: @__syumai Website: https://syum.ai © LayerX Inc.
3. 今日話すこと Workers Cacheとは？ 設定方法 従来のCache APIとの違い Workers Cacheの最大の特徴 zoneに縛られない その他の特徴 2段階Cache、async SWRなど 料金 © LayerX Inc. 3
4. Workers Cacheとは？
5. Workers Cacheとは？ 2026年7月にリリースされた、Workerの裏側ではなく、表側にあるCache https://blog.cloudflare.com/workers-cache/ Workerごとに前段にCacheを立てられる Cache HITすると、Worker自体が呼ばれない レンダリングもDBアクセスも走らない CPU時間の課金も発生しない © LayerX Inc. 5
6. 従来のCache API https://blog.cloudflare.com/workers-cache/ © LayerX Inc. 6
7. Workers Cache https://blog.cloudflare.com/workers-cache/ © LayerX Inc. 7
8. 従来のCache APIの使い方
9. 従来のCache APIの使い方 Cacheを引くのもWorkerの仕事なので、Workerは毎回実行される Cache HITでもCPU時間の課金が発生する zoneの設定が必要 では動作しない 独自ドメインの設定が必要 workers.dev © LayerX Inc. 9
10. 従来のCache APIの使い方 Workerのコード内から caches.default を明示的に呼んでいた → これが不要に！ © LayerX Inc. 10
11. Workers Cacheの設定方法
12. Workers Cacheの設定方法 wrangler.jsonc © LayerX Inc. に cache 設定を追加するだけ 12
13. Workers Cacheの使い方 Cacheの制御は Cache-Control などのレスポンスヘッダーで行う HTTP Cachingの仕様に沿った仕組み © LayerX Inc. 13
14. Workers Cacheの使い方 パージもWorkerのコードから呼ぶ Cache-Tag やパスのプレフィックスを指定できる ※ パージはWorker entrypointにスコープされる zoneの他のコンテンツを消し飛ばす心配がない © LayerX Inc. 14
15. Workers Cacheの最大の特徴
16. zoneに縛られない
17. zoneに縛られない 従来のCache APIはzoneごと Cache Rules、Page Rules、拡張子リスト etc. Workerはzoneの設定に合わせるか、Cache自体を回避するかのどちらかだった Workers CacheはWorkerごと zoneの設定は一切適用されない Workerのレスポンスの Cache-Control ヘッダーで制御 なんならWorker entrypointごとでも制御可能 © LayerX Inc. 17
18. 「Workerごとに前段にCacheが立つ」 とはどういうことか？
19. 「Workerごとに前段にCacheが立つ」とはどういうことか？ workers.dev ドメインでもCacheが効く プレビューURL、Workers for Platformsのテナントでも効く 複数zoneでCacheを共有できる Cacheはhostnameではなく、Workerに対してつく api.example.com と api.example.net で1つのCacheを共有できる Service bindingsの前段でもCacheが効く © LayerX Inc. 19
20. service binding Client Cache Worker A のCache © LayerX Inc. Worker A Cache Worker B Data source (DBなど) Worker B のCache 20
21. 応用: Worker内でのCache分離
22. 応用: Worker内でのCache分離 Workers CacheはすべてのWorker entrypointの手前に立つ default export、名前付き WorkerEntrypoint のどちらも対象 ctx.exports 経由の同一Worker内の呼び出しも対象 WorkerEntrypoint を分けることで、Worker内でも部分的にCacheを活用可能 認証する外側はCacheせず、重い内側だけCacheする、など © LayerX Inc. 22
23. Worker内でのCache分離の例
24. Worker内でのCache分離の例 どのentrypointをCacheするかは exports マップで指定する © LayerX Inc. 24
25. Worker内でのCache分離の例 外側: 認証処理だけ行って、リクエストを内側に流す 毎回実行される © LayerX Inc. 25
26. Worker内でのCache分離の例 内側: 重い処理。Cacheがこの手前に立つのでCache HIT時は実行されない © LayerX Inc. 26
27. その他の特徴
28. その他の特徴 2段階Cache 非公開コンテンツのキャッシュ ( ctx.props ) async stale-while-revalidate Vary © LayerX Inc. 28
29. 2段階Cache 世界のどこかで1度Cacheがstoreされたら、全データセンターがそのCacheを配信でき る仕組み Workerの実行回数を最小化できる Cacheが2つのtierに分かれている lower tier: ユーザーに最も近いデータセンターのCache upper tier: ネットワーク全体のfillを集約する層 設定不要で使える © LayerX Inc. 29
30. https://blog.cloudflare.com/workers-cache/ © LayerX Inc. 30
31. 非公開コンテンツのキャッシュ ( ctx.props ) 呼び出し側のWorkerが渡す ctx.props がキャッシュキーの一部になる props の値ごとに別のCacheエントリが作られる ユーザーAのための応答がユーザーBに漏れることがない 従来、認証付きのコンテンツはキャッシュ不可だった → ユーザーごとに分離してキャッシュ可能に © LayerX Inc. 31
32. async stale-while-revalidate 期限切れ後も、ユーザーを待たせずに裏で更新できる Fresh期間 ( max-age ): Cacheが応答。Workerは未実行 Stale期間 ( stale-while-revalidate ) stale応答を即返す ( Cf-Cache-Status: UPDATING ) 裏でWorkerが更新するので、誰も待たない 両方の期間の外: Workerが実行され、ユーザーが待つ 2月にCloudflareのzone Cacheでサポートされたものと同じものが使える https://developers.cloudflare.com/changelog/post/2026-02-26-async-stale-while-revalidate/ © LayerX Inc. 32
33. https://blog.cloudflare.com/workers-cache/ © LayerX Inc. 33
34. Vary 1つのURLに複数の表現がある場合に、ヘッダ値ごとに別バリアントを保存できる Cloudflareのzone Cacheでは、9月22日にCache Rulesを使って指定できるようになっ たばかり © LayerX Inc. https://blog.cloudflare.com/vary-support/ 34
35. 実測値からの補足 Cache API利用時と、Workers Cache利用時でCacheの振る舞いは基本的に同じだった Varyの解釈は異なった Workers Cache はVaryを自動でRFC準拠、CDNはopt-in設定が必要 HTTP Status 200のレスポンスのheuristic Cacheにはいずれも2時間のデフォルトTTLを仕様 Statusごとには異なっている部分も多い Workers Cache側の記載: 200, 203, 204 レスポンス -> 2時間 Cache API側の記載: 200, 206, 301 レスポンス -> 2時間 その他詳細は下記URLのレポートに記載しています https://github.com/syumai/research-cf-workers-cache © LayerX Inc. 35
36. 料金 結果 HIT (Worker未実行) MISS / BYPASS リクエスト 標準 標準 CPU 課金なし 課金あり ※注意: static assets・Worker間呼び出しも課金対象になる いずれもWorkerの手前のCacheを参照するようになるため © LayerX Inc. 36
37. まとめ Workers Cacheは、Workerの前段に立つCache Cache HIT時はWorker自体が実行されない への設定追加と Cache-Control ヘッダの指定だけで使える zoneではなくWorkerにつくので、 workers.dev でもService bindingsの前段でも効く Worker entrypoint単位でCacheを分離できる wrangler.jsonc © LayerX Inc. 37