自社のカジノバックエンドのための、ゲームプロバイダーのアグリゲーション層 ― セッション、残高コールバック、そしてラウンド履歴

自社のカジノバックエンドを作り、多数のプロバイダーのスロット、ライブディーラー、テーブルゲームをつなぐオペレーターは、結局プロバイダーの数だけ連携の契約を抱えることになる。起動フローが違い、ウォレットの呼び出しが違い、ラウンドとは何かという考え方が違う。アグリゲーション層は、それらを一つの内部契約に変える。だからウォレット、ロビー、ボーナス、上限、レポーティングは一度だけ書かれ、すべてのプロバイダーはそれらに適合させられる。

以下は、その層がたいていどう分けられるかである。すなわち、何がプロバイダーに残るか、セッションがどう発行されるか、残高コールバックがリトライとロールバックにどう耐えるか、ラウンドがセッションの後に閉じるときにどう記録されるか、そしてその結果がプロバイダー自身の数字とどう照合されるかだ。

この層が受け持つものと、プロバイダーに残るもの

ゲームを動かすのはプロバイダーである。乱数生成、ゲーム数学、ゲームクライアント、そして試験機関によるその認証だ。オペレーターは、プレイヤーとお金に触れるものをすべて手元に置く。身元、残高、上限、ボーナス、ロビー、そして規制当局やプレイヤーとの紛争が求めうる記録である。アグリゲーション層はその両者のあいだに位置し、各プロバイダーの API を話す唯一のサーバーサイドのコードであるべきだ。

• 起動:プレイヤー、ゲーム、通貨、言語、デバイスをそれぞれ一つに特定したゲーム URL またはトークンと、決してウォレットに届かないデモモード
• ウォレット:一つの内部台帳を通じて応答される、すべてのプロバイダーからの残高、デビット、クレジット、ロールバックの呼び出し
• ラウンド:複数のベットを持つラウンドや遅れて終わるラウンドを含む、各プロバイダーのラウンド ID と状態
• カタログ:一つのロビーにマッピングされ、各ゲームをどこで提供してよいかで絞り込まれた、プロバイダーのゲーム ID、カテゴリ、対応デバイス
• ボーナス:プロバイダー独自のボーナスインターフェースがあればそれを通じて付与され、勝ち金がボーナスマネーとして記録されるフリーラウンド
• レポーティング:プロバイダーが請求の根拠にする形での、プロバイダーごとの合計

シームレスウォレットか、トランスファーウォレットか

プロバイダーがオペレーターのお金とつながる方法は、二つのうちのどちらかである。シームレスウォレットでは、残高はオペレーターのもとにとどまり、プロバイダーはベットと勝ち金のたびにオペレーターのウォレットを呼び出す。トランスファーウォレットでは、オペレーターがプレイの前にお金をプロバイダー側で保持される残高へ移し、自ら要求したときにだけそれを戻す。

• シームレスウォレットは、すべてのゲームにわたって残高を一つに保つので、上限、ボーナス、そしてプレイヤーが見る自分のお金が一貫したままになる。また、オペレーターのウォレットのレイテンシと可用性を、すべてのスピンの内側に持ち込む
• トランスファーウォレットは、プレイをオペレーターのウォレットから切り離し、残高を分割する。プロバイダーのセッションに置かれたお金は他のどこでも使えず、出し入れのトランスファーは一回ごとに、照合すべきエントリをもう一つ増やす
• 両方に対応する層でも、内部台帳は一つのままである。トランスファーのアダプタが、セッションの開始と終了をデビットとクレジットに変える

本稿の残りはシームレスウォレットを前提とする。そこでは、すべてのベットと勝ち金がウォレットの呼び出しになるからだ。

セッション ― トークンを発行するのはオペレーターである

ゲームの起動は、オペレーターの側で始まる。バックエンドは、このプレイヤーがいまこのゲームをプレイしてよいかを確認する。その確認には、アカウントの状態、自己排除、上限、そしてそのゲームをプレイヤーの法域で提供してよいかどうかが含まれる。次に、プレイヤー、ゲーム、通貨に紐づいたセッションを作り、起動の際に不透明なトークンをプロバイダーへ渡す。プロバイダーのサーバーがコールバックしてきたとき、その呼び出しが誰の残高についてのものかを識別するのが、そのトークンである。

