CDN（コンテンツ配信）

何を解決する？

サーバが東京に1台しかないと、ブラジルからのアクセスは地球を半周します。光の速度には上限があるので、距離が遠いほど 往復の遅延（RTT） はどうやっても増えます。さらに人気サイトでは、同じ画像を世界中から何百万回も取りに来られ、その1台に負荷が集中します。CDN はこの2つを同時に解決します。

• ユーザーの 近く から返すので、距離由来の遅延が縮む
• エッジがキャッシュで肩代わりするので、オリジンの負荷が下がる（オフロード）
• アクセスが急増（バズ／セール）しても、エッジ群が トラフィックを吸収 してくれる

登場人物：オリジンとエッジ

CDN を理解する鍵は、サーバが2種類あることです。

エッジサーバが集まった各地の拠点を PoP（Point of Presence） と呼びます。ユーザーがどのエッジに振り分けられるかは、多くの場合 DNS や Anycast によって「地理的・ネットワーク的に近いPoP」へと自動で決まります。

配信の流れ（キャッシュヒットとミス）

画像 logo.png を例に、初回と2回目で何が起きるかを追います。

1. ユーザーがアクセス → DNS/Anycast で 最寄りのエッジ に到達する
2. エッジが自分のキャッシュを確認
3. 無い（キャッシュミス） → エッジが オリジンへ代理で取得。受け取った内容を ユーザーに返しつつ自分にも保存
4. 別のユーザーが同じ物を要求 → 有る（キャッシュヒット） → エッジが オリジンに行かず即返す
5. 保存した内容は TTL の間だけ有効。期限が切れたら、次のアクセス時にオリジンへ「まだ最新？」と確認しに行く

キャッシュ制御：TTL とパージ

「いつまでキャッシュしてよいか」は、基本的にオリジンが返す Cache-Control ヘッダ で決めます。

• Cache-Control: max-age=86400 → 「24時間キャッシュしてよい」（= TTL 1日）
• Cache-Control: no-store → キャッシュ禁止（毎回オリジンへ）
• Cache-Control: no-cache → キャッシュはするが、使う前に毎回オリジンへ 有効性を確認

TTL の長短はトレードオフです。

TTL が切れる前にどうしても内容を差し替えたい時は、パージ（Purge / Invalidation） でキャッシュを明示的に無効化します。ただしパージは反映に少し時間がかかり、回数に制限・課金があることも多いため、本命の手段は次の「キャッシュバスティング」です。

静的だけじゃない：動的コンテンツとCDN

CDN は画像・CSS・JS・動画のような 静的コンテンツ が最も得意です。中身が誰に対しても同じなので、安心してキャッシュを共有できます。

一方、ログインユーザーごとに変わるページや在庫数のような 動的コンテンツ は、そのままでは長くキャッシュできません。それでも現代のCDNは次のような形で動的領域を加速します。

• キャッシュしないリクエストも“通り道”として速くする：エッジ〜オリジン間に最適化された経路と常時接続を使い、TLSハンドシェイクや経路の無駄を削る
• エッジでの計算（エッジコンピューティング）：エッジ上で小さなコードを実行し、認証・A/Bテスト・簡単な組み立てをユーザーの近くで処理する
• 細かいキャッシュ：APIレスポンスを数秒だけキャッシュ、ページの一部だけをキャッシュ、など粒度を分ける

副次効果：CDNはセキュリティ層でもある

ユーザーとオリジンの間に巨大な分散網が挟まることで、CDN は配信高速化以外の役割も担います。

• DDoS の吸収：大量のトラフィックをエッジ群で受け止め、オリジンを守る
• WAF / TLS 終端：TLS の処理やリクエストのフィルタリングをエッジで実施
• オリジン隠蔽：本体サーバのIPを表に出さず、CDN経由だけに絞れる

CDN と ロードバランサ は「クライアントとサーバの間に立つ中継役」という点で似ていますが、CDN は 地理的に分散してキャッシュ配信 するのが主目的、ロードバランサは 1拠点内で複数サーバへ振り分け るのが主目的、という違いがあります。

つまずきポイント

• 何でも速くなるわけではない：キャッシュできない動的応答ばかりだと、ヒット率が低く効果は限定的
• 古い内容が残る：TTL とパージ、そしてキャッシュバスティングを設計しておかないと、更新が読者に届かない
• キャッシュキーに注意：クエリ文字列や Cookie、Accept-Encoding の扱い次第で、ヒット率が大きく変わる（不要なクエリでキャッシュが分裂する）
• エラーまでキャッシュされる：オリジンが一時的に返した 5xx を長くキャッシュしてしまう設定だと、障害が長引いて見える

ハンズオン

# レスポンスヘッダを見て、キャッシュ状況を確認する
# Cache-Control / Age / X-Cache(HIT/MISS) あたりに注目
curl -sI https://example.com/logo.png

# ヘッダだけ整形して眺める（-D - はヘッダを標準出力へ）
curl -s -o /dev/null -D - https://example.com/logo.png

# キャッシュバスティング：URL を変えると“別物”として再取得される
curl -sI "https://example.com/style.css?v=2"

# どのエッジ（拠点）に当たっているか、応答時間の内訳を見る
curl -s -o /dev/null -w "dns:%{time_namelookup} connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com/