Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

大規模トラフィックを支える ゲームバックエンドの課題と構成の変遷 ~安定したゲーム体験を実現す...

COLOPL Inc.
November 28, 2024

大規模トラフィックを支える ゲームバックエンドの課題と構成の変遷 ~安定したゲーム体験を実現するために~

COLOPL Inc.

November 28, 2024
Tweet

More Decks by COLOPL Inc.

Other Decks in Technology

Transcript

  1. スマートフォンゲームとは スマホやタブレットなどのモバイル端末上で動作するゲーム ▶ 特徴 ► 高い携帯性 ► いつでもどこでも手軽にプレイ可能 ► ソーシャル要素

    ► 他のプレイヤーとの協力、対戦、交流が可能 ► 継続的なコンテンツ配信 ► インターネット接続を活かして新しいコンテンツを提供
  2. 年表 2014 2016 2018 2020 2022 2024 指一本で本格的な アクションゲーム! 現実が

    ドラゴンクエストの世界に! シンプル操作で リアルなゴルフ体験! 5分でサクッと チームバトル! モバイルでの リアルタイム対戦!
  3. 当時の対応 ▶ 全く同じスキーマの DB インスタンスを後から追加することで対応 ► 時間がない中で、とにかく対応に追われて実施した苦肉の策 ► 本来不要なゲームの設定データなどもまとめて追加 ▶

    シャーディングによる負荷分散 ► 分割数の事前の試算が難しい ► アプリケーションコードの複雑化を招く ► オペレーションコスト増大 後発のゲームタイトルでは...
  4. 年表 2018 2020 2014 2016 2022 2024 指一本で本格的な アクションゲーム! 現実が

    ドラゴンクエストの世界に! シンプル操作で リアルなゴルフ体験! 5分でサクッと チームバトル! モバイルでの リアルタイム対戦!
  5. 約5年前のアーキテクチャ Google Cloud Kubernetes Cluster Monitoring Prometheus Queue Workers GKE

    Pods Queue RabbitMQ (VM) Master Data MySQL (VM) Multiple Replicas Cache Memory Store API Gateway Load Balancer KPI Analytics BigQuery Logs Cloud Logging LB Phone Google認証 Cloud IAP Admin Server GKE Pods Visualization Grafana User Search Elasticsearch API Servers GKE Pods Twemproxy LB 管理者 Admin Pubsub Redis User Data Cloud Spanner
  6. 実質的に無制限のスケーリング 変更: ユーザーデータに Spanner を採用  ※ Spanner については別のカンファレンスで詳しく話したものがあります Google Cloud

    の分散型データベース ▶ ボタンひとつでスケールイン・スケールアウト ► オペレーション、運用にかかるコストの削減 ▶ コード側でシャーディングを意識する必要性が少ない ► アプリケーションコードのメンテナンス性の向上 ▶ ゼロダウンタイム ► コロプラの運用ポリシーと相性良し
  7. 変更: ワークロードの実行基盤に GKE を採用 コンテナ型仮想化の台頭 Kubernetes の仕組みに乗ることで • ホストエラー発生時の対応 •

    自前のデプロイスクリプトの管理 • 自前のサーバー台数管理システム などから解放され、運用コストがおよそ半分に! また、 Infrastructure as Code を推進することでインフラ構成を文章化し、 運用・管理・オンボーディングなどのコスト削減!
  8. 一方その頃に開発中の新作タイトルは... 対戦! 対戦! 2018 2020 2014 2016 2022 2024 指一本で本格的な

    アクションゲーム! 現実が ドラゴンクエストの世界に! シンプル操作で リアルなゴルフ体験! 5分でサクッと チームバトル! モバイルでの リアルタイム対戦!
  9. 当時リアルタイムサーバーで抱えていた課題 ▶ デプロイが大変 ► プロトコルが常時接続 ► 更新起因で切断されるとゲームがプレイできなくなる ► 何か工夫が必要 ►

    サーバー管理が手動 ► 事前にサーバーを用意し、接続先を登録 ► キャパシティプランニングが難しい ▶ なるべくデプロイをしない ► 「リアルタイムサーバーにロジックを入れない」となりがち
  10. 組織的なアーキテクチャの変更 Realtime Platform Engineering (RTPE) チームが誕生! ▶ リアルタイム通信基盤を支える中心となるチーム ► 高度な専門性でマルチプレイヤーゲームの開発をリード

    ► 初期からマルチの開発に関わり、ノウハウを蓄積 ► ベストプラクティスの共有などの情報発信 ► 基盤ライブラリの整備 ► ゲームの性質に応じて複数の選択肢を提供 ► 新技術研究 ► PoC(Proof of Concept:概念実証) ► プロトタイピング ※ 気になった方はぜひブースにも遊びに来てください!
  11. 変更: DGS の管理に Agones を採用 • GoogleForGames に含まれるオープンソースプロジェクト • Kubernetes

    の拡張で、DGS の管理機能を追加 • カスタムリソース / コントローラー / SDK などを提供 What is Agones? オープンソースで、必要なものがすべて揃った、マルチプレイヤー専用ゲー ムサーバーのスケーリングとオーケストレーションプラットフォームであり、 Kubernetes が動作する場所ならどこでも実行できます。 ※ https://agones.dev/site/
  12. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS)

    A B C ・稼働中の DGS がある? ・ルールに適している? ・キャパ的に大丈夫? 従来までの動き
  13. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS)

    A B C ・稼働中の DGS がある? ・ルールに適している? ・キャパ的に大丈夫? 従来までの動き
  14. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS)

    A B C ・稼働中の DGS がある? ・ルールに適している? ・キャパ的に大丈夫? 従来までの動き 実装が大変!
  15. ▶ 自前でサーバーを管理する必要がなくなる ► 用意された API 経由で DGS が確保されて接続先を返してくれる ► 利用された分は自動でプロビジョニング

    ► 常に一定のサーバーを自動で確保 変更: DGS の管理に Agones を採用 ▶ 運用オペレーションが減る ► Kubernetes の恩恵を丸ごと受けられる ▶ サーバーの状態を管理して柔軟に動作 ► 状態 (Creating, Ready, Allocated...)を管理 ► デプロイ時に使用中の DGS は影響を受けない ► ゲームを楽しんでくれているユーザー様への悪影響を心配しなくて良い
  16. ▶ 対戦型のゲームでは、一緒に遊ぶプレイヤーをどうやって見つけてくるかと いう問題は非常に重要 ► 全然レベル感の違うプレイヤー同士で対戦させられると双方にとって不都合 ► 適切な相手をずっと探し続けて全然遊べないのは困る ▶ マッチングロジックは非常に複雑化しがち ►

    レベル、ランク、レーティング、ルール的な制約...etc ▶ これまでは API サーバー(PHP)に実装 ► 仕組み作りから入らないといけないのが辛い ► 密結合な実装により、運用が進むにつれて保守が大変に マッチメイキングの課題
  17. 変更: マッチメイキングに Open Match を採用 • こちらも GoogleForGames のオープンソースプロジェクト •

    Google と Unity が中心となって発足 • クラウドネイティブなマッチメイキングフレームワーク ◦ Kubernetes 上で動かすことが前提 ◦ マイクロサービスアーキテクチャを採用 ◦ 高い柔軟性を備え、マッチングロジックの実装に集中できる What is Open Match? Open Match は、ゲームに合わせてスケーリング可能な 柔軟なマッチメイキングシステムです。 ※ https://open-match.dev/site/
  18. 変更: マッチメイキングに Open Match を採用 今 最近の DGS について 仕組み作りから始める必

    要がなくなり、ゲームロ ジックの調整に集中でき るように!
  19. 効果 DGS / マッチング の基盤作りから解放! API サーバー DGS DGS 対戦リクエストなど

    マッチ依頼 DGS 要求 DGS 割り当て ゲームロジックに 注力できるように!
  20. 今のアーキテクチャの課題と今後の展望 ▶ GKE のアップグレードが大変問題 ► 数ヶ月に一度コントロールプレーンとノードのバージョン更新 ► 本来であれば特に何も起こらないはずだが... ► 謎の

    IO 負荷の上昇によりサービス影響 ► GKE 側のコンポーネントが謎のエラー ► なんでも GKE とすると運用中のものを全て上げて回るのも大変 ▶ Cloud Run などのより軽量な実行基盤を検証中 ► 周辺サービスで試験的に導入 ► 運用ノウハウを蓄積し、選択肢の拡大へ
  21. 今のアーキテクチャの課題と今後の展望 ▶ Agones ► Kubernetes のバージョンに依存している ► GKE アップグレードに追従しないといけない ►

    Counters and Lists 機能を使用してリソース効率の改善 ► モバイルゲームのインフラアーキテクチャ特集にて詳しく紹介 ▶ Open Match ► open-match2 というリポジトリが作られている ► 今後の動きについて要チェック
  22. まとめ 2014 2019 2024 データベースが詰まってしまう... Google Cloud + GKE +

    Spanner 構成へ 対戦型ゲームの開発の盛り上がりを受けて... Agones + Open Match + DGS によるマルチ開発 これからも挑戦は続く...