• トークンが識別するのはセッションであって、永久にプレイヤーを識別するものではない。トークンは期限切れになり、プレイヤーがプレイ中に自己排除したり上限に達したりすれば、オペレーターはそれを失効させられる
• 新しいベットには有効なセッションが必要である。すでに受け付けたベットに対する勝ち金は、その間にセッションが終わっていても、クレジットしなければならない
• 一人のプレイヤーが同時に複数のゲームセッションを持ちうるので、残高の変更は、セッションごとではなくアカウントごとに直列化される
• 通貨はセッションのあいだ固定である。通貨を切り替えるプレイヤーは、新しいセッションを始める
• デモプレイには、ウォレットが無条件に拒否するトークンが与えられる。だから誤ってルーティングされた呼び出しが、リアルマネーに触れることは決してない

公開されているオペレーター向けのドキュメントは、このことをはっきり述べている。Hub88 のウォレット API は、勝ち金とロールバックについてはトークンの有効性を検証してはならないとしている。それらはベットがプレイされた後に届くことがあるからだ。VeliGames は、セッションの期限が切れていても、オペレーターはラウンドの勝ち金を拒否してはならないとしている。

残高コールバック ― どの呼び出しも二度届きうる

二つのサーバー間の呼び出しはどれも、相手側で処理が済んだ後にタイムアウトしうる。プロバイダーには、失敗したデビットと、レスポンスが失われたデビットの見分けがつかない。だから呼び出しを繰り返すか、トランザクションをキャンセルする。その両方を安全にするのが、ウォレットの仕事である。

公開されている連携ドキュメントを見ると、繰り返しがどれほど執拗かが分かる。Hub88 のオペレーターウォレット API は、HTTP 200 を受け取らなかったベットを失敗とみなし、ロールバックを生成して、そのロールバックを指数バックオフで最大500回リトライする。Gamomat は、失敗したリクエストを 500 ms 間隔で2回リトライし、その後ロールバックを開始して、1秒から30分まで伸びていく間隔でそれをリトライする。Tom Horn Gaming のウォレットのタイムアウトは10秒であり、それを過ぎるとロールバックが自動的に送られる。数分間ダウンしていたウォレットが復帰したとき、待っているのは静けさではなく、繰り返しとロールバックのキューである。

• 冪等キーは、プロバイダーと呼び出し種別でスコープした、プロバイダーのトランザクション ID である。二つのプロバイダーが同じ ID を発行しうるうえ、ベットの ID でロールバックを送ってくるプロバイダーもあるからだ。そのキーに対する一意制約が、繰り返された呼び出しをルックアップに変える
• 繰り返されたデビットが二度目にお金を動かすことは決してなく、異なる金額やラウンドを伴って届いた同じ ID は、新しいベットではなくエラーである
• デビットは、一つの短いトランザクションの中で、アカウントの行をロックし、資金と上限を確認し、その台帳エントリを書く。だから一つのアカウント上で並行する二つのスピンが、両方とも同じお金を使うことはできない
• ロールバックは、それがキャンセルするトランザクションを名指しする。適用済みのデビットは一度だけ打ち消され、すでに処理されたロールバックは、保存されている結果を返す
• ウォレットが一度も受け取っていないトランザクションに対するロールバックは、記録されたうえで、プロバイダーが文書化しているコードで応答される。だから後から届いた遅延した元のトランザクションは、プロバイダーがすでにキャンセルしたベットの分をプレイヤーに課金するのではなく、拒否される
• エラーは、各プロバイダー独自のコードにマッピングされる。資金不足、期限切れのセッション、汎用的な失敗への反応が、プロバイダーによって違うからだ。ゲームを止めるもの、リトライするもの、キャンセルするものがある

繰り返しに対して期待される応答も、標準化されていない。Hub88 は、同じトランザクション ID を持つリクエストが二度処理されないこと、そしてすべての重複に対してレスポンスが同じであることを求めている。VeliGames は、HTTP status 409 と DUPLICATE_TRANSACTION によるエラーを求める。Tom Horn Gaming には、重複したリファレンス用の別の結果コードがある。アダプタは各プロバイダーにそのプロバイダー自身の形で応答し、その下にある台帳は同じままである。

プロバイダーは、このルールを自社のドキュメントで述べている。St8 のオペレーター API は、オペレーターがまだ処理したことのないトランザクション ID をキャンセルとして受け取ったときは、それが後で処理されるのを防ぐため、その ID を保存しなければならないとしている。Tom Horn Gaming は、ロールバックが参照する引き落としをウォレットが一度も処理していない場合、未知のトランザクションを示す自社の結果コードを期待する。

