CDN

CDNとは

CDN(Content Delivery Network)は、画像・CSS・JSなどの静的ファイルを、利用者に地理的に近いサーバー(エッジサーバー)からキャッシュして配信する仕組みです。オリジンサーバー(本来の配信元)への負荷を減らしつつ、表示速度を大きく向上させます。

日本のユーザー → 東京のエッジサーバー(キャッシュ済み)
米国のユーザー → バージニアのエッジサーバー(キャッシュ済み)
                → どちらもオリジンサーバーへは行かない(キャッシュヒット時)

初学者向けポイント

「本の中身」ではなく「本を置く倉庫を全国に増やす」イメージ。データそのものではなく配置場所を増やして速さを実現する
[[DNS]] の仕組みを使い、利用者に一番近いエッジサーバーへ自動的に振り分ける
キャッシュには有効期限(TTL)があり、更新したはずのファイルが古いまま配信される「キャッシュ切れ待ち」が定番のハマりどころ

最寄りのエッジサーバーへ届く仕組み

「一番近い拠点へ自動で振り分ける」と一言で言いますが、実現方法は主に2つあります。

DNSベースの振り分け — 名前解決のときに、問い合わせ元の場所に応じて返すIPアドレスそのものを変える方式([[DNS]])
エニーキャスト — 世界中の拠点が同じIPアドレスを広告し、経路制御によって最寄りの1台へ届く方式([[ユニキャスト・ブロードキャスト・マルチキャスト]])

どちらの方式でも、ここでいう「近い」はネットワーク上の近さであり、地図上の距離と必ずしも一致しません。国内からのアクセスが海外の拠点へ回ることもあり、そのときは ping で測るRTT(往復時間)が数十msから100ms超へ跳ね上がります。数字の読み方は [[帯域と遅延]] で扱っています。

主なメリット

メリット	内容
高速化	物理的な距離が縮まり、通信の往復時間(レイテンシ)が減る
負荷軽減	オリジンサーバーへのアクセスが減り、急なアクセス増にも耐えやすい
耐障害性	キャッシュがあればオリジンが一時的に落ちても配信を継続できる場合がある
セキュリティ	DDoS攻撃の吸収や [[HTTPS・TLS]] 終端をエッジ側で担うことも多い

キャッシュの当たり外れを決めるもの

CDNは「前に置けば速くなる箱」ではありません。効き方を決めるのはキャッシュキー、つまり「何を同じファイルとみなすか」の基準です。基本はURLですが、クエリ文字列やヘッダを含めるかは設定で変わります。含める設定のまま ?utm_source=... のような計測用パラメータ付きのURLが出回ると、中身が同じ画像が別物として何度も保存され、ヒット率が落ちます。

キャッシュは拠点ごとに独立している点も見落としがちです。東京の拠点で温まっていても、大阪の拠点にとって初めてのファイルはミスになり、その1回はオリジンまで往復します。拠点が多いほど「初回のミス」も増えるため、オリジンへの問い合わせを中間拠点でまとめる仕組み(オリジンシールドなどと呼ばれます)を用意しているCDNもあります。

更新を反映させる手段は3つです。TTLが切れるのを待つ・パージ(キャッシュ削除)を実行する・ファイル名を変える。このうち最も事故が少ないのは3つ目で、app.a1b2c3.js のように内容が変わればURLも変わる形にしておけば、古いものが配られる余地がそもそもありません。ヘッダの具体的な書き方は [[HTTPキャッシュ]]、DB問い合わせなどアプリ側のキャッシュとの層の違いは [[キャッシュ戦略]] が扱います。

避けたい事故が1つあります。ログイン後の個人向けページを共有キャッシュに載せてしまうことです。誰かの画面が別の人へ配信されるため、ここだけは設定を確認してください。ヘッダ側で共有キャッシュへの保存を禁じる private や no-store の指定は [[HTTPキャッシュ]] にまとまっています。

代表的なサービス

