モバイルゲームのインフラアーキテクチャ特集 - 技術選定のポイントと今後の展望

グリー株式会社

アーキテクチャ選択の背景や意図

ゲームサービスのクラウドアーキテクチャとして重要な点は、急激な高負荷に対してスケールできることと、サービスのメンテナンス時間を不要にできることの2点でした。そのため、Google Kubernetes EngineとCloud Spannerを主軸に置いた構成となっています。特に、書き込み・読み込みの性能のスケールができ、クラウド側都合によるメンテナンスが不要な構成を取っています。
また、他のクラウド環境などでも利用する機能は外部SaaSを活用しており、Grafana CloudおよびDatadog APMを活用して日々のモニタリング・トラブルシュートを行っています。

現在の課題と今後の改善予定

スケール性能や費用の面で改善を検討しています。GKEでカスタム コンピューティング クラスを利用し、複数のインスタンスタイプを利用しながらSpotインスタンスを活用していく予定です。また、スケール性能をより高めるために、GKEのイメージ ストリーミングも検討していますが、ゲーム特有の必要なマスタデータなどが多くうまく活用できない課題があり、今後引き続き試行錯誤する予定です。
また、ゲームタイトルごとに独立したシステムになっていますが、TerraformやKubernetes マニフェストといった各コンポーネントの再利用性を高める方法を模索しています。

◆執筆：後藤 浩行
グリー株式会社 開発本部 インフラストラクチャ部 サービスエンジニアリンググループ シニアマネージャー

【公式サイト】
https://corp.gree.net/jp/ja/

【グリー株式会社のエンジニア求人】
https://corp.gree.net/jp/ja/recruit/
※グリー株式会社の公式採用サイトに飛びます

株式会社gumi

アーキテクチャ選択の背景や意図

おもしろさの追求に開発チームが集中するためにはどうすればよいか、という観点から設計しています。
認証や課金といった機能は重要ですが、おもしろさの向上には寄与しない上に継続的な開発が必要です。
そのため全ゲーム共通のマイクロサービス群（図右側の Nativebase、20個以上）として提供しています

各ゲームのAPIサーバーの前段に、全通信をプロキシする自社開発のミドルウェア(GHR)を配置し、認証/セッション管理/課金等をマイクロサービスと連携して処理しています。
これにより、APIサーバーは前処理済みのデータを受け取るだけで済み、ほとんどのゲームのAPIサーバーではプラットフォーム依存の実装が不要な仕組みを実現しています。

これらのマイクロサービスは多くのゲームで共通利用されているため、停止を伴うメンテナンスは行わない他、障害時も影響を局所化しサービス停止を回避するようにしています。
ストレージにはDynamoDBを採用し、プラットフォーム依存部分は分離されているため、デプロイの影響範囲も最小限に抑えられています。

現在のアーキテクチャの課題と今後の改善予定

メンテナンス性、安定性、パフォーマンス、コスト効率は常に追求しています。

現在、ゲーム、マイクロサービス双方でコンテナ化を進めており、ゲームでは各種プログラミング言語への対応速度や開発チームの自由度向上を、マイクロサービスでは独立性を維持しつつリソースの利用率を改善しコストパフォーマンス向上を狙っています。

また、ほぼ全ての要素はコード化されており、新しいゲームや開発環境の追加にも迅速に対応可能となっています。
しかし、開発環境の追加や削除にインフラチームの関与が必要な状況です。これを解消し、開発チームが環境の追加や削除を簡単に行えるような仕組みの構築を目指しています。

他には可観測性を向上させるため、より統合して各種トレース・ログ・メトリクスを集約・閲覧できるような取り組みもしていきたいと思っています。

◆執筆：清水 佑吾　株式会社gumi　CTO

【公式サイト】
https://gu3.co.jp/

【株式会社gumiのエンジニア求人】
https://gu3.co.jp/recruit/
※株式会社gumiの公式採用サイトに飛びます

