CDN・WAF・キャッシュ
このページで学ぶこと
Section titled “このページで学ぶこと”- CDNがWebサイトの表示速度と安定性を高める仕組み
- オリジンサーバーとエッジ配信の関係
- キャッシュによって速くなる一方、古い内容が残る理由
- WAFが守る範囲と、守れない範囲
- CDN・WAF・キャッシュについてPMが要件・運用で確認すべきこと
CDN（Content Delivery Network）は、Webサイトのファイルを利用者に近い拠点へ一時保存し、元の配信元まで取りに行かずに届ける仕組みです。
flowchart LR
O[オリジン<br/>S3・Webサーバー等]
C1[CDN拠点 東京]
C2[CDN拠点 大阪]
C3[CDN拠点 海外]
U1[利用者]
U2[利用者]
U3[利用者]
O --> C1
O --> C2
O --> C3
C1 --> U1
C2 --> U2
C3 --> U3
ここで、元の正しいファイルを持つ配信元をオリジン、利用者に近い配信拠点をエッジと呼びます。
CDNは何をするのか
Section titled “CDNは何をするのか”CDNの主な役割は次の通りです。
- 利用者に近い場所からファイルを配信する
- 同じファイルを一時保存し、オリジンへのアクセスを減らす
- 大量アクセスを複数拠点へ分散する
- オリジンのIPアドレスを直接公開しない構成を作る
- HTTPS証明書の終端を担う
- 圧縮・画像最適化・HTTP制御などを提供する
- WAFやDDoS対策と連携する
CDNは画像専用の仕組みではありません。設定により、HTML、CSS、JavaScript、画像、動画などを配信できます。
キャッシュとは
Section titled “キャッシュとは”キャッシュは、以前取得したファイルやデータのコピーを一時的に保存し、次回以降にすばやく利用する仕組みです。
Webサイトでは、複数の場所にキャッシュがあります。
flowchart LR
O[オリジン] --> C[CDNキャッシュ]
C --> B[ブラウザキャッシュ]
B --> U[利用者]
| キャッシュの場所 | 主な目的 | 更新時の注意 |
|---|---|---|
| ブラウザ | 同じ端末での再表示を速くする | 利用者の端末に古いファイルが残ることがある |
| CDN | 利用者に近い拠点から配信する | パージやTTL切れまで古い内容が配信されることがある |
| アプリ・CMS | APIやDBへのアクセスを減らす | データ更新とキャッシュ更新の整合が必要 |
| DNS | 名前解決を速くする | 接続先変更後も以前の情報が一時的に使われる |
「キャッシュを削除した」と言われた場合、どのキャッシュを指すか確認する必要があります。
キャッシュヒットとキャッシュミス
Section titled “キャッシュヒットとキャッシュミス”CDNに要求されたファイルが保存されている場合をキャッシュヒットと呼びます。CDNからすぐ返せるため高速です。
保存されていない場合はキャッシュミスとなり、CDNがオリジンへ取りに行きます。取得したファイルは、次のアクセスに備えて保存されることがあります。
sequenceDiagram
participant U as 利用者
participant C as CDN
participant O as オリジン
U->>C: ファイルを要求
alt CDNに保存済み
C-->>U: キャッシュから返す
else CDNにない
C->>O: オリジンへ要求
O-->>C: ファイルを返す
C-->>U: ファイルを返す
end
TTLとキャッシュ削除
Section titled “TTLとキャッシュ削除”TTL（Time To Live）は、キャッシュをどの程度保持するかを示す時間です。
TTLが長いほどオリジンへの負荷は減りますが、更新が反映されにくくなります。TTLが短いほど更新は反映されやすい一方、オリジンへのアクセスが増えます。
更新を即時反映したい場合は、次の方法があります。
- CDNのキャッシュを削除する
- ファイル名やURLを変更する
- キャッシュしない設定にする
- TTLを短くする
- コンテンツごとにキャッシュ方針を分ける
CSSやJavaScriptのファイル名にハッシュ値を付けるのは、内容が変わるたびに別URLとして扱わせ、古いキャッシュとの衝突を避けるためです。
「CMSを更新したのに変わらない」の切り分け
Section titled “「CMSを更新したのに変わらない」の切り分け”flowchart TD
A[CMSを更新した] --> B{CMSで公開済みか}
B -->|いいえ| C[公開状態・予約時刻・権限を確認]
B -->|はい| D{ビルドが必要か}
D -->|はい| E{ビルド・デプロイ成功か}
E -->|いいえ| F[Webhook・ビルドログを確認]
E -->|はい| G{CDNキャッシュは更新済みか}
D -->|いいえ| G
G -->|いいえ| H[パージ・TTL・再検証を確認]
G -->|はい| I{ブラウザだけ古いか}
I -->|はい| J[ブラウザキャッシュを確認]
I -->|いいえ| K[API・フロント実装を確認]
このように、CMSだけでなく、ビルド、デプロイ、CDN、ブラウザ、APIのどこでも問題が起こり得ます。
WAF（Web Application Firewall）は、WebサイトやWebアプリケーションへ届くHTTP通信を監視し、ルールに基づいて不正な通信を遮断する仕組みです。
flowchart LR
U[利用者・攻撃者] --> W[WAF]
W -->|許可された通信| O[Webサイト・API]
W -->|遮断| X[不正な通信]
WAFは、Webサイトの前段で通信を確認する門番のような役割です。
主に次のような対策へ利用されます。
- 不正なリクエストの遮断
- 既知の攻撃パターンの検知
- 特定国・IP・URLへのアクセス制御
- Botや自動アクセスの制御
- レート制限
- 緊急時のルール追加
WAFがあれば安全になるわけではない
Section titled “WAFがあれば安全になるわけではない”WAFは重要ですが、すべての問題を防げるわけではありません。
たとえば次は、WAFだけでは解決できません。
- 管理者へ過剰な権限を付与した
- APIキーを公開リポジトリへ保存した
- CMSのパスワードが漏えいした
- 個人情報を不適切に保存した
- アプリの業務ロジックに欠陥がある
- バックアップが存在しない
- 古いライブラリを放置した
- クライアント側JavaScriptに秘密情報を含めた
WAFは多層防御の一部です。
CDNとWAFの関係
Section titled “CDNとWAFの関係”CloudflareやCloudFront周辺サービスのように、CDNとWAFを組み合わせて提供するサービスがあります。
一般的な通信経路は次のようになります。
flowchart LR
U[利用者] --> D[DNS]
D --> E[CDN・WAF]
E --> O[オリジン]
O --> C[CMS・API・DB]
CDN・WAFが前段にあると、利用者は通常オリジンへ直接アクセスしません。そのため、DNS切替、証明書、アクセス制御、障害切り分けでは、CDN・WAFの設定も確認対象になります。
キャッシュ設計はコンテンツごとに異なる
Section titled “キャッシュ設計はコンテンツごとに異なる”| コンテンツ | キャッシュ方針の例 | 注意点 |
|---|---|---|
| ロゴ・画像 | 長めに保持 | 更新時はファイル名変更が有効 |
| CSS・JavaScript | 長めに保持 | ビルド時にハッシュ付きURLを使う |
| ニュース一覧 | 短め・再検証 | 更新反映時間を決める |
| 記事本文 | 更新頻度に応じる | 予約公開や修正反映を考慮 |
| ログイン後ページ | 原則慎重 | 他利用者の内容をキャッシュしない |
| フォーム完了画面 | キャッシュしない場合が多い | 再送信・個人情報に注意 |
| APIレスポンス | 内容に応じる | 権限・最新性・障害時を考慮 |
「すべてキャッシュする」「すべてキャッシュしない」ではなく、データの性質と更新要件で分けます。
実案件ではどう考えるか
Section titled “実案件ではどう考えるか”- 独自ドメインがCDNへ向いているか
- HTTPS証明書が設定されているか
- オリジンへ直接アクセスできる必要があるか
- キャッシュ対象・対象外が整理されているか
- CMS更新の反映時間が要件を満たすか
- WAF導入の目的とルールを決めているか
- 古いサイトのキャッシュが残らないか
- DNS切替とCDN設定の順序は正しいか
- 404・500等のエラーページを確認したか
- WAFが正常なフォームやCMS通信を遮断していないか
- キャッシュ削除の権限を持つ担当がいるか
- キャッシュヒット率やオリジン負荷を監視するか
- WAFで遮断が増えた場合に誰が判断するか
- 緊急更新時のパージ手順があるか
- CDN障害時に切り離すか、そのまま待つか
- ログをどこまで保存するか
PMチェックリスト
Section titled “PMチェックリスト”- CDNを導入する目的を説明できる
- オリジンの場所と管理者を把握している
- キャッシュ対象・対象外をコンテンツごとに整理している
- TTLと更新反映時間の要件が一致している
- 緊急時のキャッシュ削除手順と権限を決めている
- CMS更新から本番反映までの経路を図示している
- WAF導入の目的と保護対象を決めている
- WAFの誤検知時の対応手順がある
- CDN・WAFのログ確認担当を決めている
- オリジンへの直接アクセス可否を確認している
- CDN・WAFの費用と契約者を確認している
よくある誤解・失敗
Section titled “よくある誤解・失敗”「CDNを導入すれば必ず速くなる」
Section titled “「CDNを導入すれば必ず速くなる」”設定、ファイル容量、オリジン応答、JavaScript、外部タグなどによっては、CDNだけでは改善しません。
「キャッシュを長くすればよい」
Section titled “「キャッシュを長くすればよい」”長期間キャッシュすると高速になりますが、更新の反映が遅れる可能性があります。コンテンツの性質に応じた設計が必要です。
「WAFを入れれば脆弱性診断や更新は不要」
Section titled “「WAFを入れれば脆弱性診断や更新は不要」”WAFはアプリケーション自体の修正、権限管理、アップデート、診断の代わりにはなりません。
「キャッシュ削除は制作担当なら誰でもできる」
Section titled “「キャッシュ削除は制作担当なら誰でもできる」”本番配信に影響する操作です。権限、承認、対象範囲、実施記録を決める必要があります。
「更新が見えなければブラウザの再読み込みで解決する」
Section titled “「更新が見えなければブラウザの再読み込みで解決する」”CDN、ビルド、API、CMS公開状態などが原因の場合、利用者側の再読み込みだけでは解決しません。
理解度チェック
Section titled “理解度チェック”Q1. CDNのオリジンとは何でしょうか。
Section titled “Q1. CDNのオリジンとは何でしょうか。”回答と解説
CDNが元の正しいファイルやレスポンスを取得する配信元です。S3、Webサーバー、アプリケーションなどがオリジンになり得ます。Q2. キャッシュヒットとキャッシュミスの違いは何でしょうか。
Section titled “Q2. キャッシュヒットとキャッシュミスの違いは何でしょうか。”回答と解説
キャッシュヒットはCDN等に保存済みの内容を返せる状態です。キャッシュミスは保存されておらず、オリジンから取得する状態です。Q3. WAFがあれば、CMSの管理者権限を全員へ付与してもよいでしょうか。
Section titled “Q3. WAFがあれば、CMSの管理者権限を全員へ付与してもよいでしょうか。”回答と解説
よくありません。WAFは通信を監視・遮断する仕組みであり、CMS内の権限設計の代わりにはなりません。Q4. ニュースを更新したのに古い内容が表示される場合、どこを確認しますか。
Section titled “Q4. ニュースを更新したのに古い内容が表示される場合、どこを確認しますか。”回答と解説
CMSの公開状態、ビルド・デプロイ、API、CDNキャッシュ、ブラウザキャッシュ、予約時刻などを順に確認します。Q5. WAFが正常な問い合わせ送信を遮断した場合、何が必要ですか。
Section titled “Q5. WAFが正常な問い合わせ送信を遮断した場合、何が必要ですか。”回答と解説
WAFログで該当通信を確認し、安全性を判断したうえでルール調整や例外設定を行います。判断者、変更権限、再テスト手順を事前に決めます。- Cloudflare Learning Center「CDNとは」
https://www.cloudflare.com/ja-jp/learning/cdn/what-is-a-cdn/
CDNが利用者に近い場所からコンテンツを配信する仕組みを理解するための公式解説。 - Cloudflare Learning Center「キャッシングとは」
https://www.cloudflare.com/learning/cdn/what-is-caching/
ブラウザ、DNS、CDN等のキャッシュとTTLを理解するための公式解説。 - Cloudflare Learning Center「WAFとは」
https://www.cloudflare.com/learning/ddos/glossary/web-application-firewall-waf/
WAFの役割と保護範囲を理解するための公式解説。 - AWS「Amazon CloudFrontとは」
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html
エッジ拠点とオリジンの関係を確認するための公式資料。