Cloudflare、Amazon CloudFront、Fastly などが代表例です。近年はSPAや静的サイトのホスティングそのものをCDN上で行うサービス(Vercel、Netlifyなど)も一般的になっています。静的ファイル専用という前提も崩れつつあり、短いTTLでHTMLをキャッシュしたり、拠点でコードを実行して認証や画像変換を行ったりする使い方が広がっています。

次の一歩を選ぶ地図

CDNは速度・キャッシュ・セキュリティが交差する場所にあります。目的別に、次に読む記事を並べます。

なぜ速くなるのかを納得する — [[帯域と遅延]] で「距離は回線を太くしても縮まらない」ことを押さえると、CDNが距離そのものを縮める手段だと腑に落ちます。最寄りへ誘導する経路の考え方は [[ユニキャスト・ブロードキャスト・マルチキャスト]] のエニーキャスト、改善が効いたかの計測は [[Webパフォーマンス最適化]] の Core Web Vitals が担当です。

キャッシュを正しく効かせる — 配信側への指示はHTTPヘッダで書きます。Cache-Control の指定と検証(304)は [[HTTPキャッシュ]]、計算結果や取得済みデータを持ち回すアプリ側の設計は [[キャッシュ戦略]] へ。役割の違う2つの層だと分かると、どちらを直すべきかで迷わなくなります。

攻撃を受け止める — 大量アクセスを分散基盤で吸収するのがCDNの防御面の役割です([[DDoS攻撃と対策]])。ただしオリジンのIPアドレスに直接アクセスできる状態ではCDNを迂回されるため、オリジンへの接続をCDN経由だけに絞る設定と、[[HTTPS・TLS]] をどこで終端しCDNとオリジンの間をどう暗号化するかの整理が必要です。

配信の先にあるもの — 拠点でコードまで動かす発想が [[エッジコンピューティング]]、中央から配らず利用者同士で配り合う対極の発想が [[P2P通信]] です。後者はリアルタイム性や中央集権の回避が目的のときに選択肢になります。

関連技術とのつながり

[[DNS]] — 利用者に最も近いエッジサーバーへ振り分ける際に使われる名前解決
[[HTTPS・TLS]] — エッジサーバー側で終端されることが多い暗号化層
[[クラウドコンピューティング]] — 主要CDNはクラウドプロバイダのサービスとして提供される
[[ロードバランサ]] — 複数拠点への振り分けという発想が共通する

Q: CDNが利用者を最寄りのエッジサーバーへ振り分ける方式として本文で挙げられているのはどれ?
- [ ] 全拠点へ同じデータを一斉送信するブロードキャスト
- [x] DNSで返すIPアドレスを変える方式と、同じIPを複数拠点が共有するエニーキャスト
- [ ] 利用者が拠点を手動で選んで設定する方式
解説: DNSベースの振り分けとエニーキャストの2つが代表的で、どちらも利用者が意識せず最寄りの拠点へつながります。

Q: 更新したファイルを確実に配信し直す手段として、最も事故が少ないとされるのはどれ?
- [ ] TTLが切れるのをひたすら待つ
- [x] 内容が変わったらファイル名(URL)も変える
- [ ] 拠点の数を増やす
解説: `app.a1b2c3.js` のように内容が変わるとURLも変わる形にしておけば、古いキャッシュが配られる余地がそもそもありません。

Q: 「キャッシュは拠点ごとに独立している」ことの帰結として正しいのはどれ?
- [x] 東京の拠点で温まっていても、大阪の拠点で初めて要求されたときはミスになりオリジンまで往復する
- [ ] 1つの拠点でキャッシュされると世界中の拠点へ即座にコピーされる
- [ ] キャッシュの有効期限は拠点ごとに無効になる
解説: 拠点ごとに別々のキャッシュを持つため「初回のミス」は拠点の数だけ起こり得ます。オリジンへの問い合わせを中間拠点でまとめるオリジンシールドのような仕組みはこの緩和策です。