この記事の要点

CDN (Content Delivery Network) は、世界各地に配置したエッジサーバにコンテンツをキャッシュし、利用者に最も近い拠点から配信する仕組み オリジン (元のサーバ) の負荷を肩代わりし、地理的に分散したエッジが代理配信することで応答を高速化し回線負荷を下げる キャッシュの鮮度は TTL (Time To Live) や Cache-Control ヘッダで制御する。動的コンテンツはキャッシュ対象から外す 大量の偽トラフィックをエッジで吸収する DDoS 緩和や、WAF・TLS 終端といったセキュリティ機能も提供する 代表的なサービスに Cloudflare・Amazon CloudFront・Fastly があり、静的配信・動画配信・サイト全体の高速化に使われる

概要

CDN (Content Delivery Network / コンテンツ配信ネットワーク) とは、画像・CSS・JavaScript・動画などのコンテンツを、世界各地に分散配置したエッジサーバ (キャッシュサーバ) に複製し、利用者に地理的に最も近い拠点から配信する仕組みです。元データを持つオリジンサーバへ全アクセスを集中させる代わりに、各地のエッジが代理で配信することで、応答速度を上げ、オリジンと回線の負荷を大幅に下げます。親項目は 負荷分散・プロキシ・CDN です。

CDN は実体としては地理的に分散した巨大な リバースプロキシ + キャッシュ群と捉えると理解しやすく、近年は単なる高速化だけでなく、DDoS 緩和や WAF、TLS 終端などセキュリティ機能の提供基盤としても重要になっています。

仕組み

利用者がコンテンツを要求すると、DNS によって最寄りのエッジサーバへ誘導されます。エッジは次のように動作します。

• キャッシュヒット: 要求されたコンテンツがエッジに保存済み (かつ鮮度内) なら、オリジンへ問い合わせずエッジから即座に返す。これが CDN の高速化の本質。
• キャッシュミス: エッジに無い、または期限切れなら、エッジがオリジンへ取りに行き (オリジンフェッチ)、取得したコンテンツをキャッシュしつつ利用者へ返す。次回以降はヒットになる。

キャッシュをどれだけの期間有効とみなすかは TTL (Time To Live) で決まり、オリジンが返す Cache-Control: max-age=... ヘッダなどで制御します。頻繁に変わらない静的ファイルは長めの TTL、頻繁に更新されるものは短め、ユーザ個別の動的コンテンツはそもそもキャッシュしない (Cache-Control: no-store)、という使い分けが基本です。HTTP ヘッダの基礎は HTTP を参照してください。

地理的に分散したエッジは、世界中からのアクセスをそれぞれの拠点で受け止めるため、結果として地理分散による負荷分散と、後述の DDoS 緩和を同時に実現します。

設定・実用例

オリジン側 (nginx 等) でキャッシュ制御ヘッダを返す例です。静的アセットは長期キャッシュ、HTML は短時間 + 再検証、API は no-store とします。

# nginx: 拡張子別にキャッシュ制御を出し分ける
location ~* \.(?:css|js|png|jpg|jpeg|gif|woff2)$ {
    # 静的アセットは長期キャッシュ (1 年, 変更時はファイル名を変える)
    add_header Cache-Control "public, max-age=31536000, immutable";
}

location = /index.html {
    # HTML は短時間、毎回オリジンで再検証
    add_header Cache-Control "public, max-age=60, must-revalidate";
}

location /api/ {
    # 動的・個人向けはキャッシュさせない
    add_header Cache-Control "no-store";
}

キャッシュが効いているかは応答ヘッダで確認できます。多くの CDN はヒット/ミスを示すヘッダを付与します。

# 応答ヘッダを確認 (Cache-Control や CDN のヒット表示を見る)
curl -I https://www.example.com/assets/app.css

# 例) 出力に含まれるヘッダ
#   cache-control: public, max-age=31536000, immutable
#   cf-cache-status: HIT          (Cloudflare の場合)
#   x-cache: Hit from cloudfront  (CloudFront の場合)

# コンテンツ更新時はキャッシュをパージ (各 CDN の API/管理画面で実施)
# 例: ファイル名にハッシュを付けてキャッシュバスティングするのが定石
#   app.css -> app.4f8a2c.css

主な用途

• 静的コンテンツ配信: 画像・CSS・JS・フォントなどをエッジから高速配信し、表示を速くする。
• 動画・大容量配信: 動画ストリーミングやソフトウェア配布を地理分散で効率配信する。
• オリジン負荷軽減: アクセスの大半をエッジで吸収し、オリジンサーバの負荷とコストを下げる。
• DDoS 緩和: 大量の攻撃トラフィックを世界中のエッジで分散吸収し、オリジンを守る。
• セキュリティ前段: TLS 終端・WAF・ボット対策をエッジで提供し、不正アクセスをオリジン手前で遮断する。

主要 CDN サービスの比較

サービス	提供元	特徴
Cloudflare	Cloudflare	DNS/WAF/DDoS 緩和まで統合、無料枠が広い
Amazon CloudFront	AWS	AWS 各サービスとの統合が強力
Fastly	Fastly	エッジでの即時パージと細かい制御が得意

注意点

• キャッシュの鮮度管理: TTL を長くしすぎると更新が反映されない。コンテンツ更新時はパージするか、ファイル名にハッシュを付けるキャッシュバスティングを行う。
• 動的コンテンツの誤キャッシュ: ログイン後のページや個人情報を誤ってキャッシュすると、他人に表示される重大事故になる。Cache-Control: no-store やキャッシュキー設計に注意する。
• オリジンの保護: オリジンの IP が漏れると CDN を迂回して直接攻撃される。オリジンは CDN からのアクセスのみ許可する設定にする。
• キャッシュキーの粒度: Cookie やクエリ文字列をキーに含めるかで、ヒット率と正しさが変わる。設計を誤るとヒット率が下がる。
• 地域差・障害: エッジの拠点が無い地域では効果が薄い。また CDN 自体の障害が広域影響を及ぼすため、フェイルオーバー方針も考える。

関連リンク

• 負荷分散・プロキシ・CDN
• リバースプロキシ
• ロードバランサ
• HTTP
• HTTPS