マッチングでRabbitMQを使おうと思っている件

はじめに

 

こんにちは!
サムザップでサーバエンジニアをしている北島です。
月曜日に夜更かしして書いていたら、こんなタイトルになりました (`・ω・´)キリッ

 

弊社の若手エンジニアでブログを始めることになりました。
サムザップの技術事情や、エンジニアの働く環境などをお伝えしていければと思っていますので、よろしくお願いします!
現在、私は、担当しているあるゲームアプリの課題を解決するために、RabbitMQの導入を検討しています。
初回である今回は、それについて書いていこうと思います。

 

マッチングで一部serverが遅くなってしまう問題

 

私の担当しているゲームアプリには、決まった時間にGvGがあります。
そして、GvGの始まる1時間前に対戦相手を決めるマッチングを行っています。

 

マッチング

 

マッチングでは、上の例のように、各ギルドに所属しているユーザの強さやGvGに持っていくスキルなどのデータを作成します。
そして、それらのデータができたところで、同じくらいの強さの相手になるよう対戦相手を決める処理を行います。

 

しかし、各batch_serverで行っているデータの作成処理は、ギルドに所属している人数がばらばらだったり、そもそも誰も所属していないギルドがあったりで、処理が終わる時間に差が出ます(誰も所属していないギルドは省くとしても、ユーザは常にギルドの移動を行う為、どうしてもbatch_serverごとに差が出てしまいます)。

 

よって、batch_server1は処理が終わっているのに、batch_server2の処理が終わっていないため対戦相手を決定する処理に移れず、batch_server2の処理が終わるのを待つという無駄が発生します。

 

これが、今回の課題になります。
マッチングは、GvGが始まるまでには終了していなければならない訳ですが、テレビCMを流した際や、ゲーム内でイベントを実施した際など、大量にユーザが増えるタイミングでは、guild_idが大きい値の連合にユーザが集まることが多く、そのギルドのデータを作成しているbatch_serverだけ処理が終わらないということが発生します。

 

RabbitMQの導入を検討

 

この問題に対し、弊社では、RabbitMQの導入を検討しています。

RabbitMQは、オープンソースのメッセージキューです。

 

RabbitMQを使ったマッチング

 

予め、guild_idを細かく分け、メッセージとしてsetしておきます。
各batch_serverは、並列で先頭からメッセージをgetし、メッセージにある範囲のデータを作成します。
そして、データの作成が終わり次第、次のメッセージをgetし、次のデータを作成するといった流れです。
これにより、各batch_serverは、処理が終わり次第、順次、次のデータを作成するため、各batch_serverが他のbatch_serverを待つということがほぼ起きなくなり、batch_serverごとの処理が均等化されます。

 

また、RabbitMQには、ackとnackというものが用意されています。
メッセージを受け取り適切に処理が完了した場合には、ackを返すことでRabbitMQにこのメッセージは適切に処理されたということを知らせることができます。また、途中で処理が失敗した場合は、nackを返すことでメッセージをキューに残しておくことができます。これにより、失敗したメッセージは、再度、受け取ることができ、処理をやり直すことが可能です。

 

まとめ

 

今回の課題は、リリースしてから数年がたったゲームアプリのものなのですが、サムザップでは、長年運営しているゲームアプリに対しても、今まで使っていなかった技術を導入するような挑戦的な課題解決に取り組める環境があります。
興味のある方は、ぜひ遊びに来てみて下さい!

 

実際にRabbitMQを導入して結果が出た際には、またブログにて報告しようと思います。
次回は、また別の若手エンジニアが記事を書きますのでお楽しみに!

 

株式会社Sumzap 採用情報

  • このエントリーをはてなブックマークに追加