第58話で、イトはgeographically nearestなedgeへrequestを固定しなかった。
health / capacity / content routeを通ったdelivery nodeを選び、selection timeとresponse identityを残した。
次のrequestは、selected East edgeでcache MISSになった。
targetはhttps://cdn.picoroute.test/releases/current.json。
origin routeには、primary application、secondary application、raw object storageの三holderがある。
primary applicationへ進んだrequestは、fixture status 503で戻った。
イトはprimary holderへ「本物」のsealを貼り、raw storageへのdirect railを開いた。
「primaryがoriginなら、止まったときはstorageの一番新しいfileを返せばいい」
raw storageにはstaged release R12がある。
しかしcurrent release ledgerはR11のまま。
イトのdirect responseはR12を返し、expected current identityとmismatchになった。
viewer manifest確定まで、あと六十秒。
一番新しいfileと、authoritative responseは同じとは限らない
イトはR12 direct responseをedge cacheへ保存しようとした。
ピコはfileへ触れず、target-resource holder、origin-role holder、release-ledger holderを別々に照らした。
イト
storageで一番新しいR12が、元データじゃないの？
ピコ
R12はstaged sourceだよ。current targetが今返すrepresentationはR11に決まっている
イト
originは、fileが置いてある一台のserverじゃない？
ピコ
target resourceへauthoritative responseを作るroleと、その材料を持つ場所を分けよう
この話のorigin group、application、object storage、release ledger、failover criteria、responseは、外のInternetから切り離した学習fixtureだ。
hostnameはreserved .test、release IDとstatusは説明用だ。
live origin変更、credential、bucket access、production failover、database query、write retryは扱わない。
見るのは、target resource、authoritative response、underlying source、failover policy、response identityの順序だ。
origin serverは、authoritative responseを作るprogram
RFC 9110 HTTP Semanticsはorigin serverを、given target resourceについてauthoritative responseをoriginateできるprogramと定義する。
「すべての元fileをlocal diskに置く一台のmachine」とは定義していない。
origin programはstatic fileを返すこともある。
application logicを実行することもある。
databaseやobject storageから材料を読むこともある。
load balancerの奥に複数instanceがいる構成もある。
camera、robot、news feed、video platform等もtarget resourceへauthoritative responseを作るorigin serverになり得る。
originはHTTP上のroleだ。
physical server count、building、storage locationとは分ける。
resourceとrepresentationを分ける
RFC 9110のResourcesでは、HTTP requestのtargetをresourceと呼ぶ。
resourceのnatureをfileだけに限定しない。
GET responseは、その時点で選ばれたrepresentationをcontentとして返す。
同じtarget resourceでも、time、content negotiation、authorization、application state等でrepresentationが変わり得る。
今回のresourceは/releases/current.json。
raw object release-r12.jsonとは別targetだ。
release ledgerがcurrentをR11と決めている間、origin applicationはR11 representationを組み立てる。
storage timestampがnewerでも、R12はまだcurrent resourceのrepresentationではない。
「最新file」と「このURIが今表すstate」を同一視しない。
source of truthは、system contractで決める
source of truthは、どのsystem / recordが特定stateをauthoritatively決めるかという設計上の責任だ。
server roomの奥にあるものが自動的にtruthになるわけではない。
このfixtureでは、release ledgerのactive pointerがcurrent releaseを決める。
object storageはR11とstaged R12のartifactを持つ。
application originはtarget URIとactive pointerを読み、schemaを組み立ててresponseを返す。
三つのroleは別だ。
authoritative HTTP responseを返すprogram。
release stateを決めるledger。
artifact bytesを保持するstorage。
障害調査では、どれを「origin」「database」「source」と呼ぶかを曖昧にしない。
originは、一種類ではない
CloudFront公式のorigin typesは、Amazon S3 bucket、MediaStore / MediaPackage、Application / Network Load Balancer、Lambda function URL、EC2等のcustom origin、API Gateway等を例に挙げる。
これはCloudFront固有の選択肢だが、originが一種類のrack serverではないことを示す。
path pattern等でdifferent originsへrequestを送る構成もある。
static assetはobject storage origin。
dynamic APIはapplication origin。
mediaは別origin。
一つのsite hostnameの奥に、複数のorigin routeがあり得る。
逆に一つのorigin endpointの奥に、load balancerと複数instanceがいる場合もある。
外から見えるorigin roleだけで、内部topologyを断定しない。
multiple originsとfailoverは、設定されたpolicy
high availabilityのため、CDN productがprimary / secondary origin groupを持つ場合がある。
CloudFront公式のorigin failoverでは、primaryがunavailable、timeout、またはconfigured status codeを返したとき、secondaryへrouteするorigin groupを設定できる。
何でも自動でfailoverするわけではない。
failover criteriaを設定する。
CloudFrontのこの機能例では、viewer request methodがGET、HEAD、OPTIONSの場合に限る。
POSTやPUTを同じようにsecondaryへ自動再送しない。
productごとにmethod、status、timeout、retry、health modelは違う。
利用中serviceのcurrent official documentationと、自分のconfigurationを確認する。
「secondaryがある」だけでtested recoveryになるわけでもない。
authoritativeは、無条件に正しいという合格印ではない
authoritative responseは、identified originのcontrol下でtarget resourceに対して選ばれたresponseだ。
application bug、wrong deployment、stale database、misconfiguration、compromiseがないことを一語で保証しない。
authorityの確立、TLS、authentication / authorization、data correctness、business approvalは別に確認する。
response status 200だけでも足りない。
target URI。
schema。
release identity。
content type。
cache policy。
必要なsecurity fields。
expected response contractと比較する。
今回のR12 direct responseはbytesを取得できたが、current resource contractには不適合だ。
イトの前に、三つの選択肢が開く
viewer manifest確定まで、あと三十秒。
A primary originだけを、本物としてretryし続ける
roleを一台のserverへ固定する。
configured secondaryを使わず、deadlineまで同じ503を繰り返す。
B origin applicationを飛ばし、raw storageのnewest fileを返す
R12 bytesは取れる。
しかしrelease ledger、target schema、authorization、response policyをbypassする。
C target routeを保ち、configured origin groupのfailover条件を照合する
viewer requestがsafe retrievalのGETであることを確認する。
primaryの503がfixture failover criteriaに含まれること、secondaryがsame target contractをserveすること、returned release identityがR11であることを順に確かめる。
ピコはdirect storage railもorigin switchも操作しなかった。
「一番奥のfileじゃなく、current targetをauthoritatively返すrouteを保つ」
イトはCを選んだ。
自分でraw storageへのdirect railを閉じ、R12 responseをcache inputから外した。
GET method card、primary 503 criteria、secondary route、expected R11 identityをorigin-group holderへ戻した。
secondary originが、current R11を返した
イトはviewer GET requestを一枚だけedgeから送った。
primary application attemptは503。
fixture criteriaはfailover eligible。
origin groupはsecondary applicationへ同じtarget requestをrouteした。
secondaryはrelease ledgerのactive pointerを読み、object storageのR11 artifactからcurrent representationを組み立てた。
response statusは200。
schema、content type、release identity R11、cache policyはexpected contractと一致した。
edge acceptedは1。
raw storage direct exposureは0。
write-method failoverは0。
primary回復後も、machine名をtruthにしなかった
fixture clockを一分進め、primary applicationをhealthyへ戻した。
new comparison GETはprimaryへ進んだ。
primaryもrelease ledgerを読み、R11 current representationを返した。
secondary responseとのcontent identityは一致した。
R12 artifactはstorageに残るが、active pointerはまだR11。
イトはprimary responseを「本物」、secondary responseを「代用品」とlabelしなかった。
どちらもconfigured origin roleでsame targetへauthoritative responseを生成した。
ただしfailover pathを通った事実はoperation recordへ残す。
あとでroot cause、recovery、consistencyを確認できるようにする。
originを守るときも、routeを理解する
CDNの奥にoriginを置いても、originが自動で非公開になるとは限らない。
direct accessを許すか、CDNからのauthenticated requestだけを許すか、network pathをどう制限するかはconfiguration次第だ。
origin addressを隠すだけをsecurityにしない。
TLS、access control、secret management、patching、rate limiting、logging、backup、recoveryを別に設計する。
storageをpublicにしてapplication bypassを正当化しない。
origin failover時も、secondaryがsame security / data contractを満たすか確認する。
live endpointへ無断でdirect requestを試さず、authorized observabilityとclosed testを使う。
本館ではなく、authority chainを残す
workbenchには、八つの証拠が残った。
target /releases/current.json。
current release ledger R11。
staged storage artifact R12。
primary 503とconfigured failover criteria。
secondary authoritative R11 response。
raw storage direct exposure 0。
write-method failover 0。
primary recovery後のsame R11 identity。
origin serverを「元データを全部持つ一台の本館」と判断しない。まずtarget resourceへauthoritative responseを返すorigin routeと、underlying storage / application、source-of-truth contractを分ける。primary failureではstorageへ直結せず、request methodとconfigured failover criteriaを確認し、secondary responseのschema・version・authorityを照合する。serverの最新timestampが公開中の正解とは限らない。
「元がある場所を一つ選ぶんじゃない。どのcontractがcurrentを決め、どのorigin roleが返したかをつなぐんだ」
イトはR12 direct responseをcurrent shelfへ戻さず、R11 ledger、origin-group route、two authoritative response identitiesを一列へ残した。
primary application、secondary application、object storageの電源lineが、二つのfacility boardへ分かれた。
server rackだけでなく、power、cooling、network、fire protection、physical accessのlampが並ぶ。
data centerは、serverを置く大きな部屋というだけなのだろうか。
次回：data centerは、rackの部屋？
イトはserver rackのlampだけをavailability boardへ残そうとした。
「serverが動いていれば、data centerは大丈夫だよね」
ピコはrackへ触れず、power path、cooling loop、network path、facility zoneを照らした。
次回、ピコルート第60話。
イトは、data centerをserverが並ぶ部屋だけだと決めなかった｜何を止めない？