Cloudflare Workers を用いた動的コンテンツのマイクロキャッシング
参考になった
1
BASE株式会社 / yaakaito
テックリード / テックリード
| 利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|---|
エンタープライズ | SSL for SaaS, Workers, Cache | 10名以下 | 2025年6月 | B to C |
| 利用プラン | エンタープライズ |
|---|---|
| 利用機能 | SSL for SaaS, Workers, Cache |
| ツールの利用規模 | 10名以下 |
| ツールの利用開始時期 | 2025年6月 |
| 事業形態 | B to C |
アーキテクチャ
アーキテクチャの意図・工夫
既存システムの前段に Cloudflare Workers を配置し、オリジンが返す Cache-Control に沿ってキャッシュするプロキシとして動作させています。
Cloudflare 側は言語やアクセス元による出し分けと stale-while-revalidate の実装のみに留め、キャッシュ可否や TTL 判断は独自ロジック化しないことで、既存システムへの影響と Cloudflare 依存を抑えています。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
ネットショップ作成サービス「BASE」をご利用のショップのショップページは、リクエストごとに動的に HTML を生成して配信していました。 そのため、サービスの成長に伴う機能追加によるレスポンスタイムの悪化や、利用者増加に伴うアクセススパイク時の著しい性能劣化が課題となっていました。
どのような状態を目指していたか
ショップページを動的生成から静的配信に近い形へ移行し、エッジでのキャッシュ・配信を前提とした構成を目指していました。オリジンへリクエストを到達させない作りにすることで、全体の負荷を軽減し、アクセススパイク時の性能劣化を抑えることを狙っていました。
比較検討したサービス
- CloudFront + Lambda@Edge
- CloudFront + Functions
比較した軸
独自ドメインを現状のまま扱えること
- ショップオーナーの持ち込みドメインの DNS 設定を維持したまま移行できることが前提
- 既存のシステムで運用されている証明書の発行・更新も含めて移行できることが必要
キャッシュとストレージの自由度
- 将来的に柔軟なキャッシュ戦略を構築できるよう、エッジで利用できるキャッシュとストレージに自由度が必要
選定理由
Cloudflare for SaaS (SSL for SaaS)
このソリューションを利用することで、独自ドメインに関する課題はほとんど解決したと言えます。ショップオーナー側の DNS 設定を変更することなく Cloudflare を通過する経路に切り替えが可能で、証明書の管理も任せることができます。また、事前に証明書を発行しておける機能もあり、短時間のメンテナンスで切り替えを行うことができました。
ただし、現在では CloudFront にも同様の課題に対応する仕組みが追加されており、当時と状況が変わっている可能性がある点には注意が必要です。
Workers + KV or Cache
Cloudflare Workers を利用することで、エッジでの処理と KV / Cache を組み合わせたキャッシュ制御を、アプリケーションコードとして柔軟に実装できるようになりました。キャッシュキー設計やヘッダ加工、キャッシュの有効無効を含めてプログラマティックに操作しやすい点が大きな利点だと感じています。
CloudFront でも Lambda@Edge などで同様のことは可能に思えますが、こちらは基本的にはキャッシュすることを中心とした設計となっており、会員限定ページのようなキャッシュを意図的に無効化したい要件への対応に不安がありました。また、ストレージへの書き込みをエッジから行うことができない設計のため、今回の要件とはマッチしないと感じていました。
導入の成果
改善したかった課題はどれくらい解決されたか
2秒 + stale-while-revalidate 4秒相当のマイクロキャッシングを導入し、特定のショップや商品にアクセスが集中した際に、オリジンへの到達を大きく間引けるようになりました。集中時のキャッシュヒットレートは 90% を超えており、キャッシュから返ることで全体で見たレスポンス速度も向上しています。
現状では既存システムを完全に静的配信へ移行できていない中でも、大きなアクセススパイクに対応できる手応えを得られたと感じています。
どのような成果が得られたか
- レスポンス速度の改善
- 平常時は 1000ms を超えることが多い状態であったが、キャッシュヒット時は 100ms〜200ms でのレスポンスを実現
- アクセススパイクへの耐性向上
- 特定の人気ショップや商品がオリジンのリソースを占有してしまう状況が減少
- 今後の拡張性
- Cache API と Cache-Control を組み合わせた柔軟なキャッシュ制御を構築でき、段階的にキャッシュ戦略を広げていくことが可能に
導入に向けた社内への説明
上長・チームへの説明
Cloudflare から PoC 期間を提供していただき、独自ドメインとキャッシュについて実現可能かを事前に検証することができました。
PoC では、既存システムの延長線上でキャッシュを利用した高速化を開発環境に構築し、現実的に 1/10 程度のレスポンスタイムまで到達可能であることを実証しました。あわせて、独自ドメインの移行が可能であること、既存の仕組みに比べて管理が簡単になることを説明しました。設計やフィードバックでは、 Cloudflare に強く依存せず、必要に応じて見直せる余地があるかという点を特に重視していました。
また、キャッシュの導入に伴ってショップページの開発方法を一部変更していく必要がありました。具体的には、コンテンツがキャッシュされても問題ないよう、セッションを用いた出し分けや都度サーバーサイドに依存する処理を、少なくとも配信される HTML では行わないように変更していく必要がありました。ちょうど開発中だった機能で該当する部分があり、調整に協力してもらうこととなりました。この開発方針に関しては社内イベントで共有を行ったり、機能追加時のレビューの中でも継続的に考慮するようにしています。
活用方法
よく使う機能
- Workers / KV / Cache
- Cloudflare for SaaS
- Logpush
ツールの良い点
- Workers は Web 標準に沿った API を提供しており、開発ツールも充実しているため開発しやすい
- Workers とストレージ（KV / Cache など）を組み合わせる自由度が高く、プログラム可能で汎用性が高い
- 今回利用したもの以外にもソリューションが多く、導入できれば Waiting Room など周辺機能も含めて追加施策を検討しやすい
ツールの課題点
- Cache API を利用する場合、Cache-Control の stale-while-revalidate は機能せず独自の実装が必要
- アカウントや権限管理まわりは運用面で工夫が必要だと感じる
今後の展望
マイクロキャッシングで一定の効果を得られている一方で、全体のキャッシュヒット率が常に高いわけではありません。ピークタイムに多くのページが同時にアクセスされる状況では初回アクセスが並び、キャッシュミスによるオリジン到達でパフォーマンスが低下してしまうという課題があります。
また、これまではショップページがボトルネックになりがちでしたが、これが改善されたことでその後段にあるサービスへボトルネックが移動しており、システム全体としての最適化が十分ではありません。
今後は、コンテンツの静的化をさらに進めることに加え、事前のキャッシュ作成などによる全体のキャッシュヒット率の向上を検討しています。あわせて、システム全体の高速化や流量調整に向けて Cloudflare のさらなる活用も進めていきたいと考えています。
BASE株式会社 / yaakaito
テックリード / テックリード
よく見られているレビュー
BASE株式会社 / yaakaito
テックリード / テックリード
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法