[スマホゲーム]ゴーストスクランブルの裏側を支える技術
こんにちは。ミクシィの 開発本部 SREグループ のriddle です。
弊社では2022年7月にゴーストスクランブル（通称ストブル）というスマホゲームをリリースしました。
ストブルはマルチプレイゲームとボイスチャット機能を搭載しており、最大4人でマルチプレイができるアクションゲームです。
この記事ではスマホゲームに求められる要件を説明しながら、
ストブルのバックエンド・インフラ構成もあわせて紹介します。
−−−−−−−−−−−−−−−−−−−−−−−−−
＜目次＞
- システムの全体像
1.1gRPC でのリクエスト/レスポンス
1.2マルチプレイゲーム
1.3ボイスチャット
1.4通知 - ゲームの基盤の特性について
2.1スケーラビリティ
2.2セキュリティ
2.3KPI 測定のためのログ収集
2.4まとめ - さいごに
−−−−−−−−−−−−−−−−−−−−−−−−−
システムの全体像
ストブルのバックエンドでは以下の機能を提供しています。
- gRPC でのリクエスト/レスポンス
(アイテム増減、スタミナ回復、ガチャを引くなど) - マルチプレイゲーム
- ボイスチャット
- 通知
gRPC でのリクエスト/レスポンス
ゲームアカウントを登録したり、ガチャをひいたり、アイテムを購入したりなど、ゲームのうち永続性と一貫性を持たせたい操作を提供します。
一般的に API サーバと呼ばれますが、ストブルでは gRPC を利用しているので gRPC サーバと呼んでいます。
gRPC をゲームで使うのはチャレンジングな試みでしたが、Protocol Buffers の使い勝手がいい感じです。 またシリアライズによってデータサイズが小さくなるので、ユーザの通信量が小さくなるのもうれしいですね。
※HTTP/2ベースで動くので End-to-Endで TLS 必須なところが開発時に厄介ですが（ローカル開発するときは流石にinsecure にはしますが）
また永続データはSpanner に、
一時データはMemory Store for Redis に格納しています。
マルチプレイゲーム
ストブルは4人で同時に遊べる マルチプレイを売りにしています。 マルチプレイではサーバとの通信ではなく、ユーザ同士がパケットを交換して通信をするので専用のサーバが必要です。
モンストではTURN サーバを利用していましたが、ストブルではプロトタイプ開発の容易さからモノビット社のMonobit Unity Networking 2.0 (MUN) を利用しています。
MUN はホストOSにインストールする製品のため、
コンテナではなくCompute Engine で動かしています。
ボイスチャット
よりマルチゲームを楽しんでもらうため、ストブルではボイスチャットを用意しています。 こちらは弊社のスーパーエンジニアがGKE +Agones で動くボイスチャットアプリを作ってくれました！
ボイスチャットの詳しい構成や挙動は別の機会に紹介したいと思います。
通知
フレンドにマルチプレイゲームの招待をする際に使う機能です。
弊社で通知を実装する際は、リアルタイム通信もできるWeb Socketサーバや通知専用のNATS サーバを自前で建てていたのですが、今回は通知に特化したサービスがあればよかったのでFirebase Cloud Messaging(FCM) を採用しています。
クライアントAがマルチプレイ用のルームを立てフレンドを招待すると
- クライアントA
- gRPC サーバ
- Firebase Cloud Messaging(FCM)
- クライアントB(フレンド)
という流れで通知が飛びます。
ゲームの基盤の特性について
続いてゲームの基盤に求められる特性（いわゆる非機能）を紹介します。
スケーラビリティ
Web サービスと異なり、
ゲームの基盤は時間ごとのトラフィックの増減が非常に激しいです。
たとえば、リリース直後は大量のアクセスがありますが、その後はアクセス数がガクンと落ちます。 またイベントやキャンペーンといった販促活動を行うと大量のトラフィックが飛んでくることもあります。
そのためユーザ体験を損なわないように、スマホゲームにはスケーラブルなゲーム基盤が必須です。さらにアクセスが減った時は、コストを抑えるため簡単にスケールインできる必要もあります。
サーバなどのコンピュートリソースはコンテナの登場で増減が容易になりましたが、データベースはスケールインが難しいことが多いです。
そのため我々も使っているCloud Spannerはボタンぽちぽちでスケールイン・アウトができるのでゲーム業界では支持を集めているようです。
セキュリティ
ゲームでは bot や 不正ユーザからのアクセスや攻撃が多くとんでくるので、相応のセキュリティ対策が求められます。
実際ストブルもリリース直後に海外からの大量アクセスがとんできたので、Cloud Armor をつかって弾きました。
ただチートやセキュリティ対策の多くはユーザが直接ダウンロードするクライアント側での対策が必要です。（この動画がとてもわかりやすい）
KPI 測定のためのログ収集
「ゲームをどのように改善・更新していくか？」 を判断するため、
- ユーザがどのクエストを遊んだのか？
- ユーザが所持しているアイテムは何か？
など、遊んでいただいたユーザのログを出力し、
自前のデータ基盤にためて、ゲームの継続率やミッション達成率など必要な項目を設定して KPI 分析を行なっています。ストブルではBigQuery +Looker で分析しています。
まとめ
基盤やバックエンドを設計・構築する際には「ゲームの機能を提供する」以外にもこれらの非機能要件も考えています。
- トラフィックの増減に応じてリソースを変動できる
- リソースが変動してもレイテンシーを維持する
- ユーザの不利益にならないようにセキュリティを高める
- 改善のための KPI 測定用のデータレイクの用意と分析
これらを満たすため、
ストブルでは以下の構成でサービス提供を行なっています。
参考までに使用している言語やツールも紹介します。
- 言語: Go (ボイスチャットで Elixir / Rust、管理ツールで Ruby）
- ビルド: Bazel
- サーバ：GKE / Google Compute Engine
- DB：Spanner / SQLite
- キャッシュ：MemoryStore for Redis
- マルチプレイ：MUN
- ボイスチャット：GKE / Agones
- CDN：Cloud CDN
- IaC: Terraform / Ansible
- CI : Cloud Build / GitHub Actions
- 通知：Firebase Cloud Messaging (FCM)
- 解析：DataFlow / PubSub / Google Cloud Storage / BigQuery / Looker
- 監視：Prometheus / Cloud Monitoring / PagerDuty / Bugsnag
さいごに
今回はざっくりストブルのバックエンド〜インフラで利用している技術を紹介しました。 個別の話や、リリースまでに色々と苦労したことについては別に記事にしようと思いますので、またよろしくお願いします！
ゲームも配信中なので、よかったら遊んでみてください！
