T18 · リアルタイムシステム

現実の問題

T17 で信頼できる索引器ができました。長時間接続を追加し、ブロック処理ごとにイベントを送り出すと、ローカルでは数秒で届き、快適です。

公開 2 週間後、再現しにくい似た苦情が出ます。

• 「活動一覧に数件足りないが、更新すると現れる。」
• 「処理中のままだが、実際には成功済み。」
• 「画面の残高がエクスプローラーと違う。」

サーバーログは正常です。すべて送信しました。 送信関数は成功し、例外も滞留通知もありません。

共通点は、モバイル回線で短時間切断したことでした。

設計は送ったら忘れる方式でした。その瞬間接続中なら届き、不在なら永久に消えます。ネットワークでなく、設計で失っています。不在への準備が何もないからです。

問いは、30 秒切断して戻ったユーザーへ、その間の出来事をどこから補うかです。

思考実験

3 つの配送方法を考えます。

第一はラジオ放送です。 聞いている人には届き、不在なら番組は消え、何を逃したか誰も知りません。

サーバーが聴衆について何も記憶せず、低費用です。到達は運に依存します。

第二は、番号付き掲示板です。 連番を付けて壁へ残し、戻った人が「812 まで見た」と言えば、813 以降を読めます。

切断は復旧不能の事故から、補完できる追い付きへ変わります。ただし壁を保存し、有限の容量なので古いメッセージはいずれ消します。

第三は、変化したから見に行くよう知らせるだけです。 内容でなく信号を送り、受信者が最新状態を照会します。

一信号の喪失にはほぼ影響がないという利点があります。次の信号でまとめて更新し、冪等で喪失に強い方式です。ただし途中の出来事ではなく、現在の状態しか答えられません。

共通する基準は次です。

リアルタイム配信は、再生可能か、正しい状態へ収束可能にします。どちらもなければネットワークへの賭けです。

第一はどちらもなく、必ず失います。冒頭の苦情は、その三つの表れです。

あなたが決める

チェーンの変化で画面を更新する方法を選びます。

結果を観察する

異なる指標で比較します。

遅延と喪失は無関係です。本章の中心は、

リアルタイムは遅延の指標、失わないことは正確性の指標で、別の機構が保証します。

多くは前者だけ実装し、安定回線の開発ではよく見えます。問題はユーザー側で、まれに数件欠ける、調査困難な形で現れます。

前章とつながる第二の結論です。

先端のイベントは取り消され得ますが、配信済みイベントは自分では消えません。

取り消しメッセージを用意するか、T17 の outbox 条件で十分深いものだけ送ります。失わないことと、偽でないことは別の要件で、両方が必要です。

モデルを作る

三要素

イベントを失わないシステムの要素です。

カーソルの候補：三つ中、二つは誤り

タイムスタンプは誤りです。 同ミリ秒に複数あり、時計変更や複数インスタンスのずれで単調にならず、重複か欠落が出ます。

DB の自動採番も、多くの場合誤りです。 採番とコミットの順序は違います。A が 102、B が 103 を取り、B が先にコミットすると、読み手が 103 へ進んだ後で A がコミットします。102 は永久に読まれません。

エラーのない穴です。使うなら、十分古い行だけ読むか、単一書き手が直列割当する必要があります。

チェーン座標が適切です。 (chain_id, block_number, log_index) は単調で一意、インスタンス間で一致し、再起動後も一致します。ユーザーもチェーンで照合できます。

比較可能な文字列か大整数へ符号化します。

cursor = chainId : blockNumber : logIndex
      例：  1 : 00000000020134 : 0007

メッセージプロトコル：必須の種類

ライブラリから独立して記述します。

クライアント → サーバー   subscribe  { topics, cursor }   既読位置付き購読
サーバー → クライアント   snapshot   { cursor, state }    任意の現在状態
サーバー → クライアント   event      { cursor, type, payload }
サーバー → クライアント   revoke     { fromCursor }       この位置以降を無効化
サーバー → クライアント   reset      { reason }           古いカーソル。再購読を要求
双方向                    ping / pong                      生存確認

最後の三種類が漏れやすいものです。

reset は必須です。 有限窓の外まで離れたクライアントに、reset なしで黙って何も補わないと最新だと誤認します。正常に見えるため、切断より悪い状態です。