KLab株式会社

アーキテクチャ選択の背景や意図

KLabにはオンプレミス環境のDSASとクラウド上のKLAWSという基盤システムがありますが、現行システムの運用性を維持したまま、新しい技術を導入することは難しくなっていました。そこで、新しいAPI基盤としてコンテナ技術を活かしたクラウドネイティブなシステムを構築しました。

新しいAPI基盤ではオーケストレータにEKS(Kubernetes)を利用しています。サーバーアプリケーションのデプロイ・コントローラーにJenkinsとArgo CDを使ってGitops運用を実現しています。Kubernetesには多くの優れたツールが存在するため、独自の作り込みをすることなく構築できたのはたいへんありがたかったです。

APIサーバーはFlask+Pythonで実装しています。クライアント側のゲームエンジンはUnityを採用し、C#で実装しています。特徴的な点として、クライアントサーバ間のAPI送受信および双方のモデルクラスをバックエンド開発者がC#/Pythonで実装しています。これにより、通信処理の最適化による品質の向上と、クライアント開発者とバックエンド開発者のコミュニケーションコストの削減による開発効率の向上を図っています。

また、APIサーバーとは別に、オンライン対戦のゲームロジックをサーバーサイドで.NET環境下で動作させています。クライアントと共通のC#で実装されているため、開発効率の向上と一貫性のあるゲーム挙動が実現されています。

APIサーバーのオートスケール・オートヒーリングといった可用性の維持がKubernetesに任せられるようになったのは大きなメリットです。モニタリングにはDatadogを利用しています。ネットワークからサーバーアプリケーションまでDatadogでカバーできるため、状況の変化やエラーが起きたときの原因を見つけやすくなりました。

現在のアーキテクチャの課題と今後の改善予定

Kubernetesを採用した以上、ライフサイクルに追随してEKSクラスタのバージョンアップをしなければなりません。AWS Load Balancer Controller、External Secrets Operator、ArgoCD、Argo Rolloutsといったアドオンもアップデートする必要があります。バージョンアップにかかる手間と時間は運用の負担になります。クラスタを更新するタイミングで、問題がある部分をより良い形で置き換えやすいというメリットはありますが、追随に関わるコストに関しては、これが不要となるECSのほうが分があり、ECSをつかったシステムも検討しています。

◆執筆：米田 真治 (こめだ しんじ)
エンジニアリング本部 ゲームコアテクノロジーグループ @komeda_shinji

【公式サイト】
https://www.klab.com/jp/

【ＫＬａｂ株式会社のエンジニア求人】
【開発】新規ゲーム 開発リーダー 等
https://www.klab.com/jp/recruit/
※ＫＬａｂ株式会社の公式採用サイトに飛びます

株式会社コロプラ - フェスティバトル

アーキテクチャ選択の背景や意図

コロプラではGKE上にAPIサーバー、バックエンドにCloud Spannerを利用している点が特徴的ではあるものの、構成は一般的なWebサービスと大きな差はありません。
ゲーム特有のアーキテクチャとして特徴的なのは、専用ゲームサーバーのオーケストレーションにAgonesを利用していることです。
Agonesを利用して専用ゲームサーバーを割り当てる際、コロプラでは前段にその割り当て先を決めるAllocator Service（図のAgones Allocatorの部分）を独自で開発しています。
この独自開発したAllocator Serviceのメンテナンスコストを減らす、最終的にはコンポーネント自体をなくすことは、複数のゲームタイトルを同時に開発・運用するコロプラにとって課題の一つです。

