【ITニュース解説】Go Realtime Queues: What One Key Buys Gaming Presence During Reconnects

オンラインゲームにおいて、プレイヤーが現在ゲームルームにいるか、接続しているかといった「プレゼンス」（存在状態）を正確に把握することは非常に重要だ。しかし、ネットワークの瞬断や再接続といった事象が発生すると、システムが把握している接続数と、実際にゲームをプレイできるアクティブなプレイヤー数との間にずれが生じることがある。例えば、サーバー上では84人が接続中と表示されていても、実際にゲームに参加できるのは79人だけ、といった状況が発生する可能性がある。これは、古い切断情報が新しい再接続情報よりも後に処理されたり、期限切れの古い通信がアクティブな状態を維持していると誤って判断されたりするために起こる。従来の監視方法、例えば部屋ごとの接続数だけを追うダッシュボードや、キューの深さを示すグラフだけでは、これらの問題の根本的な原因である「因果関係」を特定することは難しい。

このような混乱を防ぎ、プレイヤーのプレゼンスを正確に保つために、記事では「一つのキー」をリアルタイム通信の経路と、非同期処理を行うキューの両方を通じて一貫して使用する方法を提案している。このキーは、個々のプレイヤーの接続セッションのライフサイクル全体を一意に識別するためのもので、例えば「ルームID」「プレイヤーID」「セッションID」を組み合わせた形などが考えられる。この「一つのキー」を導入することで、システムは特定のプレイヤーの単一の接続ライフサイクルに関する全ての情報に同じ名前を付けられるようになり、これにより情報の相関付け、キーの範囲内での順序付け、そして古くなった作業を拒否する実用的な仕組みが手に入る。ただし、このキー単体で全てのシステムにおける全体的な順序付けや、情報の「正確に一度だけの配信」、あるいは自動的な正確なプレゼンスを実現できるわけではない。

このキーには、主に三つの重要な情報が含まれる。一つ目は「相関キー」（CorrelationKey）で、これは特定のプレイヤーの特定の接続セッションを一意に識別するためのものだ。二つ目は「世代」（Generation）で、これはプレイヤーが再接続するなどして新しい接続セッションを開始した際に更新される数値で、古い接続と新しい接続を明確に区別するために使われる。三つ目は「シーケンス番号」（Sequence）で、同じ世代内で発生するイベントの順序を正確に把握するための連番である。タイムスタンプだけではこれらの疑問に信頼性高く答えることはできないため、これらの情報が組み合わされることで「どのプレイヤーのどのセッションに関する、どの時点の更新情報か」をサーバーが正確に判断できるようになる。

プレゼンスの正確性は、単に接続されているソケットの数ではなく、「サーバーの現在のビューが、プレイヤーの現在の接続世代と、決められた時間内に一致しているか」という問いによって定義される。問題発生時には、アラートを単なる再接続の量ではなく、持続的なプレゼンスの不一致で発生させるべきだ。そして、影響を受けている部屋から相関キーと世代情報へと焦点を移し、消費側で受け入れられたシーケンス番号と拒否されたシーケンス番号を比較する。さらに、イベントの経過時間を検査して、古い順序付けが原因なのか、処理の遅延なのか、有効期限切れのポリシーが原因なのかを判断する。最終的な対処は、一つの世代、一つのプレイヤーセッション、または一つの部屋のパーティションといった最も狭い範囲で行うべきである。この「一つのキー」があるからこそ、このような詳細な分析と迅速な対処が可能になる。

キーを設計する際には、可変な状態（例えばサーバーアドレスやオンライン状態のフラグなど）をキーに含めるべきではない。これらはフィールドとして扱うべき情報だ。また、プレイヤーIDだけをキーとして再利用すると、二つの異なるタブからの接続や古い接続と新しい接続が誤って同じ順序付けの対象となってしまう可能性がある。キーが長すぎると、キューの記録、ログ、インデックス、メトリックラベルなどで容量のコストもかかるため、適切な長さの不変な識別子を使用することが望ましい。

システムは、古い情報を適切に拒否するメカニズムを備える必要がある。プレゼンスの永続的な情報を保持するストアが、この拒否の最終的な判断点となる。消費側は、まずイベントの「世代」を、次に「シーケンス番号」を現在の状態と比較する。イベントの世代が現在の状態の世代よりも古い場合、そのイベントは拒否される。もし世代が同じ場合でも、イベントのシーケンス番号が現在の状態のシーケンス番号以下であれば、それは古い情報と判断され拒否される。このようなロジックを実装することで、古いイベントが誤って新しい情報として適用され、不正確なプレゼンス状態を引き起こすことを防ぐことができる。本番環境では、現在の値を読み込み、新しい値を書き込む処理が、単一の原子的な操作として実行されることを保証する必要がある。そうしないと、複数の処理が同時に比較を通過し、誤った順序でコミットされてしまう可能性があるからだ。

このシステムを設計する際には、キャパシティプランニングも重要だ。接続数や更新頻度に応じてトラフィックが増大するため、必要な処理能力を事前に見積もる必要がある。キーのカーディナリティ（キーの種類の多さ）も考慮し、例えば全てのセッションをメトリックラベルとして使用すると、監視システムの容量を圧迫する可能性があるため、集計されたメトリックと個別の追跡のためのログやトレースを適切に使い分けるべきである。

監視においては、消費側で受け入れられた遷移、古い世代による拒否、古いシーケンスによる拒否、そしてイベントが観測されてから状態がコミットされるまでのレイテンシの四つの情報を計測することが推奨される。また、定期的に部屋のビューが権威ある未期限切れの世代と一致しているかを確認するサンプリングも行う。デプロイメントは段階的に進めるべきで、まずキー、世代、シーケンスを導入し、状態変更は行わずにそれらが適切に機能するかを確認する。次に、拒否ルールをシャドウモードで実行し、不一致を記録する。そして初めて、小さな範囲の部屋から拒否ルールを適用し、ロールバックパスを確保しながら展開する。

アラートの閾値設定も重要だ。単一の古い情報の拒否は、防御が機能した証拠であるため、すぐにページングするのは適切ではない。ユーザーに見える不一致がプレゼンスのサービスレベル目標（SLO）の許容範囲を超えたときにページングし、古い情報拒否率やイベントの経過時間は、診断や早期警告のシグナルとして使用すべきだ。

まとめると、一つの共有キーは、イベント間の因果関係を確立し、それを強制するための証拠の連鎖とスコープを提供する。しかし、プレイヤーが実際に観測する部屋の状態を正確にするためには、このキーを世代、シーケンス番号、条件付き書き込み、有効期限のセマンティクス、そして具体的なサービスレベル目標と組み合わせることが不可欠である。