二度目のrequestが、遠い本館行きのrailへ入ろうとした。
イトが、gateを閉じた。
posterの正本は本館にある。
それでも彼は、取りに行かせなかった。
preview開始まで、あと五秒。
第13話で最後まで遅れていた上映posterを、二台の端末がほぼ同時に求めている。
GET /media/finale-poster一人目のrequestは、すでに近くの配信拠点へ届いていた。
しかし、青い棚は空だった。
受付の灯りが、赤へ変わる。
CACHE MISS。
ここには、まだ返せるposterがない。
イト
近い棚が空なら、結局は本館へ行くしかない
ピコ
一人目はね。でも、そのresponseを通り過ぎさせるだけでいい？
ユイ
二人目が、もう入口まで来ています
origin railの奥で、poster cardが動き始めた。
残り四秒。
一人目は、遠いoriginを消せない
CDNは、世界中のどのrequestも最初から魔法のcopyで満たせるわけではない。
このfictional CDNでは、viewerのrequestを、そのrequestへ応答しやすいedgeへ送る。
物理的にいちばん近い建物だと断定する話ではない。networkのlatencyや経路、serviceの設定によって、応答を担当する拠点が選ばれる。
edgeにrequestと合うresponseがなければ、cache missだ。
そのときはoriginへrequestを送り、材料を取得する必要がある。
Amazon CloudFrontの公式配信手順でも、requestを応答に適したedge locationへ送り、objectがcacheになければoriginから取得し、viewerへ転送すると同時に次回のためcacheへ加える流れが説明されている。
CDN productや構成は一つではない。
ここで使うのは、その流れを持つ一つのfictional構成だ。
遠いoriginから、一人目のposter responseが戻ってくる。
イトの前に、二つの出口が開いた。
一つは、一人目のbrowserへ続くlane。
もう一つは、edgeの青い棚へ続く短いlane。
posterをviewerへ渡すだけなら、一人目の画面は完成する。
だが、棚は空のままだ。
イトはresponseを二つに裂いたのではない。
同じresponseをviewerへ流しながら、次のrequestに再利用できるcopyとしてedgeへ保存した。
一人目の画面に、posterがはまる。
青い棚にも、同じtargetへ結び付くposter cardが残った。
残り三秒。
二人目のrequestが来た
二人目のrequest tokenが、分岐へ入った。
targetは一人目と同じだ。
GET /media/finale-posterorigin行きの長いrailは、まだ一人目のtransferの光を引きずっている。
ピコが、三枚のroute cardを開いた。
- 正本があるoriginへ、もう一度送る
- edgeにある別の派手なimageを、すぐ返す
- requestを照合し、再利用できる同じposterをedgeから返す
一枚目なら、正本を取りに行ける。
けれど、一人目と同じ長い往復がもう一度増える。
二枚目なら速い。
しかし、頼まれたtargetとは違う。速く届いても、別の上映posterでは失敗だ。
三枚目を選ぶには、ただ「似た絵が棚にある」だけでは足りない。
requestを、保存したresponseのcache keyと照合する必要がある。
同じURLに見えても、同じcopyとは限らない
cache keyは、どのrequestがどのstored responseを再利用できるかを見分ける鍵だ。
このfictional CDNでは、今回のposterについてrequest targetを中心にkeyを組み立てている。
実際の構成ではquery、header、cookieなど、ほかのrequest要素をkeyへ含める場合がある。
CloudFrontのcache key公式説明でも、requestが同じcache keyになり、有効なobjectがedge cacheにあればcache hitになる。missならoriginへ取りに行き、取得したobjectをedgeへ保存する。
イトは二人目のtokenと、青い棚のposter cardを重ねた。
targetが合う。
このrequestへ再利用できる。
まだfreshとして扱える。
RFC 9111 HTTP Cachingでは、cacheはresponse messageのlocal storeと、その保存・取得・削除を制御する仕組みとして定義される。freshなstored responseは、originでのvalidationなしに再利用でき、latencyとnetwork overheadを減らせる。
ピコ
近いから、何でも返していいわけじゃないよ
マコト
同じrequestに使えるcopyかを確かめて、初めて近道になる
イト
二人目は、同じposterをもう一度本館へ取りに行かなくていい
残り二秒。
イトは、一枚目のorigin cardを伏せた。
二枚目の別image cardも戻す。
三枚目を、二人目のrequestへ重ねた。
長いorange railのgateを閉じる。
近いedge shelfからbrowserへ続く、短いcyan laneを開く。
CACHE HIT。
poster cardが、二人目の空frameへ滑り込んだ。
速くしたのは、距離だけではない
残り一秒。
二台の画面に、同じposterが表示された。
一人目は、edge missからoriginへ取りに行った。
二人目は、edge hitで近いcopyを受け取った。
一人目: browser → edge MISS → origin → edge → browser
二人目: browser → edge HIT → browser二人目の経路から、origin往復が一つ消えている。
同じrequestが何度も来る場面では、edgeのstored responseが使えるほど、originへ届くrequestも減らせる。
originの負荷を分け、viewerが待つ時間を短くできる場合がある。
ただし、CDNという名前だけで必ず速くなるわけではない。
cache missならoriginへ行く。
cacheしないresponseもある。
keyが細かく分かれれば、見た目が同じrequestでも別物として扱われる。
networkの状態や設定によって、edgeを経由するcostが勝つ場合もある。
今回、二人目を速くしたのは、一人目が持ち帰ったresponseを、同じrequestに使えるcopyとしてedgeへ残していたからだ。
ユイ
近い拠点、再利用できるcopy、originへ戻らないhit。三つがつながって速さになりました
イト
一人目の待ち時間を、二人目の近道に変えたんだ
preview開始の光が点いた。
二人目を速くしたのは、CDNという名前ではない。
一人目のresponseをedgeへ残し、origin往復を一つ消したことだ。
棚のposterだけ、昨日のまま
そのとき、本館のorigin shelfでposterが差し替わった。
上映開始時刻が変わった新版だ。
originのcardは、新しい青い縁へ変わる。
だが、イトの近くにあるedge shelfのcardは、古い橙の縁のままだった。
三人目のrequest lightが近づいてくる。
targetは同じ。
cache keyも合う。
edgeの時計は、まだそのcopyをfreshとして示していた。
速く返す条件は揃っている。
新しく返す条件は、揃っているのだろうか。
イトの手が、cyan laneのswitchの上で止まった。
「originが変わったのに、ここはどうやって気づくんだ？」
次回：速いcopyは、いつ古くなる？
一人目のcache missでoriginからposterを取得し、edgeへcopyを残した。
二人目のcache hitでは、そのcopyを使ってorigin往復を省いた。
次に迫るのは、速さと新しさの衝突だ。
freshness、validation、browser cache、CDN cacheはどうつながるのか。
次回、ピコルート第15話。
昨日のposterを、いつ疑う？
画面のむこう側をもっと知る
CDN、edge、origin、cache hit/missの流れを図で整理するなら、CDNとはで確かめられます。