Cloudflare CDN

解決する課題

• 遠いユーザーにも 低遅延 でコンテンツを届けたい
• オリジンサーバーの 負荷とデータ転送量（egress）を下げたい
• 世界配信でも HTTPS（TLS 終端）とアプリ層防御（WAF/DDoS 対策） を一体で担保したい
• 静的アセット（画像・JS/CSS・動画）を エッジで肩代わり し、オリジンへの往復を減らしたい

主要概念と用語

• エッジネットワーク: 世界中のデータセンターで構成される Cloudflare のネットワーク。ユーザーは最寄りの拠点にアクセスする（CloudFront の「エッジロケーション」に相当）
• オリジン (Origin): 配信元となるサーバーやオブジェクトストレージ。DNS でオレンジ雲（プロキシ有効）にした状態でエッジの背後に置く
• キャッシュルール (Cache Rules): パスやパターン単位でキャッシュ可否・キャッシュキー・TTL を制御する設定単位。従来の「ページルール」の後継
• Cache Level / Edge TTL / Browser TTL: エッジでのキャッシュ期間とブラウザでのキャッシュ期間をそれぞれ制御する設定
• Tiered Cache: 上位（上流）データセンターを経由させることでオリジンへのリクエストを集約し、キャッシュヒット率を高める仕組み
• Cache Reserve: 頻度の低いオブジェクトも含めて長期間キャッシュを保持する永続ストレージ層
• パージ (Purge): キャッシュを明示的に無効化する操作。全体パージ・URL 単位パージ・タグ/ホスト単位パージなどがある
• オレンジ雲 (Proxied): DNS レコードを Cloudflare のプロキシ経由にする設定。CDN・WAF・DDoS 防御が有効になる前提条件

仕様・制限・クォータ

• キャッシュ対象はデフォルトで 静的なファイル拡張子（画像・CSS・JS 等）が中心。HTML や動的レスポンスは既定でキャッシュされないため、明示的なキャッシュルールが必要
• キャッシュできるレスポンスサイズには上限があり、超過分はキャッシュされずオリジンへの都度アクセスになる
• パージの粒度や頻度、キャッシュルールの作成数はプランによって上限が異なる
• Cache-Control ヘッダーなどオリジンの指示を尊重する設定と、Cloudflare 側の設定で上書きする設定を選べる
• 反映は基本的に短時間で全エッジに伝播するが、パージ直後でも一時的に古いレスポンスが返ることがある

内部の仕組み

ユーザーは最寄りの エッジデータセンター にアクセスします。エッジは TLS を終端し、必要に応じて WAF・DDoS 防御ルールを評価したうえで、キャッシュがあれば即座に返し（キャッシュヒット）、なければ オリジンへ取りに行き（キャッシュミス、オリジンフェッチ） レスポンスをキャッシュします。何をどれだけキャッシュするかは キャッシュルールと TTL 設定 で決まります。

• Tiered Cache を有効にすると、末端エッジがキャッシュミスした際にまず上位データセンターを確認し、そこにもなければオリジンへ向かう。これによりオリジンへの同時アクセスが集約される
• Cache Reserve はさらに長期間・大容量のオブジェクトをオブジェクトストレージ相当の永続層に保持し、エッジキャッシュからも溢れたコンテンツを守る
• 同じエッジで WAF・レート制限・ボット対策 も同時に実施され、キャッシュ判定とセキュリティ評価が一つのリクエストパスの中で行われる

設計パターン / ベストプラクティス

• 静的サイト配信: オブジェクトストレージや静的ホスティングをオリジンにし、キャッシュルールで TTL を長めに設定してエッジ配信を最大化する
• パスごとに最適化: 静的アセットは TTL を長く、API や動的パスはキャッシュ対象外に分けてキャッシュルールを設計する
• オリジン保護: オリジンへの直接アクセスを避け、Cloudflare のエッジ経由のみを許可する（オリジン側で送信元 IP を絞る、認証ヘッダーを要求するなど）
• ヒット率向上: アクセスが分散しやすい構成では Tiered Cache を有効化し、オリジンへの往復を減らす
• 大容量・低頻度アクセスのコンテンツ: Cache Reserve を組み合わせて、キャッシュから溢れやすいオブジェクトも長期保持する

運用・監視

• アナリティクス（Cache Analytics） でキャッシュヒット率、リクエスト数、帯域の推移を可視化する
• ログ（Logpush 等）で「キャッシュから返ったのか、オリジンまで到達したのか」をステータスやキャッシュ判定ヘッダーで切り分ける
• 反映されない、または古い内容が返る場合は、まずキャッシュルールと TTL、オリジンの Cache-Control ヘッダーを確認する
• 5xx エラーが出る場合はオリジン側の健全性（応答時間、証明書、ファイアウォール設定）を確認する

コスト

セキュリティ

• HTTPS 強制: エッジで TLS を終端し、HTTP から HTTPS へのリダイレクトや HSTS を有効化できる
• オリジン秘匿: オリジンへの直接到達を防ぐため、Cloudflare からのアクセスのみを許可する設定（許可リストや認証ヘッダー）を組み合わせる
• WAF・DDoS 防御と一体: 同じエッジで WAF ルール、ボット管理、レート制限を適用でき、キャッシュ配信とセキュリティ制御が分離しない
• 権限分離: アカウント配下でメンバーやトークンの権限を分け、キャッシュルールや DNS 設定の変更権限を限定する

関連サービス・比較

ハンズオン / CLI例

Cloudflare のキャッシュ設定自体は主にダッシュボードや REST API で行いますが、Workers を使えばレスポンスの Cache-Control ヘッダーやキャッシュ挙動をコードで制御できます。ここでは wrangler で簡単な Worker をデプロイし、静的アセットに長い TTL を付与する例を示します。

# 1) プロジェクトを作成
npm create cloudflare@latest -- cdn-cache-demo

# 2) wrangler にログイン
npx wrangler login

# 3) src/index.ts でオリジンからのレスポンスに Cache-Control を付与する処理を実装後、
#    ローカルで動作確認
npx wrangler dev

# 4) 本番へデプロイ
npx wrangler deploy

# 5) デプロイ後、レスポンスヘッダーでキャッシュ状態を確認
curl -I https://cdn-cache-demo.example.workers.dev/assets/app.js