この独自のAllocator Serviceを開発している理由の一つに、Agonesでは一度割り当てた専用ゲームサーバーを再割り当てする方法がなかったことが挙げられます。 コロプラでは数人単位でグループを作るゲーム（MO形式）が多いため、コロプラの専用ゲームサーバーではルームと呼ばれるグループにマッチしたユーザー同士を詰め込むことで、ユーザー間の通信ができるようになっています。
ルームは1つの専用ゲームサーバー内に複数作ることができるため、1プロセスでより多くのユーザー通信を処理することができ、効率的にサーバーリソースを利用できるというメリットがあります。
しかしながら、このルームという概念を実現するためにはすでに割り当ての完了している専用ゲームサーバーを再割り当てする必要があります。
今回フェスティバトルではこの専用ゲームサーバーを再割り当てする仕組みをHigh Density GameServerパターンを導入することで実現し、よりAgones標準のAllocator Serviceに近づけることで移行しやすくしています。

現在のアーキテクチャの課題と今後の改善予定

Agonesでは現在、よりコロプラのユースケースに沿った形で専用ゲームサーバーのオーケストレーションを実現できるCountersAndLists機能が開発中です。
CountersAndListsは自分たちで用意した値（例えばルームIDのようなもの）をGameServerリソースに保持することで、専用ゲームサーバーの割り当てにその値を利用したり、オートスケールのしきい値として利用することができる機能です。
今後はこの機能を利用して独自のAllocator ServiceをAgones標準のものへ移行できないか検討していきます。

◆執筆：加藤 悠　
株式会社コロプラ 技術基盤本部 インフラストラクチャ部 第2グループ @katsew

【フェスティバトル公式サイト】
https://festibattle.jp/

【株式会社コロプラのエンジニア求人】
【GCP】国内外に提供している人気ゲーム開発｜大規模トラフィックに耐えうるインフラ環境の設計～運用を担当するインフラエンジニアを募集！ 等
https://findy-code.io/companies/437/jobs

株式会社MIXI - モンスターストライク

アーキテクチャ選択の背景や意図

モンスターストライクではイベント開始時にトラフィックが一瞬で何十倍にも急増します。こうした国内最大規模のユーザを支えるために、オンプレミスとクラウドを組み合わせたハイブリッドクラウドで運用されています。
AWSおよびGoogle Cloudのそれぞれをデータセンタ内のネットワークと接続し、オンプレミスによる高性能・低レイテンシと、クラウドのマネージドサービスによる高スケーラビリティ・低運用負荷の両立を目指しています。
また各種運用作業や、管理画面の閲覧等を安全に行えるよう、内製のゼロトラストプロキシが活用されていることが特徴です。CI/CDでは、以前はJenkinsがメインで利用されていましたが、近年GitHub Actionsへの移行が進み、一部GitHub Actionsでは利用できないリソースを要求するものに関してもJenkinsのAgentを自動的にスケールするツールが内製されるなど、コスト最適で柔軟なCI/CD環境となっています。構成管理の一部にTerraform Cloudが導入され、GitHub Actionsおよび各クラウドとのOIDC連携によって様々な設定のIaCが実現しています。

現在のアーキテクチャの課題と今後の改善予定

2013年のリリースから運用され続けていることで、ある程度安定した「枯れた」アーキテクチャとなっていますが、古いコードベースやミドルウェア、また運用負荷が依然として高い部分も多数存在します。これらの課題点をクリアし、これからもモンストを通して「心もつながる」場と機会を創造し続けるべく、シンプルで効率的、また今後のビジネス環境の変化に対応できるシステムを目指しています。具体的には、コードのリファクタリングやミドルウェア等の更新はもちろんのこと、新たに登場したマネージドサービスの活用など、多岐にわたるチャレンジを続けていく予定です。

◆執筆：影山　勇太
株式会社MIXI　デジタルエンターテインメントオペレーションズ本部　モンスト開発部　モンストサーバ2グループリーダー

【モンスターストライク公式サイト】
https://www.monster-strike.com/

【株式会社MIXIのエンジニア求人】
【MIXI】CTO直下の組織で各プロダクトのパフォーマンスを改善するSREを募集 等
https://findy-code.io/companies/247/jobs