【ITニュース解説】Realtime Backpressure for Gaming Kanban Boards: Five Go Test Invariants

オンラインゲームの共有カンバンボードのようなリアルタイムシステムでは、ユーザーが同時に多くの操作を行うことがある。例えば、複数のプレイヤーが同時にカードを移動させたり、ネットワーク接続が一時的に切れたりすることもある。このような状況でシステムが安定して動作するためには、内部で発生する大量の処理を適切にさばく仕組みが必要になる。これを「リアルタイムなバックプレッシャー（負荷制御）」と呼ぶ。

この記事は、特にゲーム開発スタジオで使われる共有カンバンボードを例に、このバックプレッシャーをどのようにテストし、システムがどのような状態でも正しく動作することを保証するかについて解説している。

多くの場合、「再接続後にユーザー数が正しくない」といったアラートが表示されるのは、既に問題が発生した後であり、手遅れな状況である。このようなアラートが出る頃には、ゲームスタジオのカンバンボードでは、多くのカード移動が一気に受け入れられ、部屋の全員に通知された後、プレイヤーがネットワークを切り替える際に、そのうちの一つがうまく通知されなかった、といった事態が起こっているかもしれない。最終的なボードの状態は一見正しく見えるかもしれないが、内部的なデータの一貫性や、各クライアントとサーバー間の同期に問題が隠れている可能性がある。問題の兆候は、ボードの表示そのものではなく、たとえばカーソルの位置のような細かい部分に現れることがある。

このような問題に対処するためには、アラートが発生してから対応するのではなく、より早い段階で問題の兆候を捉える必要がある。具体的には、特定の部屋における処理待ちのキューの深さが増加していること、新しい処理の受け入れが拒否されていること、あるいは再接続時の処理がSLA（サービスレベル目標）を超過していることなどが、問題の早期発見につながる重要なシグナルとなる。これらのシグナルを追跡することで、問題がシステムの処理能力不足によるものなのか、処理の順序に関するものなのか、それともユーザーのオンライン状態（プレゼンス）に関するものなのかを特定できる。そして、これらのシグナルは、単に時間を待つだけのテストよりも、はるかに信頼性の高いテストの基準となる。

リアルタイムのバックプレッシャーテストが、再接続するカンバンクライアントに対して何を証明すべきか。これに対し、五つの不変条件が提案されている。これは、システムが常に満たすべき基本的なルールや保証である。

一つ目は「受け入れは制限される」こと。これは、部屋のキューが処理能力の限界に達した場合、新しい操作の受け入れを一時停止するか、または明確な拒否応答を返す必要があることを意味する。クライアントの操作速度が速すぎても、サーバーのメモリが無制限に増大してシステムがクラッシュするような事態は避けるべきである。

二つ目は「一つのカードに対するバージョンは順序通りに適用される」こと。例えば、異なるカードに対する操作は並行して処理されてもよいが、同じカードの操作は、必ずバージョン番号の順に適用されなければならない。カードがバージョン12からバージョン11に戻るようなことは許されない。これはデータの整合性を保つ上で非常に重要である。

三つ目は「受け入れられた全ての操作には関連IDと最終結果がある」こと。システムが受け入れた全ての操作には、一意の識別子（関連ID）が付与され、その操作が「適用された」「拒否された」「期限切れになった」のいずれかの最終結果を持つことが保証されるべきである。これにより、操作の追跡と検証が可能となる。

四つ目は「再接続はスナップショットとサーバーカーソルを返す」こと。クライアントがネットワーク切断から再接続する際、サーバーはボードの現在の完全な状態（スナップショット）と、その状態に対応するサーバー側の処理位置（サーバーカーソル）をクライアントに提供する必要がある。クライアントは、自分の手元にある古い情報から不足しているメッセージを推測するのではなく、サーバーから提供された正確な情報に基づいて状態を更新するべきである。

五つ目は「プレゼンスには明示的なリースと有効期限ポリシーがある」こと。ユーザーの接続が一時的に切断されたとしても、それが直ちにそのユーザーがボードから離れたことを意味するわけではない。特にモバイルネットワーク環境では、一時的な切断と再接続は頻繁に発生する。そのため、ユーザーがオンラインである状態（プレゼンス）には有効期限（リース）を設けることで、一時的な切断に対して猶予期間を与え、適切なタイミングでプレゼンスを更新する仕組みが必要になる。

これらの不変条件を検証するために、記事ではGo言語を用いた具体的なテストハーネスの例が示されている。このテストハーネスは、消費（処理）を一時停止させ、複数の操作を送信し、容量の境界が正しく機能するかを直接検証する。この際、time.Sleepのような「壁時計の遅延」は一切使わない。これは、time.Sleepがシステムのスケジューリングのタイミングに依存するため、テストの再現性や信頼性が低いとされているからだ。代わりに、イベント駆動型でテストを進めることで、より確実な検証が可能となる。

例示されたBoundedQueueというシンプルなデータ構造は、指定された容量を持つキューとして機能する。Submitメソッドはキューが満杯でなければ操作を追加し、満杯であればfalseを返す。DrainOneメソッドはキューから一つ操作を取り出す。TestAdmissionWithoutSleepというテスト関数では、容量が5のキューに対して10個の操作を連続して投入し、最初の5個は受け入れられ、残りの5個は拒否されることを検証している。その後、キューから5個の操作を正しく取り出せることも確認する。このようなテストは、time.Sleepに頼ることなく、キューの容量制限という重要な機能が正しく動作することを証明する。

