【ITニュース解説】Go WebRTC Contract Tests: Five Presence Signals for Realtime Auction Bidders

リアルタイムオークションのようなシステムでは、参加者への通知が非常に重要だ。しかし、WebRTCのようなリアルタイム通信技術を使っているからといって、単に接続が開いているだけで安全な通知が保証されるわけではない。例えば、参加者のデバイスがスリープに入ったり、ネットワークが一時的に切断されたりすると、接続状態が不安定になり、通知が届かなかったり、誤った情報が届いたりする可能性がある。サーバー側は「この参加者が今このイベントを見る権限があるか？」という問いに、確実かつ防御可能な答えを出す必要がある。単に通信チャネルが開いていることを許可とみなすのは危険なのだ。

そこで重要なのが、通知を単なる「データ」ではなく、「決定記録」として扱う考え方だ。これは、ソケット（物理的な通信路）の状態に依存するのではなく、サーバーが特定の参加者に特定の通知を送ることを「決定した」という事実を記録するものだ。この決定記録は、ネットワークの再接続や、過去のイベントを再生（リプレイ）する場合、さらには遅れて届いた切断通知など、さまざまな状況に耐え、その意味が変わらないように設計する必要がある。

通知の安全性を確保するため、記事では「エンベロープ（封筒）」という考え方を提案している。これは、オークションイベントそのものの内容（本文）だけでなく、その通知がなぜ、誰に、いつ、どのような条件で送られるべきかを記した情報を「封筒」としてまとめるものだ。クライアント（参加者のブラウザなど）は封筒の中身、つまりイベントの本文を表示できるが、封筒自体を編集して、勝手に他の人に通知を見せたり、権限を広げたりすることはできない。

このエンベロープには、特に以下の5つの重要な情報（シグナル）が含まれる。一つ目は、通知を受け取るべき「認証された参加者」を識別するID。二つ目は、通知の対象となるオークションに参加しているかどうかの「オークションメンバーシップ」の情報。三つ目は、現在有効な通信セッション（接続）のバージョンを示す「セッションバージョン」。四つ目は、この通知がいつまで有効であるかを示す「有効期限」。そして五つ目は、通知が送られる順序を示す「シーケンス」番号だ。これらの情報に加え、イベントを一意に識別するID、データ構造のバージョン、適用された規則のバージョン、発行時刻などがエンベロープに含まれる。金額などの機密情報は、個別の参加者向けに調整された後で本文（Body）に入れられ、エンベロープには直接アクセス情報や他人の秘密情報を格納しないことが重要だ。

WebRTCのような通信路の「接続状態」は、必ずしもサーバーが考える「参加者のオンライン状態」と一致しない場合が多い。例えば、参加者のノートパソコンが蓋を閉じてスリープに入っても、WebRTCの接続がすぐに切断されるとは限らない。また、切断通知が遅れて届き、その間に新しい接続が確立されてしまうこともある。このような問題を解決するため、各接続を「リース」としてモデル化し、セッションバージョンを割り当てる。サーバーは定期的なハートビート（生存確認信号）でリースを更新し、セッションバージョンが一致する場合にのみ切断を有効にする。これにより、古い接続の切断通知が新しい接続を誤って終了させてしまうのを防ぐことができる。

リアルタイムシステムでは、メッセージの順序が非常に重要だ。例えば、同じイベントが二度送られてしまったり、古いイベントが新しいイベントよりも遅れて届いたりすると、混乱が生じる。そこで、すべてのイベントには一意のIDと、そのスコープ（例えば特定の参加者向けの通知ストリーム）内での単調増加するシーケンス番号が割り当てられる。これにより、クライアントは重複したイベントを無視したり、すでに処理した古いイベントを破棄したりすることが可能になる。サーバー側は、クライアントが最後に受け入れたシーケンス番号を元に、どのイベントをリプレイすべきかを判断できる。

リアルタイムでの通知配信と、過去のイベントをリプレイする際の両方で、全く同じ認証ロジックを使用することが重要だ。これにより、システム全体の一貫性が保たれ、テストも容易になる。認証ロジックは、ネットワークやキャッシュの状態に依存しないように設計し、純粋な入力に基づいて結果を決定できるようにする。記事で示されたGo言語のAuthorize関数は、以下の条件で通知を拒否する。第一に、通知の対象参加者と、実際に認証されている参加者が異なる場合。第二に、通知の対象オークションに参加者がメンバーとして登録されていない場合。第三に、通知の有効期限が切れている場合。第四に、通知が古いセッションバージョンに紐づけられている場合（現在の接続がより新しいセッションであるにも関わらず）。第五に、通知のシーケンス番号が、すでに受け入れたシーケンス番号よりも古いか同じ場合だ。これらの拒否理由を明確にすることで、システムの状態を正確に把握し、問題発生時に原因を特定しやすくなる。

このような複雑なシステムを導入する前には、徹底したテストと監視が不可欠だ。各認証条件が正しく機能するかを確認する「契約テスト」を行う。例えば、許可された参加者、メンバーシップが取り消された場合、オークションが一致しない場合、エンベロープが期限切れの場合、重複したイベント、古いイベント、通知の範囲が欠落している場合、古いセッションの切断など、さまざまなシナリオを網羅的にテストする。また、本番環境に展開する前には、意図的に障害を発生させる「障害訓練」を実施し、システムが期待通りに動作するかを確認する。例えば、切断を遅延させたり、イベントを重複させたり、再接続中にメンバーシップを取り消したり、リプレイ用ストレージから一部のシーケンスを削除したりする。これにより、システムが新しいセッションを優先し、重複イベントを無視し、メンバーシップ剥奪時にはリプレイをブロックし、欠損時には適切なスナップショットを提供することを確認できる。システム運用においては、各拒否理由（「誤った受信者」「非メンバー」「期限切れ」など）を個別のメトリックとして監視することで、問題の種類を迅速に特定できる。

システムが進化するにつれて、通知のデータ構造（スキーマ）も変更される可能性がある。このような変更は段階的に慎重に行う必要がある。まず、新しいフィールドを追加する場合、古いバージョンのシステムでもそのフィールドを読み取れるように準備し、次に新しいフィールドを書き込む。その後、新しいバージョンが正常に動作していることを確認してから、そのフィールドを必須にする、といった手順を踏む。

このような厳格なプレゼンス管理と通知の安全性を確保する設計は、すべてのシステムに必要というわけではない。もし通知が公開情報であり、参加者のオンライン状態が単なる装飾的な意味しか持たず、メッセージが一部失われても大きな問題がなく、クライアントがいつでも最新のスナップショットを簡単に取得できるようなシステムであれば、もっとシンプルな「発行と更新」モデルで十分だ。しかし、プライベートなリアルタイムオークションのように、誤った情報が情報漏洩につながったり、間違った行動を誘発したりする可能性がある場合、この設計は非常に価値があり、その複雑さに見合うだけのメリットがあるのだ。