← AWSサービスの内部原理 コース
105. キャッシュはどの層にも置ける — ブラウザからDB前段までの地図と、新しさという対価
1つのリクエストがあなたの指からDBに届くまでの全経路を1枚の地図にして、本編で学んだキャッシュを各層に置いていきます。そして「速さの対価に何を払っているのか」を、上から下へ図で追っていきます。
① 1本のリクエストが通る5つの層
ユーザーの指
キャッシュに無い/期限切れ → 発信
①ブラウザ端末のディスク/メモリ
Cache-Control max-age が支配。ユーザーに最も近いキャッシュミス → オリジンへ
②CDN (CloudFront)POP → REC →(Origin Shield)→ Origin
s-maxage/キャッシュポリシーが支配。世界中に分散、多数のユーザーで共有cache.get() が null
③ElastiCacheアプリ層キャッシュ
遅延読み込み/ライトスルーをアプリが実装。key-value、データ構造も持てるアイテムキャッシュがミス
④DAXDB専用の前段キャッシュ
DynamoDB APIに透過なライトスルー。アプリはDynamoDBを呼ぶつもりのまま⑤DB自身の中DynamoDB / S3 Bucket Keys
B木のノードをメモリに載せるバッファ。キャッシュはDBの外だけの話ではない- ElastiCacheは「アプリケーションとデータストアの間に座るインメモリkey-valueストア」(ElastiCache Strategies)。
- CloudFrontはDNSがリクエストを最もよく処理できるPOP(通常はレイテンシ最小のエッジロケーション)にルーティングし、POPがミスなら通常は最寄りのREC(リージョナルエッジキャッシュ)へ取りに行く(HowCloudFrontWorks)。PUT/POST等のプロキシメソッドや動的リクエストはRECを通らず直接オリジンへ行く——だから「通常は」。
- Origin Shieldは有効化するとRECとオリジンの間に入るオプションの追加キャッシュ層。全RECからのオリジン向けリクエストがそこを通るようになり、オリジンへの重複リクエストを絞る(Origin Shield)。
- ⑤はDynamoDB編で見たB木のノード・バッファ、S3 Bucket Keysの鍵キャッシュの呼び戻し。
キャッシュは特定の1か所に置く道具ではなく、リクエストが通るどの層にも置ける。同じ道の上に5つのキャッシュが縦に並んでいる、というのが今回の地図の全体像。
② 近いほど速いが、無効化が届かない
①ブラウザ最速。だが運営者からは消せない
だから「バージョン付きファイル名」だった——app.v2.js を新しいURLにして別物にする②CDNInvalidationで消せる
無効化リクエストは期限前でもPOPとRECの両方から除去③アプリ層自分の管理下
TTLやライトスルーで能動的に整合を取れる④DB前段自分の管理下
同じく能動的に整合を取れる⑤DB本体真実の源(source of truth)。常に最新
- CloudFrontは「キャッシュ無効化リクエストは、期限切れ前にPOPキャッシュとリージョナルエッジキャッシュの両方からオブジェクトを除去する」(HowCloudFrontWorks 注記)。
- ブラウザキャッシュにはサーバから届く無効化命令が無い——だから中身が変わったらURL自体を変える(バージョン付きファイル名)しかない。
ユーザーに近づけるほど速くなるが、その分「やっぱり古かった、消して」という指示が届きにくくなる。ブラウザは消せないから名前を変える。この非対称が、キャッシュ設計で「どの層に置くか」を決める第一の軸。
③ どの層も同じ3つの問いに答える
問1 キー何をもって「同じ」とするか
問2 期限いつまで信じるか
問3 追い出し満杯なら何を忘れるか
URL①ブラウザ
max-age
ブラウザのLRU等
キャッシュキー②CDN
s-maxage/TTL/再検証
不人気なら追い出し
key③ElastiCache
TTL(秒)
LRU/LFU
プライマリキー④DAX
item TTL既定5分
LRU常時有効
PK+ハッシュ⑤DynamoDB
(常に最新)
ページ置換バッファ
- 問1の④はDynamoDB編で見た「パーティションキーをハッシュして置き場所を決める」のと同じ原理——DAXのアイテムキャッシュは「アイテムをプライマリキー値で格納」する(DAX: How it works)。
- 問2のCloudFrontは「Cache-Control max-ageやs-maxageやCloudFront側TTLで決まる」(Expiration)。DAXのitem TTLは既定5分で、LRUは常時有効(DAX: How it works)。
- 問3のDAXは「新しいアイテムのために古いデータをアイテムキャッシュから追い出す(LRUアルゴリズム)」、負のキャッシュ含め「TTL失効・LRU発動・更新のいずれか」で消える(DAX.consistency)。
- ③ElastiCacheのエビクションはmaxmemory-policyで選ぶ——既定はvolatile-lruで、allkeys-lru/allkeys-lfuなどLFU系も選べる(エビクション本編の復習)。
キャッシュキー/TTL/エビクションという3つの問いは、層が変わっても消えない。「これはブラウザの話、あれはDBの話」ではなく、同じ設計問題を層ごとに解き直しているだけ——これがコースの軸「マネージドサービスの中身は基礎でできている」のキャッシュ版。
④ 対価は「新しさ」— 定義上古い
遅延読み込みElastiCache
黙って古くなるキャッシュにしか書かない→DBが変わっても気づかない。TTLで「古すぎ」を防ぐだけ
ライトスルーElastiCache / DAX
他人の直接更新に弱い自分で書けば常に最新。だが他人がDBを直接書き換えるとTTL失効までズレる(DAX: AliceとBobの食い違い)
stale-while-revalidateCloudFront
古さを秒数で売買期限切れでも古いものを即返し、裏で取り直す。max-age=3600, stale-while-revalidate=600
- ElastiCacheは遅延読み込みの欠点として「データがstale(古い)になりうる」と明記(Strategies)。
- DAXはライトスルーでも「他アプリがDynamoDBを直接更新すると、DAXのアイテムキャッシュはDynamoDBと食い違う」——正確には、TTL失効・LRUによるエビクション・DAX経由での次の書き込みのいずれかが起きるまで食い違ったまま(DAX.consistency)。
- CloudFrontのstale-while-revalidate=600は「再検証中、最大10分は古いコンテンツを配信する」(Expiration)。
- キャッシュされたデータは定義上、書かれた瞬間の値であり、原理的にどこかで古い。
「速い」の対価は常に「古いかもしれない」。遅延読み込みは黙って古く、ライトスルーは他人の直接書き込みに弱く、stale-while-revalidateは古さを秒数で明示的に買う。手法は違えど、払っているのは同じ一貫性という通貨。
⑤ 新しさが要る読みだけ迂回する
読みリクエスト
キャッシュに寄る速い / 結果整合
DAX: 通常のGetItemはアイテムキャッシュからキャッシュを迂回遅い / 強い整合
DAX: ConsistentRead=true → DynamoDBへ素通しし、結果をキャッシュしない- DAXは「強い整合性の読みリクエストをDynamoDBへ渡し、返ってきた結果をクライアントに返すがキャッシュはしない。DAX自身は強い整合性の読みを提供できない(DynamoDBと密結合していないため)」(DAX.consistency)。
- CloudFrontでも同じ形——no-cache/no-storeや短いmax-ageで、鮮度が要る応答をキャッシュから外せる(Expiration)。ただしこれらのヘッダーが尊重されるのは最小TTL=0のとき。最小TTL>0だとその時間はキャッシュされる。
- 新しさが必要な読みだけがキャッシュを迂回する——これが層をまたいだ共通の答え。
キャッシュは「全部を速くする」道具ではなく「速くしていい読みを速くする」道具。強い整合性が要る読みだけを素通しにする設計は、DynamoDB編の整合性選択がそのまま各キャッシュ層に現れたもの。
⑥ 地図の裏は教科書の基礎だった
ハッシュスロットElastiCache
ハッシュで置き場所DynamoDBのパーティションと同じ(キーをハッシュ→置き場所)
エビクション(LRU)各層のキャッシュ
OSのページ置換
CDNの階層ブラウザ→POP→REC
CPUキャッシュ階層L1→L2→L3
無効化の難しさCDN/ブラウザ
分散合意の難しさ分散システム
TTL / max-age
いつまで信じるか時間の設計
- メモリ階層・局所性・ハッシュ・LRU・TTL——本編の各レッスンで別々に触れたこれらは、どれもOS/データ構造/分散システムの教科書の基礎。
- 「どの層に置くか」で速さ・共有範囲・無効化の届きやすさが変わるという視点は、可観測性編の「どの解像度でメトリクスを持つか」・メッセージング編の「どこでバッファするか」と同じ「配置の設計」の問い。
マネージドキャッシュは魔法ではない。メモリ階層・局所性・ハッシュ・LRU・TTLという基礎の組み合わせに、AWSが運用と規模を足したもの。仕組みから見れば、5層の地図はまるごと教科書の応用問題だった——これがキャッシュ編の、そしてコース横断テーマの回収。