中級ではTTLとキャッシュ制御を見ました。上級では、キー設計・階層・エッジの内部へ。
上級の解説は準備中のため、上級の内容を表示しています。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
エッジの内部と階層
- キャッシュキー正規化 — URL・選ばれたクエリ・Vary（言語や圧縮）で「同じ内容は同じキー」に
- 階層キャッシュ — エッジ → シールド層 → オリジン。オリジンへの問い合わせを束ねる
- collapse forwarding — 同一キーの同時ミスを1本化してオリジンを守る
配信の流れ（詳細）
- エッジでキャッシュキーを計算し照合
- hit（TTL内）なら即返す。stale-while-revalidate／stale-if-errorで古くても返しつつ更新
- miss／期限切れは条件付きリクエスト（ETag・If-None-Match）でオリジンに確認
- 変わっていなければ304、変わっていれば新版を取得しTTL付きで保存
高度な機能
- エッジコンピュート — エッジで軽い処理（A/B・認証・リライト）を実行し、往復を減らす
- TLS終端をエッジで — 近い場所で暗号処理、オリジンまで再暗号化も
- Anycast — 同一IPを各地で広告し、最寄りへ誘導
- ログ集約と分析 — 多数のエッジのログを集めて可視化
⚠️ 落とし穴
- hit率低下 — キーの細分化、キャッシュ不可ヘッダの付けすぎ
- 個人情報の誤キャッシュ — Vary設計ミスで個人向けが共有される（別途、攻撃としてのキャッシュ汚染／ポイズニングも存在）
- パージ遅延 — 全エッジへの無効化が伝わるまでの時間差
- オリジン過負荷 — シールド／collapseが無いと、ミス時に殺到
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. キャッシュキーを不用意に細かくするとどうなる？
問2. 多数のエッジが同時にミスしてオリジンへ殺到するのを、上位の共有層で束ねて防ぐ構成は？
問3. CDNで「同一IPを各地で広告し、利用者を最寄りのエッジへ誘導する」仕組みは？
問4. TTL切れ時、エッジがETagをIf-None-Matchで送り「変わっていない」と確認できたとき、オリジンが返すステータスコードは？
問5. オリジンがエラーを返したとき、期限切れのコピーでも返して可用性を保つ指示に最も近いのは？
問6. 「エッジで軽い処理（A/B・認証・リライトなど）を実行し、オリジンまでの往復を減らす」ものは？
問7. 同一キーの同時ミスを1本化してオリジンを守る仕組みを、英語（2語）で答えてください。
問8. 言語や圧縮方式ごとにキャッシュを分け、個人向け応答の取り違えも防ぐために使うHTTPヘッダを英字で答えてください。