年三日坊主のKKです。
Web関連技術は複雑化する傾向が強いので説明しようとすると意外と大変なものが多いです。
そんなもののひとつがWebサイトの高速化や負荷分散の文脈でよく出てくる「CDN（Content Delivery Network）」かと思います。
最近では多くのCDNがWAFなどのセキュリティ機能を持つようになって来ており、更にサービス事業者によって実装も違うことが多いため、益々ややこしい存在になりつつあります。
そのため、仕組みをちゃんと説明しようとすると意外と難しいです。
この記事では、
- CDNの基本的な仕組み
- よくある誤解
- 実際の構成イメージ
- 導入パターン（プロキシ型 / オフロード型）
を、できるだけシンプルに整理してみようと思います。
CDNとは何か？
CDNとは一言でいうと：
👉 「ユーザの近くからコンテンツを配信する仕組み」
です。
通常のWebアクセスでは：
| ユーザ → 遠くのサーバ（「オリジン」と呼びます） |
となるため、オリジンとユーザの距離が遠いほど遅くなります。
CDNを使うと：
| ユーザ → 近くのCDN → オリジン |
となり、ユーザの近くのサーバから配信されるため高速化されます。
今回の前提（例）
以下のようなシンプルなWebサイトを例にします：
-
www.example.com/index.html （静的）
-
www.example.com/img/logo.png （静的）
-
www.example.com/cgi/counter.cgi（動的）
- オリジンサーバ：
www.example.com - CDNエッジ：
cdn000.example.com
CDNの基本機能①：キャッシュ
CDNの一番重要な機能はキャッシュです。
初回アクセス
| ユーザ → CDN → オリジン ↓ コンテンツ取得 ↓ CDNに保存 |
2回目以降
| ユーザ → CDN（キャッシュあり） ↓ 即レスポンス |
👉 オリジンまでコンテンツを取りに行かないので速い
CDNの基本機能②：オンデマンドキャッシュ
ここは初心者がよく誤解するポイントです。
❌ よくある誤解
「CDNはオリジンのコンテンツ全部をキャッシュとして世界中にコピーする」
✔ 実際
👉 実際にアクセスされた要素だけがアクセスされた場所でキャッシュされる（オンデマンド）
| 東京ユーザ → 東京CDN → キャッシュ作成 NYユーザ → NY CDN → キャッシュ作成 ※ロンドンユーザがアクセスしなければロンドンCDNにキャッシュは作成されない。 |
- 各エッジは独立
- オリジンの全コンテンツを無条件にキャッシュするわけではない
- 自動同期はしない
CDNの基本機能③：近くのサーバが応答
CDNはユーザに最も近いサーバに誘導します。
| 大阪ユーザ → 大阪CDN NYユーザ → NY CDN |
👉 通信距離が短くなり高速化
静的コンテンツと動的コンテンツ
CDNはすべてのコンテンツをキャッシュできるわけではありません。
より正確には、キャッシュできないわけではないですが、コンテンツ制作者の意図と異なる表示なる恐れがあるため注意が必要です。
静的コンテンツ（CDN向き）
静的コンテンツ＝基本的にアクセスするたびに内容が変わらない要素
| index.html logo.png |
👉 キャッシュ可能
※静的コンテンツを更新した場合のキャッシュ反映については別記事で解説する予定です。
動的コンテンツ（CDNに不向き）
動的コンテンツ＝基本的にアクセスするたびに内容が変わる要素
| counter.cgi |
👉 アクセスごとに変わるため
- キャッシュしない
- 毎回オリジンへ
※動的コンテンツでもアクセスごとに内容が変わらないならキャッシュしても大丈夫。
CDNの全体の流れ
-
ユーザアクセス
-
CDNへ誘導
-
キャッシュ確認
-
なければオリジンから取得
-
キャッシュして返す
👉 シンプルだけど強力
CDNの導入パターン
既存サイトにCDNを導入する場合、大きく2つの方法があります。
パターン①：プロキシ型（リバースプロキシ）
概要
元のドメインのままCDNを挟む方式です。
| ユーザ ↓ www.example.com（実体はCDN） ↓ CDN ↓ オリジン |
DNSでCDNに向けるのがポイント。
※wwwの付かないドメインの場合、DNSとCDNの組み合わせに制約がある場合もあります。
動作
| ユーザ →CDN ↓ キャッシュあり → 即返答 キャッシュなし → オリジン取得 |
この例での挙動
| コンテンツ | 挙動 |
|---|---|
| index.html | CDNキャッシュ |
| logo.png | CDNキャッシュ |
| counter.cgi | オリジン |
メリット
- 導入が簡単（既存コンテンツの修正がほぼ不要）
- サイト全体を高速化
- HTTPSやDDoS対策、WAFもまとめて適用可能
注意点
- 動的コンテンツの制御が必要
- CDN障害の影響が大きい
パターン②：オフロード型（静的配信分離）
概要
静的コンテンツだけCDNに逃がす方式です。
構成
| ユーザ→www.example.com（HTML） ↓ HTML内でCDN参照 ↓ cdn.example.com |
URLの変化
変更前：www.example.com/img/logo.png
変更後：cdn.example.com/img/logo.png
動作
| ① HTML → オリジン ② 画像 → CDN |
この例での挙動
| コンテンツ | 配信元 |
|---|---|
| index.html | オリジン |
| logo.png | CDN |
| counter.cgi | オリジン |
メリット
- 影響範囲が限定される
- 段階導入が可能
- トラブル時も安全
注意点
- HTMLの修正が必要
- ドメイン分離による制約（Cookie / CORS）
プロキシ型 vs オフロード型
| 項目 | プロキシ型 | オフロード型 |
|---|---|---|
| 導入の簡単さ | ◎ | △ |
| 柔軟性 | △ | ◎ |
| 影響範囲 | 大 | 小 |
| 初心者向け | ◎ | ○ |
どちらを選ぶべきか？
ざっくり：
- まずは簡単に導入したい → プロキシ型
- 安全に試したい → オフロード型
まとめ
CDNはシンプルに言うと：
👉 「ユーザの近くにコピーを置いて速くする仕組み」
重要ポイントはこの3つ：
- キャッシュで高速化
- 必要な要素だけキャッシュ
- ユーザに近いサーバが応答
まずはここまで理解して頂ければ具体的な運用や実装の話に進めるのではないかと思います。
