Diarkis MatchMaker はこれまでのマッチングの仕組みと概念が大きく違います。 ここではその概念を説明します。
従来のマッチメイキングの仕組みについて
例えばこれまでのデータベースを使ったマッチングでは、定期的にバックグラウンドプロセスが動きデータベースにあるユーザーをマッチさせて新しいデータセットを作り、ユーザークライアントはそれを参照するような作りの場合はデータベースに保持されているため検索結果は、次の集計プロセスが処理を終えるまで変わりません。
Diarkis MatchMaker の仕組みについて
Diarkis MatchMaker ではサーバクラスタにある複数のサーバにデータを分散させて保持をします。従来のようにサーバごとに分かれたマッチングやデータベースを外部に持つような方式とは違い、大規模でありながら検索速度やリアルタイム性を重視した設計を採用しています。
これはスケールとパフォーマンスを優先するために採用した設計なのですが、データを分散しているために検索の結果が検索の度に変わる可能性があります。
検索追加「Add」について
まず検索の対象にするために「Add」追加というステップを踏みます。Diarkis MatchMaker が用意しているこの追加を使うことで検索の対象になることができます。ここでの注意点は検索の対象になる時間に期限がついている部分です。「Add」は最大 60 間の間検索の対象として追加されるのですが、60秒以上検索の対象に留めておきたい場合は再度「Add」を使って追加する必要があります。
検索「Search」について
実際にマッチを検索するステップです。検索では Diarkis MatchMaker に対して任意の条件にマッチしたものを N 件検索するという指示を実行してその結果を取得するという機能です。この検索だけを使う場合は排他処理などは含まれていません。これはデータが分散しているという設計によるものです。ここでいう排他の例としては、検索の結果が他の検索の結果と重複してしまう場合や、すでに先着があるものが結果に含まれる場合を指します。
Diarkis Room を併用したマッチングについて
検索の際に説明があった排他処理がないという注意点について Diarkis Room を一緒に使うことで排他処理を加えることが可能になります。考え方としては、条件に合うユーザーを検索するのではなく、条件に合うユーザーが参加しているルームを検索するという考え方になります。ルームは同時に複数のルームに参加することができません。このため同じユーザーが重複して検索されたとしてもルームを使うことでブロックすることができます。同様にルームには人数声芸限があるため、人数制限を超えた人数が参加することを防ぐことができます。ルームを一緒に使うことでのもう一つの利点としては、マッチング途中の間でもすでにマッチして同じルームに参加しているユーザー同士で同期をすることができるため、例えば待受中にユーザーのステートが変わったことなどを他のユーザーに通知することが可能になります。
Diarkis MatchMaker Ticket を使ったマッチングについて
Diarkis MatchMaker では、「Add」や「Search」以外にも排他処理などを備えたマッチメイキングの仕組みを用意しています。
MatchMaker Ticket を使うことで、マッチメイキングのロジックをサーバで管理、制御するだけでなくユーザー同士の排他処理を自動で管理し、クライアント側からはシンプルにマッチメイキングのチケットの発行とその結果のイベント処理を行うだけの簡単な実装だけで、多様な種類のマッチメイキングを実装することが可能です。
MatchMaker Ticket のユーザー排他処理では、同一のユーザーが重複してマッチされることを防ぐだけでなく別の種類の「Ticket」を発行することで、複数のマッチメイキングに参加することができるようになります。
このほかにも、Diarkis Room を併用した場合と同様に MatchMaker Ticket を使うとマッチしたユーザー同士でデータを送受信することが可能になるだけでなく「Ticket」毎にアプリケーションのデータを引き渡すことで、アプリケーションのデータをユーザー間で共有することも可能になります。