第32話で、イトは「ネットが遅い」をserverのせいにしなかった。
同じlaptop、同じpreview、同じ映像のまま、Wi-Fiとwiredだけを変えた。
本番用のcueは、壁際を通したwired connectionで間に合った。
ところが、観客screenに最後の一枚が映った瞬間、ユイが息を止めた。
宇宙船の窓が、赤い。
最終版では、窓を青く直したはずだった。
イトは管理画面を開いた。
origin shelf: blue poster / upload complete
保存先の地図には、海の向こうの青いpinが立っている。
管理画面のorigin確認窓にも、青い窓のposterが出た。
イトは配信記録へ、大きく丸を付けた。
「serverの更新は終わってる。観客screenの読み込み直しが足りないんだ」
観客screenをreloadする。
赤い窓。
もう一度reloadする。
赤い窓。
本番まで、あと六分。
ユイ
私の確認窓は青。でも、観客と同じ公開URLは赤です
イト
同じURLなのに、別のserverが返してるの？
マコト
『serverはどこ』の、どのserverを聞いているかから分けよう
ピコ
地図のpinは一つの答え。でも、今回の返事そのものではないよ
イトは、公開URLのIP locationを調べた。
地図に、ラボと同じ国の琥珀色のpinが現れる。
「ここだ。この都市のserverが、古いposterを持ってる」
指は、配信をoriginへ直結するleverへ伸びた。
それなら琥珀色の拠点を外せるかもしれない。
だが、地図が示した都市は、本当にいま返した機械の住所なのか。
もし違えば、配信の道だけを大きく変え、古いposterは残る。
「serverはどこ？」には、別々の問いが入っている
マコトは、透明な地図を五枚に分けた。
| 知りたいこと | 分かるもの | それだけでは分からないもの |
|---|---|---|
| 誰がserviceを管理するか | 運営者、provider、契約 | 今回応答した機械 |
| 正本をどのregionへ置いたか | origin / storageのregion | viewerへ直接返したedge |
| 名前解決で何が返ったか | その時刻・resolverで得たaddress | addressの正確な建物 |
| 今回のrequestへ誰が返したか | serviceのedge / request診断 | その拠点のrackや部屋 |
| IPがどの地域に見えるか | 国・地域などの推定 | 実際の配信経路と物理住所 |
「server」という一語で、これらを一つにすると迷う。
今回、originの青いpinが答えるのは、正本を置いたregionだ。
観客screenへ、いま直接返事をした場所とは限らない。
originは正本の棚、edgeは今回の受付
CDNを使う配信では、viewerのrequestをedgeが先に受けることがある。
edgeに必要なobjectがあれば、そこからviewerへ返す。
なければ、別のcache層やoriginへ取りに行く。
originは、配信するcontentを保存し、edgeが取得する元になる。
edgeは、viewer-facingな受付になる。
同じ機械、同じ役割とは限らない。
AWS CloudFrontの公式Developer Guideでは、viewer requestがedge locationへ入り、objectがcacheになければregional edge cacheやoriginへ取りに行く流れを説明している。
CloudFront APIのOrigin定義でも、originはcontentが置かれ、CloudFrontがcontentを取得する場所として定義される。
これは一つのCDN製品の例だ。
serviceごとに名前、層、確認方法は違う。
しかし、正本の置き場所と、今回viewerへ返した受付を分ける見方は共通して使える。
イトが青く直したposterは、originには届いていた。
観客screenが見たのは、別の受付が持つ赤いposterだった。
ここで必要なのは、originの国をもう一度見ることではない。
観客と同じrequestが、どの配信層から何を受け取ったかだ。
一つのaddressが、一つの建物とは限らない
イトは、IP locationの琥珀色のpinを拡大した。
都市名の下に、一つのaddressがある。
「addressが一つなら、serverも一台じゃないの？」
ピコは、一つの呼び鈴から三つの受付へ線を伸ばした。
anycastでは、同じservice addressを、離れた複数のnodeから使える。
routing systemは、requestが入った場所やnetwork topologyなどに応じ、一つのnodeへ届ける。
地理的に最も近い建物が、必ず選ばれるという意味ではない。
RFC 4786は、one service addressを複数の離れたnodeで利用でき、routing topologyとrequest originによって利用されるnodeが変わりうることを説明している。
同じURL、同じaddressに見えても、別の利用者や別の時刻が同じnodeへ届くとは限らない。
DNS serviceそのものも、一か所とは限らない。
RFC 3258は、一つのnamed authoritative serverを複数locationへ分散させる構成を扱っている。
DNSで得たaddressは大切な観測だ。
ただし、それだけを正確な建物名へ変換しない。
記録するなら、addressだけでなく、調べた時刻、使ったresolver、調べたhostnameも一緒に残す。
IPの都市pinは、住所札ではない
琥珀色のpinは、目を引く。
だが、IP locationの表示には、登録情報、providerが公開するlocation情報、推定databaseなどが使われる。
表示される粒度も、更新時刻も、正確さも同じではない。
RFC 8805のgeofeed仕様では、location fieldを空にでき、利用側が公開情報をhintとして扱えること、情報が不正確な場合もあることを境界にしている。
だから、IPの都市名から次を断定しない。
- その都市の特定buildingに機械がある
- その機械が今回のHTTP responseを返した
- network上で最短の拠点である
- originもedgeも同じ場所にある
国や広いregionを推定する手がかりにはなりうる。
正確なrackを示す荷札ではない。
イトは、琥珀色のpinに書いた故障を消した。
六分を、どの地図へ使うか
本番まで、あと四分。
観客screenには、まだ赤い窓が映っている。
三枚の操作cardが立ち上がった。
- 全viewerをoriginへ直結する
- 琥珀色のedgeを通らない可能性はある。ただし配信設計を大きく変え、originの負荷や距離の影響も変える。古いposterの原因確認にもならない。
- IP地図の都市pinを、応答serverの場所として扱う
- 地図は速く読める。しかし、推定都市と今回のrequestを結ぶservice側の証拠がない。
- 観客と同じ公開URLの診断を見て、公式の配信controlを使う
- 正確な建物名は出ないかもしれない。代わりに、守るrequestが見たedge marker、cache state、object versionを確認できる。
一枚目なら、道を丸ごと変えられる。
二枚目なら、場所を言い切れる。
どちらも、六分前なら安心して見えた。
だが、安心できる答えと、今回のresponseを示す答えは違う。
イトは、origin直結leverのcoverを閉じた。
琥珀色のpinも伏せる。
三枚目を選んだ。
「建物を当てない。観客と同じrequestが、何を返されたかを見る」
同じ公開URLを、二つのviewerから確かめる
このラボの配信serviceには、管理権限のある人だけが開けるrequest診断がある。
実serviceで使える診断名やheader名は異なる。
表示がないserviceもある。
イトは、観客screenの公開URLと時刻を診断へ入れた。
- request: public poster URL
- viewer: lab audience screen
- delivery marker: amber edge
- cache state: stored copy
- object version: red
- origin version: blue
次に、海の向こうのstage monitorで、同じ公開URLを同じ時刻帯に開く。
- request: same public poster URL
- viewer: remote stage monitor
- delivery marker: violet edge
- cache state: fetched copy
- object version: blue
- origin version: blue
二つの結果は違った。
同じserviceでも、二つのviewerは別のdelivery markerを見ている。
ラボ側だけ、保存済みの赤いversionを返している。
この結果から、琥珀色のedgeの正確な都市やbuildingは分からない。
しかし、今回の行動を選ぶには十分だった。
originへのuploadを繰り返す必要はない。
全viewerをoriginへ直結する必要もない。
対象は、公開poster pathの配信状態だ。
イトは、地図ではなく公式controlへ手を置いた
clockは、残り二分。
イトは、配信serviceの公式control panelを開いた。
権限scopeを確かめる。
対象pathを、poster一枚へ絞る。
全cache、全site、全設定をまとめて初期化しない。
このラボfixtureで用意されたrefresh delivery copyを選ぶ。
「青いpinへ送り直すんじゃない。公開posterの受付に、正本を取り直させる」
イト自身が実行buttonを押した。
最初の観客requestが、琥珀色のedgeへ届く。
stored copyは使われない。
edgeがoriginから青いversionを取得する。
観客screenが、一度だけ暗くなる。
宇宙船の窓が、青く点いた。
次のrequestも、青い窓を返した。
remote stage monitorも青いまま。
本番clockが、最後の輪を閉じる。
ユイ
originの青いpinは間違いではなかった。でも、観客へ返した場所の答えでもなかったんですね
マコト
violet edgeもあった。『このserviceのserverは琥珀の都市にある』とも言えないね
イト
うん。分かったのは建物じゃなく、あのrequestが赤いcopyを受け取った配信層だ
ピコ
その粒度なら、観測と行動がつながっているよ
場所を調べる順番は、答えたい問いで変える
利用者がserverの場所を考えるとき、正確な物理住所まで必要になることは少ない。
目的ごとに、見る証拠を変える。
dataの保管regionを知りたい
service / cloud providerの公式管理画面、契約、構成資料を見る。
compliance、data residency、backup範囲を判断するなら、IP検索より管理上のregionが重要になる。
今回のrequestへ応答した配信層を知りたい
serviceが公式に提供するrequest ID、edge marker、trace、response diagnostic、support logを使う。
利用できる項目はserviceごとに違う。
無許可のscanや管理外networkの変更は行わない。
名前解決の結果を比べたい
hostname、時刻、resolver、返ったaddressを一組で残す。
address単独を、正確なserver住所へ変換しない。
おおまかな国・regionの手がかりがほしい
IP locationはhintとして使う。
providerの公式region情報やservice診断と食い違うなら、都市pinを優先して断定しない。
「近いserver」を地図の距離だけで選ばない
地図で近く見える場所が、networkでも短いとは限らない。
route、peering、混雑、service policy、障害時の切替などで、実際のpathは変わる。
CDNやanycastが選ぶnodeも、地理的な直線距離だけで決まるとは限らない。
速度や反応を確かめたいなら、都市名の比較より、守りたいapplication requestのRTT、失敗、object version、時刻、viewer条件を記録する。
第31話のpingも、第32話のA / B comparisonも、ここでつながる。
場所の名前は、測定値を補うcontextだ。
測定値の代わりではない。
読者が次にできる一手
「このserverはどこ？」と思ったら、最初にoriginのregion、DNSで得たaddress、今回応答したedge、IP locationの推定のどれを知りたいかを一行で決める。配信の不一致を調べるなら、都市pinを正確な住所として扱わず、守りたい公開URL、時刻、viewer、serviceが提供するrequest / edge / cache診断を残す。管理権限がある場合も公式controlで対象を絞り、権限がない場合はrequest IDと再現条件を運営者へ渡す。
次の扉
観客screenは、青い窓のposterを映している。
origin regionは、海の向こう。
violet edgeも、別の海岸側で光っている。
琥珀色のedgeが入っていた正確なbuildingは、最後まで分からなかった。
イトは、地図へ無理に住所を書き足さない。
代わりに、青いoriginと二つのedgeを結ぶrouteを見た。
線は港へ伸び、そこで海の下へ沈んでいる。
「海外のoriginやedgeへ行くpacketは、海をどうやって越えるの？」
ピコが、港に巻かれた太い光のcableを指した。
次は、海底cableがどこを通り、遠いserverへの道をどう支えるかを見る。