第57話で、イトはnear cacheのfresh HITを最新だと決めなかった。
versioned targetへ参照を切り替え、first MISSとsecond HITでviolet release assetを確認した。
次のviewer request cardの前に、二つのedge counterが開いた。
map上では、East counterがイトに近い。
West counterは、少し遠い。
イトはrulerで直線を引き、Eastへmanual pinを置いた。
「一番近いedgeなら、一番速く返るはず」
request cardはEast queueへ入った。
だがhealth lampはamber、active queueはlimitを超えている。
fixture responseはtimeoutになり、violet assetは0枚。
studio first-viewer checkまで、あと六十秒。
地図の最短距離は、routing結果そのものではない
イトはmanual pinをさらに強く押し込もうとした。
ピコはpinへ触れず、geographic rulerとnetwork-path clockを別holderへ照らした。
イト
Eastの方が地図では近いのに、どうして届かなかったの？
ピコ
地理の距離と、networkが選ぶpathやlatencyは同じ尺度じゃないよ
イト
CDNは、一番近い建物を探しているわけじゃない？
ピコ
requestをserveできるcandidateから、policyとmetricsでdelivery nodeを選ぶ仕組みを見よう
この話のDNS、anycast address、request router、edge counter、health、load、latencyは、外のInternetから切り離した学習fixtureだ。
hostnameとaddressはreserved test dataを使う。
live DNS変更、BGP announcement、production traffic steering、load test、DDoS回避手順は扱わない。
見るのは、candidate eligibility、selection policy、observed route、response identityの順序だ。
edge serverは、delivery nodeという役割
CDNのedge serverは、利用者側に近いnetwork locationでcontentを返すdelivery node / surrogateとして働く場合がある。
cache hitならstored responseを返せる。
missならregional tierやorigin側へ進む構成もある。
edge computeを実行するproductもある。
しかし「edge」は、利用者から何km以内という一つの世界共通規格名ではない。
どのnodeをedgeと呼び、何を処理し、どの階層へmissを送るかはarchitectureとserviceで違う。
そしてrequestがどのedgeへ着くかは、edge server自身の役割と、request-routing systemの選択を分けて考える。
near shelfに何があるかは第57話のcache条件。
本話では、そのshelfを見る前に、requestがどのcounterへ到達したかを追う。
request-routingは、serveできるnodeへrequestを向ける
RFC 3568 Known Content Network Request-Routing Mechanismsは、client requestをcontent network内のsurrogateへ向ける技術をRequest-Routing / Content Routing / Content Redirectionと呼ぶ。
一つの選択尺度だけを規定しているわけではない。
network proximity。
bandwidth availability。
surrogate load。
content availability。
requestをbest serveできるcandidateを選ぶため、複数のpolicy / metricsを使い得る。
「最短の緯度経度」を唯一のruleにしない。
healthが悪いnode、対象distributionをserveしないnode、capacityを超えたnodeは、地理的に近くてもcandidateから外れる場合がある。
DNS・transport・applicationで向け方が違う
RFC 3568はknown mechanismを大きく、DNS-based、transport-layer、application-layerへ分ける。
DNS-based request routingでは、specialized DNS serverがpolicy等に応じてdifferent address / nameを返せる。
transport-layerでは、network path上のmechanismがconnectionをdelivery nodeへ向ける構成がある。
application-layerでは、URL / header情報やHTTP redirect等を使う方法がある。
一つのCDNが必ず全部を使うわけではない。
同じvisible hostnameでも、名前解決時刻、resolver側から見える位置、network route、service policyによって別nodeへ着き得る。
DNS resultを永久なedge identity cardとして保存しない。
DNS TTLやconnection reuseも観察条件へ影響する。
このfixtureでは、request routerがEast / Westのcandidate boardを一回ごとに評価する。
anycastの「近い」は、routing topology上の近さ
anycastでは、同じdestination addressを複数nodeが共有し、routing systemが一つへpacketを届ける構成がある。
RFC 4786 Operation of Anycast Servicesは、anycast service addressへ送られたpacketが、routing systemによって一つのanycast nodeへ届けられると説明する。
ここでの選択は、地図の直線距離を測る処理ではない。
RFC 4786のservice distributionは、routing topology上のnearnessがround-trip performanceと一般には一致しないことも示す。
BGP / IGPのpolicy、path、failure、congestion等で結果は変わり得る。
anycast addressを見ただけで、どのphysical siteへ着いたかを断定しない。
node identifierやvendorのtrace / response header / log等、許可された観察手段で確認する。
実際のCDN policyは、productごとに違う
Amazon CloudFrontの公式delivery flowは、DNSがrequestをbest serveできるPOPへrouteし、通常はlatencyの面でnearestのPOPになると説明する。
これは「地理上の最寄りを必ず選ぶ」とは書いていない。
Cloudflare公式のgeographic traffic routingも、Anycast networkではgeographically closestとは限らず、performanceとreliabilityが競合すればstable connectionを優先すると説明する。
二つはproduct例で、全CDNのalgorithmを代表しない。
実運用では、利用中productのcurrent official documentationとcontractを確認する。
本話のEast / West selectionはPicoRoute fixture固有だ。
latencyは、距離の別名ではない
latencyはrequest / responseがnetwork pathを進む時間に関係する。
physical distanceは要因の一つになり得る。
しかしpath length、peering、routing policy、queue、packet loss、server processing、connection setup等も影響する。
clientから見たround-trip timeと、edgeからoriginまでの時間も別だ。
一回のpingだけでapplication response performanceを断定しない。
測るなら、同じtarget / time window / protocol / connection conditionを残す。
平均だけでなく失敗、tail latency、response identityも見る。
fixtureのnetwork clockは、地理rulerと別に値を出す。
イトの前に、三つの選択肢が開く
studio first-viewer checkまで、あと三十秒。
A 地図上で最短のEastへmanual pinを残す
選択理由は簡単だ。
しかしEastのhealth / queue変化を無視し、timeoutを繰り返す。
B healthを無視し、同じviewer requestを全edgeへ同時送信する
先に返るresponseを選べるかもしれない。
だがunapproved duplicate traffic、log重複、cost、stateful requestの危険を広げる。
C manual pinを外し、approved routing policyでeligible candidateを一つ選ぶ
target distribution / content route、health、capacityを先に確認する。
eligible candidate間ではfixture network latencyを比べ、selection time、candidate reason、selected edge、response identityをroute recordへ残す。
ピコはmanual pinもrequest cardも動かさなかった。
「地図の近さじゃなく、今serveできる条件へrequestを一回だけ送る」
イトはCを選んだ。
自分でEastのmanual pinを外し、approved policy cardをrouter holderへ戻した。
candidate boardのhealth / capacity / content-route lampsを更新し、new viewer requestを一枚だけinput railへ置いた。
unhealthy Eastを外し、healthy Westが選ばれた
selection timeはfixture clock 14:32:10。
Eastはtarget distribution eligible。
しかしhealth checkはfail、active queueはlimit超過。
candidate resultはineligible。
Westはtarget distribution eligible、health pass、capacity available。
fixture network latencyはWestの方が低い。
request routerはWestをselected edgeにした。
request emittedは1。
West cacheからviolet versioned assetがHITし、expected content identityと一致した。
response acceptedは1。
Eastが回復すると、次のrequestは別結果になった
fixture clockを一分進めた。
Eastのhealth checkはpassへ戻り、queueはlimit未満になった。
Westもhealthyのまま。
同じtargetへnew comparison requestを一枚送る。
このtime windowではEastのfixture network latencyが低い。
approved policyはEastをselected edgeにした。
East responseもviolet content identityと一致し、acceptedは1。
最初のWest選択が間違いだったわけではない。
候補のstateとmeasurement timeが変わり、次のselection resultが変わった。
イトはWest / Eastを永久なprimary / backup labelにしなかった。
route recordには、二回のselection timeとreasonを別行で残した。
selected edgeは、responseから観察する
「いつもこのedgeへ行くはず」という記憶だけでtroubleshootingしない。
同じhostnameでも、DNS cache、connection reuse、network route、availability、service policyの変化でselected nodeが変わり得る。
authorizedなvendor log、trace identifier、response header、request ID等があれば、公式定義に従って読む。
header名を見ただけでnodeのphysical locationやfull pathを推測しない。
request target、client / resolver condition、timestamp、selected edge identifier、cache result、status、content identity、latencyを同じrecordへ残す。
異なる端末や地域の結果を比べるときも、測定条件をそろえる。
live nodeへ無断probeを増やさず、providerのobservabilityとcontrolled testを優先する。
最短距離ではなく、selection reasonを残す
workbenchには、八つの証拠が残った。
geographically closerなEast。
East manual pinのtimeout。
East health fail / queue limit超過。
West health pass / capacity available。
first selectionのWest response accepted 1。
request emitted 1 / duplicate 0。
recovery後selectionのEast response accepted 1。
二つのselection time / reason record。
edge serverを「地図上で一番近い建物」と判断しない。まずtargetをserveできるcandidateか、healthとcapacityがあるかを確かめ、利用CDNのrouting policyとnetwork measurementにselectionを任せる。結果はtimestamp、selected edge、cache result、response identityで確認する。geographic distance、routing-topology上の近さ、application latencyは別の尺度だ。
「近いedgeを覚えるんじゃない。なぜ今そこが選ばれ、何が返ったかを残すんだ」
イトはEast pinをmapへ戻さず、two selection recordsとviolet response identityだけをviewer checkへ残した。
次のrequestはselected Eastでcache MISSになった。
その奥に、一つの本館ではなく、primary origin、failover origin、object storeの三つのsource holderが開く。
origin serverとは、一台の元データ倉庫なのだろうか。
次回：originは、一台の本館？
イトはprimary originのcardだけを「本物」と書かれたholderへ置こうとした。
「originって、全部の元を持つ一台のserverだよね」
ピコはcardを取らず、source-of-truth、origin role、failover policyの三holderを照らした。
次回、ピコルート第59話。
イトは、origin serverを一台の本館だと決めなかった｜元はどこにある？