revoke は再編成の出口です。 未確認を送るなら、直前のイベントの無効化を通知します。実装しないなら、十分深いものだけ送り、深度へ任せます。

ハートビートは双方向です。 一方だけ送ると、片側しか相手の停止を判定できません。両側にタイムアウト判定が必要です。なければ半開接続が残ります。

スナップショットと増分の境界

現在を取得してから購読する順序は誤りです。

誤った順序：
  t0  スナップショット取得（cursor=100 まで）
  t1  ← cursor=101 が発生するが、誰も監視していない
  t2  購読を開始し、102 以降を受け取る

  結果：101 が兆候もなく永久に欠ける

購読、バッファ、スナップショット、解放の順です。

1. 接続して購読し、サーバーが接続のキューへイベントを入れ始める
2. まだ配信せず、クライアントかサーバーでバッファする
3. スナップショットと、その cursor を取得する
4. バッファの cursor がスナップショットより大きいものだけ順に送り、古いものを捨てる
5. 通常配信へ移る

逆の順序が、再接続後の欠落の頻出原因です。ちょうど境界の瞬間にイベントが必要なので、ローカルでは再現しにくいものです。

バックプレッシャー：待つのでなく縮退する

弱い回線、背景タブ、遅い実装で、読み手が遅い場合です。

第三が正解です。

バックプレッシャーの出口は、待機ではなく縮退です。

接続ごとに例えば 1000 件の有界キューを持ち、満杯なら、その接続の全待機を消して reset します。購読、スナップショット、補完を再実行させます。

古い数件だけ消してはいけません。見えない穴を作ります。すべて捨て、やり直しが必要と明示します。

再接続：バックオフにジッターを付ける

即時再試行は、障害サーバーをさらに圧迫します。指数バックオフを使います。

n 回目の待機 = min(基本間隔 × 2 の n 乗, 上限) × 乱数係数
係数は 0.5〜1.5

乱数は必須です。なければ再起動後に全クライアントが同秒に戻り、次の再起動でも同じことを繰り返す、周期的な自己攻撃になります。

配送保証：サーバーの正確に一度を追わない

ネットワークで正確に一度は実現できず、次を組み合わせます。

サーバー：少なくとも一度の配送。補完で数件再送することがある
クライアント：cursor で除去。既読以下なら捨てる
組み合わせ：効果として正確に一度

T15 の冪等性、T16 の主キー、T17 の再開と、同じ手法の四度目の登場です。一度だけ行うのでなく、複数回でも同じ結果にします。

ファンアウトと複数インスタンス

接続別キューと、トピックから接続への索引を用意し、イベントで検索、配送します。単一なら単純です。

複数なら中間のメッセージ基盤を使えますが、T16 の事実は一つという規則を守ります。基盤は伝送で、事実源ではありません。補完は DB をカーソルで照会します。

基盤の保存方針、分割順序、消費位置は別の故障可能な状態です。速さは基盤へ、正確性は DB へ任せます。

何と呼ぶか

実践

30 秒切断して再接続した受信列が、
常時接続の対照クライアントと、数量、順序、内容すべてで一致する。

select * from outbox
 where chain_id = $1
   and (block_number, log_index) > ($2, $3)   -- クライアントのカーソル
   and block_number <= $safeHeight
 order by block_number, log_index
 limit 1000;

- 数量は同じか？
- 順序は同じか？
- 各内容は同じか？
- 重複が届いた場合、除去が機能したか？

- 500 ミリ秒の遅延
- 10% のパケット損失
- 非常に低い帯域でバックプレッシャーを発生

AI Lab

第 1 段階：
切断再接続でイベントを失わない、チェーンの購読プロトコルを設計してください。
全メッセージ型、フィールド、両側の状態機械を示してください。

第 2 段階：
各場面で、どの部分が対応するか説明してください。
1. 30 秒切断し、12 イベントが発生。
2. 3 時間切断し、再生窓は 1 時間。
3. 読み取りが配信の十分の一の速度で、10 分継続。
4. 再起動で 5 万クライアントが同時切断。
5. スナップショット取得と購読の間にイベントが発生。
6. 配信済み 3 件が、再編成で無効になる。

第 3 段階：
未対応の場面はどれですか？最小変更と代償を説明してください。

実例

変数を一つ変える

持ち帰る問い

章末チェック