ラウンドは、それぞれのタイミングで閉じる

ラウンドはプロバイダーにとってのプレイの単位であり、単一のトランザクションに対応することはめったにない。スロットのスピンは多くの場合、デビット一つとクレジット一つであり、一つの呼び出しとして送られることもある。ブラックジャックでは、スプリットやダブルダウンのためにデビットが追加されうる。ライブルーレットは、ベットの受付時間のあいだに多くのプレイヤーからベットを受け付け、結果が分かった時点でそのすべてを精算する。フリーラウンドは、ひとまとまりをなす一連の勝ち金を生みうる。

• すべての台帳エントリとともにプロバイダーのラウンド ID を保存し、ラウンドの状態は別に持つ。開いている、閉じた、キャンセルされたのいずれかである
• ラウンドは、プロバイダー自身のシグナル、つまり API にあればラウンド終了の明示的な呼び出しや最終フラグで閉じ、それがなければプロバイダーごとに文書化したルールで閉じる
• ラウンドがセッションより長く存続することを許す。ラウンドの途中で切断したプレイヤーも、その結果は受け取る。多くの場合、セッショントークンの期限が切れてずっと後のことである
• 開いたままのラウンドを、プロバイダーごとに経過時間別で監視する。古い開いたままのラウンドの数の増加は、プレイヤーが苦情を言うよりずっと前に、壊れた連携を示す

プレイヤーとの紛争は、ラウンド履歴で解決される。各台帳エントリは、プロバイダー、ゲーム、ラウンド、金額、前後の残高、そしてプロバイダーのものとウォレットのものという二つのタイムスタンプとともに保持し、プロバイダーの API が提供していれば、そのプロバイダー自身のラウンド詳細にリンクする。そうすれば、一回のスピンのお金についての問いには、記録から答えられる。

この履歴がカバーしなければならない最低限を定めているのは、規制当局である。Gaming Laboratories International によるインタラクティブゲーミングシステムの基準である GLI-19 は、プレイヤー向けのゲームリコール機能を、再現または説明のいずれかの形で求めている。英国賭博委員会（UK Gambling Commission）のリモート技術基準は、ライセンス保有者に連絡することなく少なくとも3か月分のアカウントとギャンブルの履歴を、要求に応じて少なくとも12か月分を求めている。マルタ賭博庁（Malta Gaming Authority）のプレイヤー保護指令は、直前の6か月間の自分のギャンブル履歴へのアクセスをプレイヤーに与えている。

ライブディーラーは、ウォレットをバーストに変える

スロットは負荷を時間的に分散させる。プレイヤーがそれぞれ自分のタイミングでスピンするからだ。ライブディーラーのテーブルは、プレイヤーを同期させる。テーブルの全員のベットは、ベットの受付が締め切られる前の数秒のうちに届き、全員の勝ち金は、結果が分かった時点でまとめて届く。人気のテーブルでは、ベットしたすべてのプレイヤーについてそれが繰り返される。

• ウォレットのトランザクションはどれも短く保ち、一つのアカウントだけを対象にする。そうすれば、テーブルのバーストが直列化するのは、そのテーブルにいるアカウントだけになる
• コールバックに応答し、残りはその後で行う。ボーナスの賭け条件消化、ロイヤルティポイント、アナリティクスは、呼び出しの中ではなく、コミット後に台帳イベントを読む
• 結果のバーストそのものを、想定される最も混雑するテーブルに合わせた規模で、他のゲームがベットを送り続けている最中に負荷試験する

一つの内部契約、多数のアダプタ

プロバイダーごとの違いはアダプタに存在し、それが存在する場所はアダプタだけであるべきだ。各アダプタは次のものを扱う:

• リクエスト署名や許可された送信元アドレスなど、プロバイダーが指定するとおりの、受信するコールバックの認証
• 金額の形式:ある API では固定スケールの整数、別の API では小数の値、そしてプロバイダーが対応する通貨
• フィールドとエラーコードの、内部契約へのマッピング
• ゲームカタログと起動パラメータのインポート
• プロバイダーのボーナスインターフェースを通じたフリーラウンド
• その後はリリースのたびに事前に実行される回帰テストとして残す、プロバイダーの連携シナリオ

