remote screenの進捗slotが、五つとも青く満ちた。
第30話でイトは、100 Mbpsのplateを完成時刻に読み替えるのをやめた。
remote applicationが新しく受理したpayloadを測り、final cutを早く送り始めた。
だから今度は、最後の表情まで本番用のscreenへ届いている。
あとは開始のcueを送るだけだった。
ユイが、remote screenへ小さな確認packetを三つ送った。
一つ目。
返事なし。
二つ目。
返事なし。
三つ目。
往復clockは止まらないまま、timeoutの線を越えた。
端末には、replyなしの印が三つ並ぶ。
イトは、本番routeの札を外した。
「このscreenは壊れてる。返事をする予備へ切り替えよう」
予備screenへ同じ確認を送ると、clockはすぐ止まった。
三回ともreplyが返り、往復時間も短い。
イトは迷わず、cueの宛先を予備へ差し替えた。
ユイ
待って。final cutを送ったのは、最初のscreenだけです
イト
でも、そっちはpingへ返さない。予備は三回とも返ったよ
マコト
返った合図は、本番用の映像もあると答えたのかな
イト
道が通るなら、screenも使えるはずだよ
wall clockが、本番の位置へ来た。
イトはcueを送る。
予備screenのlampは青く点いた。
しかし、画面に出た登場人物は、昨日の古い表情だった。
進捗slotも四つしかない。
五つ目のfinal cutは、予備へ届いていなかった。
pingは成功した。
本番は失敗した。
返事をした相手は、何に返事をしたのか
そのとき、最初のremote screenからapplication receiptが届いた。
final cut accepted: 5 / 5
本番前に送った映像を、五つすべて受理したという記録だった。
ユイが、最初のscreenへもう一度pingを送る。
replyは返らない。
二つの結果が、点検boardへ並んだ。
| target | pingのreply | remote applicationの状態 |
|---|---|---|
| 最初のscreen | 返らない | final cutを5 / 5受理済み |
| 予備screen | すぐ返る | 古いcutのまま4 / 5 |
イトは、予備screenの速い数字を見た。
数字は間違っていない。
ただし、イトが知りたかった質問への答えではなかった。
「僕は、何の返事を見てたんだろう」
pingは、ICMP Echoの往復を観測する
pingという名前は、よくnetworkの確認に使うutilityを指す。
一般的なpingは、IPの制御用messageであるICMPのEcho Requestをtargetへ送り、対応するEcho Replyが戻るかを観測する。
IPv4のEcho RequestとEcho Replyは、RFC 792で定義されている。
Requestはtype 8、Replyはtype 0。
identifierやsequence number、dataを使い、送ったEchoと戻ったEchoを対応づける。
RFC 1122では、IPv4 hostがEcho Requestを受けてEcho Replyを返す機能を実装することと、診断用interfaceを備えることが要件として整理されている。
IPv6でも、RFC 4443がEcho RequestとEcho Replyを定義している。
ピコが、透明な往復railを一本だけ点灯させた。
- 端末がEcho Requestを送る
- targetがそのRequestを受け取る
- targetがEcho Replyを返す
- 端末が対応するReplyを観測する
送信から受信までの経過時間を測れば、そのsampleのround-trip time、RTTになる。
複数回送れば、戻ったsample数、戻らなかったsample数、RTTのばらつきも見える。
ただし、送信回数、interval、packet size、timeout、表示する統計はpingの実装やoptionで変わる。
このラボで三回、次の検証で四回送るのは、物語内の測定条件であって、すべてのpingに固定された回数ではない。
イト
replyが返ったら、そのtargetは僕のEchoへ返事をした
マコト
そう。でも、映像を五つ受理したとも、cueを正しく処理するとも答えていない
ユイ
呼び鈴へ返事をしたことと、舞台の準備が終わったことは別なんですね
ピコ
観測したmessageの種類を、そのまま答えの範囲にするよ
replyがあっても、applicationの成功までは証明しない
最初の判断でイトは、ping replyを「screenが本番を実行できる」という許可証にした。
けれど、Echoを処理する場所と、映像を受理してcueを実行するapplicationは同じ仕事ではない。
replyから直接いえるのは、設定した条件のもとで、送ったEcho Requestに対応するEcho Replyを観測できたことだ。
その往復には、送信端末、network path、targetのICMP処理、戻り道、受信端末の観測が関わる。
一方、本番の成功には別の条件がある。
- 必要なapplication processが動いている
- 正しいportやprotocolでrequestを受けられる
- sessionやloginが有効である
- final cutが現在のversionとして受理されている
- cueとcutの対応が一致している
- deadlineまでに画面へ反映できる
ping replyが速くても、この一覧を自動では満たさない。
逆に、applicationのtransactionが成功しているのに、Echo Replyだけ観測できないこともある。
最初のscreenが、その状態だった。
replyがないとき、確定できるのは一行だけ
イトは、最初のscreenの行へ赤い札を置こうとした。
故障。
しかし、application receiptは5 / 5を示している。
赤い札を置くには、観測した事実より言葉が大きすぎた。
pingでreplyがないときには、複数の候補が残る。
- Echo Requestが途中で失われた
- targetへ届いたが、Echo Replyを作るresponderが応答しなかった
- 運用方針やfilteringでEchoが通らなかった
- targetがEcho処理を低い優先度で扱った
- Echo Replyが戻り道で失われた
- Replyは戻ったが、設定したtimeoutより遅かった
- hostまたはpathが実際に利用できなかった
この一覧は、今回の原因を示す答えではない。
一回のno replyだけでは区別できない候補だ。
RFC 2681は、pingのような測定をround-trip delayのsampleとして扱える一方、targetの応答、負荷、timeoutなどが結果の意味と不確かさに関わることを説明している。
対応するpacketを待ち時間内に観測できなければ、そのRTT sampleは値として決められない。
また、RFC 4890が扱うように、ICMP messageにはnetworkの運用やfilteringの方針も関わる。
だから今回のno replyから、「filterが原因だった」「hostが落ちていた」と一つへ決めることはできない。
確定できるのは、短い一行だけだ。
指定したtimeoutまでに、送ったEcho Requestへ対応するEcho Replyを観測できなかった。
それ以上は、別の観測で分ける。
pingのRTTは、application response timeではない
予備screenのpingには、短いRTTが表示されていた。
イトはその数字を、本番screenが反応する速さとして読んだ。
けれど、pingのclockが止まるのはEcho Replyを受けたときだ。
映像applicationがrequestを読み、権限を確認し、dataを探し、描画し、結果を返し終えるまでの時間ではない。
同じtargetでも、ICMP Echoとapplication requestではmessage、処理、待ち行列、応答条件が違う。
RTTは大切な手がかりだ。
だが、何の往復を測ったRTTかを外すと、別の仕事のdeadlineへ誤用してしまう。
イトは、予備screenの短いという札を外した。
代わりに、こう書く。
Echo ReplyのRTTは短かった。applicationの準備は未完了だった。
返事の速い予備か、replyのない本番用か
本番をやり直せるのは、あと一回。
clockの輪が三つだけ残った。
三枚の計画cardが立ち上がる。
- pingへ返す予備screenを使い続ける
- Echoは往復する。しかし、final cutは4 / 5のままで、本番の成功条件を満たさない。
- pingは役に立たないとして、結果をすべて捨てる
- applicationだけを見る。IP reachabilityやRTTの手がかりまで失う。
- 同じtargetへ、Echoと実際のapplication transactionを別々に試す
- 観測は二列になる。守りたい機能が本当に準備できたかを直接確かめられる。
ユイは、最初のscreenのping欄を指した。
「replyがないまま本番に使うのは、少し怖いです」
マコトは、その隣のapplication欄を指した。
「怖さを消すために、replyがある別のscreenへ逃げた。でも、守るべき映像はそこになかった」
ピコはcardに触れない。
wall clockの輪が、一つ減る。
イトは一枚目を持ち上げた。
replyが返るscreenなら、説明はしやすい。
だが、本番で古い表情を出した事実は変わらない。
二枚目なら、pingの失敗を見なかったことにできる。
それでは、Echoで見えていた別の手がかりまで消える。
イトは二枚を戻し、三枚目を選んだ。
「同じ相手へ、二つの質問をする。replyの有無で、質問を入れ替えない」
条件を固定し、二列で確かめる
イトは、cueの宛先を最初のremote screenへ戻した。
そのうえで、pingの測定cardに条件を書く。
- target: 本番用remote screen
- packet type / size: 今回使うEcho Requestとdata size
- count / interval: 四回、同じ間隔
- timeout: ラボで決めた待ち時間
- measured at: 本番前の時刻
一回目のEcho Requestを送る。
replyなし。
二回目。
replyなし。
三回目と四回目も、timeoutまで対応するReplyを観測できなかった。
イトは、結果をscreen故障と書かない。
Echo Reply 0 / 4 within fixture timeout
観測した範囲だけを残す。
次に、実際のremote applicationへpreflight requestを送った。
質問は、Echoより本番の成功条件に近い。
いま受理しているfinal cutは五つか。次のcue sequenceと一致しているか。
applicationからreceiptが返る。
五つのcut mark。
本番で送るcueと同じsequence。
古いcutを持つ予備screenでは、この一致を作れない。
ユイ
pingの欄は失敗のまま。でも、本番用applicationは五つのcutへ返事をした
イト
Echoを成功させることが目的じゃない。いま守るのは、正しいcutを正しいcueで出すことだ
マコト
そしてEchoの0 / 4も隠さない。別の点検で使える観測だからね
ピコ
二つの結果が食い違ったときこそ、同じ意味に丸めないよ
pingを直さなくても、判断は直せる
最後の本番が始まった。
イトは最初のremote screenへcueを送る。
application receiptが、同じsequenceを返した。
screenのlampが青く点く。
五つの進捗slotは、すべて満ちている。
新しい表情の登場人物が、deadlineの手前で振り向いた。
一方、上段のEcho railには、四つの空欄が残ったまま。
pingのreplyは戻っていない。
原因も、まだ一つには決まらない。
それでもイトは、replyの速い予備へ切り替えなかった。
守りたいapplicationのtransactionを確かめ、正しい本番用screenを残した。
イトは、最初に書いた故障の札を裏返した。
表へ、新しい一行を書く。
no replyは原因名ではなく、次の質問を選ぶ観測。
ただし、Echo Replyが戻らない理由は未解決だ。
本番後のmaintenanceでは、運用方針、targetのEcho responder、送信側、往路、復路、timeoutを分けて調べる必要がある。
連続で大量のpacketを送りつければよいわけでもない。
管理しているnetworkの手順と負荷を確認し、必要な範囲で測る。
本番に間に合ったことを、原因解明の代わりにはしない。
読者が次にできる一手
最初の一手は、「pingが返った／返らない」の横へtarget、packet type / size、count / interval、timeout、測定時刻を書くことだ。replyがあれば、そのtargetとのICMP Echo往復を観測できた。replyがなければ、timeoutまで対応replyを観測できなかった。どちらもapplicationの成功・失敗を自動では決めない。Web、game、通話、remote consoleなど、守りたい機能はその機能のrequest / responseでも確かめる。Echoとapplicationの結果が食い違う、または両方失敗するなら、原因名を急いで付けず、次の層別点検へ進む。
次の扉
remote screenの本番は終わった。
application receiptも、次のcueへのreplyも返っている。
今度はpingのEcho Replyも戻った。
それなのに、イトの手元にあるpreviewだけが、二秒おきに止まる。
「相手は返してる。applicationも動いてる。それなら、どこが遅いの？」
ピコが、端末、Wi-Fi、router、回線、server、applicationの札を載せた点検boardを開いた。
一つの数字に原因名を付けるのではなく、層を分けて比べるためのboardだ。
次は、ネットが遅いときに、どこから点検を始めるかを見る。