モンスターストライクシステムオーバービュー

※こちらの記事は過去のブログから転載したものです。

f:id:mixi_PR:20210202200203j:plain

こんにちは。XFLAG™スタジオの青山です。XFLAG™ スタジオの開発者ブログ一本めということで、モンスターストライクのシステムについてざっくりと書いてみます。細かなところはそのうち別の人が書いてくれると思いますっ。

スマートフォンゲームであるモンスターストライクは、スマートフォンアプリとして動作する"クライアント"と、ゲームのパラメーターや進行状況などの重要なデータを管理する"APIサーバー"、最大４人のマルチプレイにかかるリアルタイムなデータ通信を中継する"TURNサーバー"の、大まかに３つの要素で構成される情報処理システムです。

ほかにもサーバーやネットワークの監視系システムや、解析系システム、カスタマーサポート系システムなどなど、"ゲーム事業"を滞りなく遂行するための様々なサブシステムを内包しています。

今回は主要３要素のうち、スマートフォンアプリからは見えないAPIサーバーとTURNサーバーを簡単に取り上げます。

APIサーバー

APIサーバーはゲーム進行に必要な情報をクライアントに提供・管理するWebアプリケーションサーバーです。

f:id:mixi_PR:20210202200305j:plain

A10のロードバランサー配下に約300台超のLinuxサーバーを配置してクライアントと通信しています。APIサーバーは一般的な基盤ソフトウェアを土台として、XFLAG™ スタジオが開発しているサーバーアプリケーションを実行しています。

APIサーバーのロジックはRubyで記述しています。Web Application FrameworkはPadrinoを使用し、RDBMSの操作にはActiveRecordを使用します。

永続化が必要な情報はMariaDBで管理します。MariaDBはActive-Standbyのペアを基本として、要求の増大に対してはまずはクエリ改善をしたり、頻繁に参照される同じデータについてはmemcachedに保存したりしています。必要に応じてスケールアップをしたりテーブルセットごとに別のActive-Standbyペアに分割したり、さらに要求の高いテーブルについてはシャーディングして対応しています。なんやかんやでMariaDBのサーバーは200台以上動いています。

頻繁に使用するホットデータはmemcachedで保持します。memcachedは2つのキャッシュプールを同時更新することで、データ構造を変更する際にもスムーズな移行とパフォーマンス低下を防いでいます。

処理時間の大きく遅延しても問題のない処理は、Resqueのジョブキューに投入して複数のワーカーノードで分散しつつ非同期処理します。

ちなみにモンスターストライクのシステムは複数のデータセンターにサーバーを配置しています。

仮にデータセンターがまるごと1つ停止して長時間利用できない状況となったとしても、残ったデータセンターに切り替えることでゲームを提供し続けられる構成をとっています。

TURNサーバー

スマートフォンは携帯電話キャリアや家庭のWi-Fiなど様々なネットワークから利用されます。ほとんどの場合ネットワークのレイアウトによる制約からクライアントどうしは直接通信できませんが、インターネット上に配したTURNサーバーが仲介することで仮想的なpeer-to-peer通信を実現しています。

f:id:mixi_PR:20210202200619j:plain

モンスターストライクのTURNサーバーはTURN - Traversal Using Relays around NAT プロトコルを実装したオープンソースソフトウェアをベースに、大規模なマルチプレイ環境の安定提供に必要な様々な改良を加えて利用しています。

TURNサーバーは一台あたりピーク時で約30,000セッションを同時に処理するよう調整しています。ちなみにTURNサーバーはゲームの"状態"を保持しない単純なTCPリレー装置として振舞うので計算機資源への要求は少なく、大量のセッションを同時に扱うことができます。もちろん全てのマルチプレイセッションを1台でまかなうのは不可能なので、複数のTURNサーバーをクラウド上に並列配置しています。

とりあえずモンスターストライクのサーバサイドのシステムのサワリとしてはこの辺になります。引き続きモンスターストライクをはじめとしたXFLAG™ スタジオで扱う技術要素や、スタッフの愚痴が少しずつ書かかれていくと思いますので、以後お付き合いのほどよろしくお願いします。