複数のエッジノードが上位階層の一箇所を経由してオリジンに到達するTiered Cache構成を表した代表画像

概要

この記事は Cloudflare Workers 静的サイトガイド - デプロイからSEOまで シリーズの一部です。

Workerが外部APIを呼び始めると、すぐにキャッシュが必要になります。かけなければオリジンの負荷がページビューの分だけ増えます。

かけること自体は1行で済みますが、その後に知らなければ必ず踏む罠がいくつかあります。特にエッジキャッシュが全世界で共有されないという点は、知ってしまえば当然ですが、知らなければ「なぜキャッシュが当たらないのか」としばらく悩むことになります。

この記事で扱うこと

  • キャッシュをかける2つの方法 — fetch() の cf オプションとCache API
  • エッジキャッシュがデータセンターごとに別であることと、その対応
  • Tiered Cacheでオリジンへのリクエストを減らす方法・そのとき cache.put() が使えない理由
  • 同じURLがヘッダーによって異なるレスポンスを返す場合のキャッシュキーの問題

扱わないこと

Workers Static Assetsの構造とデプロイは Cloudflare Workers 静的サイトホスティング - リクエストの流れと課金基準、ローカル開発は wrangler 使い方 - Cloudflare Workers のローカル開発とデプロイ にあります。

KV・R2・D1のようなストレージは範囲外です。この記事はHTTPレスポンスキャッシュのみを扱います。

キャッシュをかける2つの方法

① fetch() の cf オプション — レスポンスをCloudflareのエッジキャッシュに任せます（Request ドキュメント）。

1await fetch(url, {
2  cf: { cacheTtl: 3600, cacheEverything: true },
3});

② Cache API — 自分で入れて取り出します。

1const cache = caches.default;
2const hit = await cache.match(key);
3if (hit) return hit;
4// ...
5ctx.waitUntil(cache.put(key, response.clone()));

知っておくべきこと3つ

エッジキャッシュはデータセンターごとに別です。 ドキュメントの表現そのままです。

The contents of the cache do not replicate outside of the originating data center.

— Cache API

ソウルでキャッシュしたものを東京は知りません。全世界から入ってくるトラフィックを相手にすると、同じURLがデータセンターの数だけオリジンを叩きます。

**Tiered Cache がそれを減らしてくれます。下位のデータセンターがミスしたとき、オリジンではなく上位のデータセンターに先に問い合わせます。全プラン無料です。ただし、cache.put() で入れたものはTiered Cacheの対象外です** — そのため①の方式を使う方がよいです。

キャッシュキーはURLです。 同じURLがリクエストヘッダーによって異なるレスポンスを返す場合（Accept-Language など）、そのままにしておくと先に埋めた方が全員に返されます。cf.cacheKey でキーを変える方法がありますがEnterprise専用なので、それ以下のプランでは区別する値をURLのクエリに入れる必要があります。

まとめ

  • Workerが外部APIを呼ぶならキャッシュは選択ではありません。 かけなければオリジンがページビューの分だけ叩かれます。
  • かける方法は2つ。cf.cacheTtl の方をデフォルトにする方がよいです — cache.put() で入れたものはTiered Cacheに乗れません。
  • エッジキャッシュはデータセンターごとに別です。全世界のトラフィックなら Tiered Cache を有効にしましょう。全プラン無料です。
  • 同じURLがヘッダーによって異なるレスポンスを返すなら、区別する値をURLに入れる必要があります。 cf.cacheKey はEnterprise専用です。

参考