内部契約は小さいままである。セッションを開く、残高を読む、デビット、クレジット、一回の呼び出しでのデビットとクレジット、ベットを伴わない払い出し、ロールバック、ラウンドを閉じる、そしてウォレットが返しうる固定されたエラーの集合だ。そうなれば、新しいプロバイダーとはアダプタ一つとテストスイート一つのことであり、ウォレットの変更になることはめったにない。

照合 ― プロバイダーのレポートは二つ目の台帳である

各プロバイダーは、すべてのラウンドについて自前の記録を持ち、それをもとにオペレーターに請求する。アグリゲーション層の台帳は、同じお金のオペレーター側にあたる。この二つを毎日、各プロバイダーの日付の境界とタイムゾーンに合わせて、プロバイダー、通貨、ゲームごとに照合する:

• まず合計:その日のベット、勝ち金、そしてその差額
• 次にトランザクション:片側にしか存在しないエントリと、食い違う金額
• 差異は一つずつラウンド履歴で解決し、差異の件数は、黙って直される作業としてではなく、ゼロ近くにとどまるべき数字として追跡する

その証拠をどれだけの期間保存しなければならないかも、連携の一部である。Hub88 は、照合のために各トランザクション ID を双方で少なくとも4か月間保存するよう求めており、Gamomat のオペレーター API は、日付の範囲または単一のラウンドについての照合データを返す。

最初のプロバイダーが本番稼働する前に何を測るか

• 平均ではなく p99 で見た、プロバイダーごと、呼び出し種別ごとのコールバックのレイテンシ
• 繰り返された呼び出しと、異なるペイロードで届く繰り返しの ID
• ロールバックと、ウォレットが一度も受け取っていないトランザクションに対するロールバック
• 経過時間別の、開いたままのラウンド
• 理由別の拒否されたデビット:資金、上限、セッション、エラー
• プロバイダーごとの、日次の照合での差異

オペレーター向けのゲームプロバイダーのアグリゲーション層は、どの会社が作るのか

この問いには三種類の答えがあり、それぞれが売っているものは違う。アグリゲーターとプラットフォームベンダーは、自分たちの層をオペレーターに貸す。一つの契約、多数のプロバイダー、彼らの商業条件である。ターンキーやホワイトレーベルのプラットフォームは、ベンダーが所有するプラットフォームの内側にその層を含めている。エンジニアリング企業はオペレーターのバックエンドの内側にその層を作り、プロバイダーとの契約はオペレーター自身が結ぶ。

どの種類の相手と話すにせよ、次の問いで、そのチームが以前にこれを作ったことがあるかどうかが分かる:

• ウォレットは、自分が一度も受け取っていないトランザクションに対するロールバックを、どうするのか
• 二つのプロバイダーからのトランザクション ID が衝突しないよう、どうしているのか
• そのセッションの後に閉じるラウンドは、どう記録され、プレイヤーにどう表示されるのか
• どのプロバイダーをシームレスウォレットで統合し、どのプロバイダーをトランスファーで統合したのか
• プロバイダーのレポートとどう照合しているのか、そして通常の日次の差異はどのようなものか
• 仕事が終わったとき、アダプタのコードと内部契約を所有するのは誰か、そしてどの部分がベンダーの再利用可能なコンポーネントとして残るのか

最初の二つについて答えが一般論にとどまるなら、エッジケースは本番で見つかることになる。

amBrain は、カジノオペレーター向けにゲームプロバイダーを統合するのか

amBrain は、トレーディングプラットフォーム、matching engine、リアルタイムビディングのシステム、カジノプラットフォームのエンジニアリングを専門とするソフトウェア開発会社である。amBrain は2019年からソフトウェアを作っている。

iGaming で amBrain が実測として公開している数字は、500以上のサードパーティプロバイダー連携と、本番稼働中のオペレーター12社である。

amBrain の働き方には三つの形態がある。フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニアだ。顧客は、プロダクトとコードの完全な所有権を保持する。ただし、amBrain の再利用可能なコンポーネントは除く。

本稿はアグリゲーション層の仕組みを説明するものであり、事例紹介ではない。どの顧客の名前も挙げない。

だから最初の判断は、どのプロバイダーと契約するかではない。それは、すべてのプロバイダーを適合させることになる内部契約であり、最初のアダプタが存在する前に、そのエラーケースとともに書き留められたものである。