全世界リリースを支えるマルチプレイゲームの裏側【CAGC2024】※2025年3月6日までの公開

アプリボットで全世界リリースしたゲームプロダクトにおいて、マルチプレイは多くの技術的挑戦を含んでいました。
本セッションでは、マルチプレイを開発・運用する上で立ち塞がった3つの壁と、その壁を乗り越えるために使った技術や戦術としてサーバーサイドC#、MagicOnion、Amazon GameLiftについて解説します。

https://cagc.cyberagent.co.jp/2024/session/index.html?id=N7z2nimH

© SQUARE ENIX Powered by Applibot, Inc.　CHARACTER DESIGN: TETSUYA NOMURA / CHARACTER ILLUSTRATION: LISA FUJISE
Copyright © CyberAgent, Inc.

Transcript

1. 全世界リリースを支える マルチプレイゲームの裏側 1 SRE 長谷部　充洋　Hasebe Mitsuhiro
2. マルチプレイの要件 2
3. マルチプレイの要件 3 協力型 - 3人のプレイヤーが協力して共通の敵と戦う リアルタイムコマンドバトル - ターン制ではない - 格闘ゲームほどシビアではないが、 他プレイヤーのコマンドがリアルタイムに反映される リアルタイムな通信の開発は弊社に前例がない → 難易度が高い開発になることが予想された
4. 技術選定 4
5. 技術選定 : 経緯 5 最終的にはAmazon GameLift(後述)とC#サーバを採用することになるが、 当初はサーバレスのリアルタイム通信サービスで開発を進めていた → 1人のクライアントがホストになる設計のため問題が発生した 当初使用していたサービスの問題点 - ホストプレイヤーによるチートを防ぐ手段がない - ホストプレイヤーの通信状態が全員に影響する
6. 技術選定 : 経緯 6 問題を解決するため、サーバ上でバトルロジックを動作させ、 リアルタイムに通信を行う別の技術を採用した 実現可能になること - プレイヤーによるチートを防ぐことができる - プレイヤーの通信状態が他プレイヤーに影響しにくくなる 追加要件 再実装のコストを削減するためC#を採用する
7. 技術選定 : C#サーバ 7 リアルタイム通信サーバは C# / .NET で開発することにした
8. 技術選定 : C#サーバ 8 バトル … アウトゲーム … マルチ基盤 … クライアントはUnity、サーバは.NETで開発し、バトルロジックを C#のコードレベルで共有することで開発コストを削減
9. 技術選定 : Amazon GameLift 9 サーバ管理サービスとして Amazon GameLift を採用 ※Amazon GameLift : AWSのマルチプレイ用サーバ管理サービス
10. 技術選定 : Amazon GameLift 10 既に他のサーバやデータベースはAWSで構築していたため、 同じAWSのサービスである GameLift を採用することで 他のリソースと連携しやすいメリットが期待できる C#でリアルタイム通信サーバを実装し、 GameLift管理下に構築することにした
11. 技術選定 : 最終的な構成図 (関連部分のみ抜き出し) 11 ECS Cluster GameLift FleetIQ ECS Cluster GameLift GSG Auto Scaling Group API server realtime server GameLift FlexMatch SNS DynamoDB Lambda ALB Auto Scaling Group game play Cloud Front
12. 技術選定 : 最終的な構成図 (関連部分のみ抜き出し) 12 ECS Cluster GameLift FleetIQ ECS Cluster GameLift GSG Auto Scaling Group API server realtime server GameLift FlexMatch SNS DynamoDB Lambda ALB Auto Scaling Group game play Cloud Front
13. 技術選定 : 最終的な構成図 (関連部分のみ抜き出し) 13 ECS Cluster GameLift FleetIQ ECS Cluster GameLift GSG Auto Scaling Group API server realtime server GameLift FlexMatch SNS DynamoDB Lambda ALB Auto Scaling Group game play Cloud Front
14. 技術選定 : 最終的な構成図 (関連部分のみ抜き出し) 14 ECS Cluster GameLift FleetIQ ECS Cluster GameLift GSG Auto Scaling Group API server realtime server GameLift FlexMatch SNS DynamoDB Lambda ALB Auto Scaling Group game play 通常のAPI通信 リアルタイム通信 (MagicOnion) Cloud Front
15. 技術選定 : 最終的な構成図 (関連部分のみ抜き出し) 15 ECS Cluster ECS Cluster GameLift GSG Auto Scaling Group API server realtime server Auto Scaling Group DB ステートフルであり、 バトル中にDBアクセスしない
16. 未経験開発の壁 16
17. 未経験開発の壁 17 - 技術選定は終わったが、マルチプレイの開発にあたっては 弊社に前例がない開発が多く、いくつもの”壁”があった - “壁”を乗り越えるために使った技術・戦術を紹介する
18. 未経験開発の壁 18 壁1 : C#サーバの開発 - バトルを再実装するコストを抑えるために C#でサーバ開発することにしたが、弊社に前例がなかった
19. 未経験開発の壁 19 壁1 : C#サーバの開発 - バトルを再実装するコストを抑えるために C#でサーバ開発することにしたが、弊社に前例がなかった なぜ必要か？ - バトルにはソロプレイとマルチプレイがあり、ソロはアプリ上で、 マルチはサーバでロジックが動作する - 既にソロプレイ開発はかなり進行していた - 大規模なチームで開発する都合上、同じものを 二重に開発するコストは許容できない → バトルロジックは共有する必要があり、C#サーバは避けて通れない
20. 未経験開発の壁 20 壁1 : C#サーバの開発 - バトルを再実装するコストを抑えるために C#でサーバ開発することにしたが、弊社に前例がなかった 解決策1 : クライアント・経験者・SREを中心に専任チームを結成 - バトルに詳しいクライアントエンジニア - C#サーバ開発経験があるサーバエンジニア - AWS上の構築を担うインフラエンジニア
21. 未経験開発の壁 21 壁2 : リアルタイム通信の開発 - C#サーバと同様に弊社に前例がなかった なぜ必要か？ - リアルタイムであることが要件に含まれており、 REST API のポーリングではレイテンシ的に実現できなかった
22. 未経験開発の壁 22 壁2 : リアルタイム通信の開発 - C#サーバと同様に弊社に前例がなかった 解決策2 : Cysharpサポートのもと、MagicOnionを採用 - サイバーエージェントグループの Cysharp が開発したライブラリ MagicOnion を採用 - Cysharp と隔週でミーティングを行い、MagicOnion を使った開発を 直々にサポートしてもらう ↓ - 大きなハードルとなる通信基盤の開発コストを大幅に抑えられた
23. 未経験開発の壁 23 MagicOgion とは？ - サイバーエージェントグループの Cysharp が開発したgRPCベースの 通信ライブラリ - 従来のgRPCでは難しかった複雑なリアルタイム通信が可能 - サーバーとクライアントがお互いの関数を呼び出しているかのように 記述できるため非常に分かりやすい
24. 未経験開発の壁 24 壁3 : ステートフルサーバーの構築・運用 - 弊社に前例がなかった なぜ必要か？ - リアルタイムであることが要件に含まれており、DB通信による レイテンシ増加は許容できない - 既に開発が進んでいたソロプレイのバトルロジックはデータが インメモリで管理されている前提だった
25. 未経験開発の壁 25 壁3 : ステートフルサーバーの構築・運用 - 弊社に前例がなかった なぜ壁になったか？ インフラ側の構築・運用が壁になった - 通信サーバがバトルの状態を持つため、他サーバにアクセスしても 情報を取得できない - バトル中はクライアントがアクセスするサーバを固定する必要がある - 同じバトルに参加するユーザは同じサーバにアクセスする必要がある → 従来のAPIサーバのような単純なロードバランサが使えない
26. 未経験開発の壁 26 壁3 : ステートフルサーバーの構築・運用 - 弊社に前例がなかった なぜ壁になったか？ インフラ側の構築・運用が壁になった - 通信サーバがバトルの状態を持つため、他サーバにアクセスしても 情報を取得できない - バトルが進行中のサーバを停止してはいけない → 従来のAPIサーバのように単純にスケーリングできない
27. 未経験開発の壁 27 壁3 : ステートフルサーバーの構築・運用 - 弊社に前例がなかった 解決策3 : AWSサポートのもと、GameLiftを採用 - サーバのスケーリングやバランシングに相当する部分に GameLift FleetIQ を使い、構築コストを削減
28. 未経験開発の壁 28 従来のロードバランサ サーバの負荷が均一になるように、リクエストごとに振り分けられる server1 server2 client1 client2 load balancer server3 client3
29. 未経験開発の壁 29 従来のロードバランサ ステートフルサーバで同じことをしようとすると、データを持っている サーバ以外に振り分けられることがあるため成立しない server1 server2 client1 client2 load balancer server3 client3
30. 未経験開発の壁 30 GameLift FleetIQを採用した構成 クライアントが直接物理サーバにアクセスする構成で、 GameLift FleetIQが両者を仲介する server1 server2 client1 client2 server3 client3 GameLift FleetIQ
31. 未経験開発の壁 31 GameLift FleetIQ 詳細は弊社記事「Amazon GameLift を導入してみた話」を参照 未使用 使用中 server1 未使用 使用中 使用中 server2 未使用 client1 client2 client3 ※図は概念的なものであり、実際のリソース構成とは異なります FleetIQ 確保 URLを返却
32. 未経験開発の壁 32 GameLift FleetIQ 詳細は弊社記事「Amazon GameLift を導入してみた話」を参照 未使用 使用中 server1 未使用 使用中 使用中 server2 使用中 client1 client2 client3 ※図は概念的なものであり、実際のリソース構成とは異なります FleetIQ 接続
33. まとめ 33
34. まとめ 未経験からのC#サーバ開発 　→ 経験者・適任者を集めた専任チームを結成 未経験からのリアルタイム通信開発 　→ Cysharp の力を借りて MagicOnion を採用 未経験からのステートフルサーバ運用・構築 　→ AWS サポートの力を借りて Amazon GameLift を採用 34