サービスにおいて、キューから処理を取り出すシグナルは、Go言語のチャネル受信、メッセージブローカーからの承認、あるいはデータベーストランザクションの完了といった形を取るかもしれない。重要なのは、これらのシグナルをテストから直接監視できるようにすることである。これにより、決められた条件を満たすまで待機するテストが可能になり、スケジューラのタイミングに依存する不確実なtime.Sleepを回避できる。

また、テストでは最終的なボードの状態だけでなく、一連の処理の「トレース」（イベントの履歴）も検証することが重要である。たとえば、あるテスト実行では、最終的に表示されるカードの状態は再接続後も同じだったにもかかわらず、実際にはサーバーカーソルとクライアントのローカルバージョンを比較した結果、同じ編集操作が二重に発行されてしまっていた、ということがあった。このような場合、単に最終状態だけを検証するテストでは問題を見逃してしまう。ルーム識別子、プレゼンスの移行、操作受け入れ前のキューの深さ、拒否された正確な理由など、イベントの完全なシーケンスをテスト出力に含めることで、正しく拒否された操作と、受け入れられた後に再実行され、そして見えない形で上書きされてしまった操作とを区別できるようになる。この詳細なトレースがアラートに添付されていれば、担当者は適当なtime.Sleepを試したり、テストが偶然成功するまで何度も実行したりすることなく、問題のスケジューリング順序を再現し、根本原因を特定できる。

バックプレッシャーの境界（キュー）をどこに設定するかには、いくつかの選択肢がある。

一つは「プロセス内メモリ」である。これは最も高速な方法であり、処理の一時停止と再開を素早く行える。しかし、プロセスがクラッシュすると、キューに入っている未処理の作業は失われるという制約がある。単体テストや、単一のノードで動作するプロトタイプに適している。

二つ目は「永続的なブローカー」である。これは、システムが再起動してもキュー内のデータが失われず、メッセージの承認や再配信といった信頼性の高いセマンティクスを提供する。複数のワーカープロセスにまたがって部屋が分散配置されるようなシステムに適している。ただし、監視すべき承認状態が増えるため、運用が複雑になる。

三つ目は「データベースアウトボックス」である。これは、データ変更とメッセージ公開を一つのデータベーストランザクション内で処理できるため、データの整合性を保証しやすい。しかし、データベースのポーリングや変更ストリームの遅延が発生する可能性がある。監査可能な書き込みログが必要なカンバンボードに適している。

これらの選択肢にはそれぞれ利点と欠点があるため、システムの要件やチームの運用能力に合わせて適切なものを選択する必要がある。例えば、プロセス終了時にデータが失われても許容される場合や、部屋の処理が単一のプロセスで完結する場合は、シンプルなプロセス内メモリキューが適している。一方で、ワーカープロセスが再起動してもサービスレベル目標（SLO）を達成するために処理を再開する必要がある場合は、永続的なキューを選ぶべきである。再配信のメトリクス監視、デッドレターキューの処理、カーソルの修復といった運用がチームにとって負担が大きい場合は、よりシンプルなキューに留まるのが賢明かもしれない。

誤ったアラート（フォールスポジティブ）は、運用コストが非常に高い。例えば、通常規模のトーナメントが開始された際に一時的に3秒間だけキューの深さが増加するような状況でアラートが鳴ってしまうと、担当者はそれを無視するようになり、本当に問題のある再接続の前に5分間かけて徐々にキューが溜まっていくような深刻な兆候を見逃してしまう可能性がある。そのため、アラートの閾値は、部屋の規模、処理速度、再接続の遅延といった要素に基づいて慎重に調整し、単一の一時的なピークではなく、持続的な違反があった場合にのみアラートを発するように設定すべきである。

システムが正しく動作しているかを確認するための計測（インストゥルメンテーション）も非常に重要である。ルームID、現在のキューの深さ、操作の受け入れ結果、操作のバージョン、サーバーカーソル、プレゼンスリースの残り時間などを構造化されたログとして出力することが推奨される。特に、拒否された書き込みと期限切れになったプレゼンスリースは、別々のカウンターで計測すべきである。そうしないと、ダッシュボードでは「トラフィックは正常」と表示されていても、実際にはプレゼンスの正確性が低下しているという誤解を招く可能性がある。再接続時の処理時間（リプレイ期間）や、操作が承認されるまでの時間（タイムツーアック）の分布をヒストグラムで可視化することは、再接続のSLAに直接対応する重要な指標となる。

テストにおいては、プレゼンスリースの期限切れやリトライポリシーのテストのためだけに、仮想的な時計（フェイククロック）を導入し、明示的に時間を進めることで、正確なプレゼンスイベントを検証する方法が有効である。キューからの処理を取り出すテストは、引き続きイベント駆動型で行うべきである。すべてのゲームモードに単一の閾値を適用するのは難しいかもしれないため、最初は部屋ごとのデータ分布を観察し、実際の再接続トレースに基づいてポリシーを調整していくのが現実的なアプローチである。

最終的に、運用上の確認はシンプルである。アラートが鳴った際に、そのトレースが「受け入れが停止したのか」「どのカーソルが発行されたのか」「プレゼンスリースがいつ期限切れになったのか」という疑問に明確に答えられるべきである。もしこれらの情報がトレースから読み取れない場合、単にシステムの処理能力（キャパシティ）を増やしたとしても、問題の根本原因は特定されず、下流のどこかに謎が移動するだけになってしまう。システムの安定稼働のためには、単なる最終状態の確認にとどまらず、システム内部の動きを詳細にテストし、監視する体制が不可欠である。