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

Transcript

1. 株式会社コロプラ 大規模トラフィックを支える ゲームバックエンドの課題と構成の変遷 ~安定したゲーム体験を実現するために~ 2024.11.26
2. 仲山 悠也 株式会社コロプラ サーバー基盤グループ LCEチーム バックエンドエンジニア 自己紹介
3. コロプラについて
4. コロプラについて Vision 行動指針 エンターテインメントで日常をより楽しく、より素晴らしく Mission
5. コロプラについて
6. 最新作
7. 本題
8. アジェンダ 1 スマートフォンゲームの構成について 2 昔のアーキテクチャのお話 3 少し昔のアーキテクチャのお話 4 最近のアーキテクチャのお話
9. スマートフォンゲームとは スマホやタブレットなどのモバイル端末上で動作するゲーム ▶ 特徴 ► 高い携帯性 ► いつでもどこでも手軽にプレイ可能 ► ソーシャル要素 ► 他のプレイヤーとの協力、対戦、交流が可能 ► 継続的なコンテンツ配信 ► インターネット接続を活かして新しいコンテンツを提供
10. Web アプリケーションとほとんど同じ構造 スマートフォンゲームの主要コンポーネント API サーバー Request Response クライアント 言語：C#
11. より楽しいゲーム体験を実現するために リアルタイムな通信を実現するための専用のサーバーが存在する場合がある リアルタイムサーバー クライアント 言語：C#
12. より楽しいゲーム体験を実現するために
13. より楽しいゲーム体験を実現するために
14. より楽しいゲーム体験を実現するために ・移動したよ！ ・敵を倒した！ ・ターンエンド！
15. より楽しいゲーム体験を実現するために
16. より楽しいゲーム体験を実現するために
17. より楽しいゲーム体験を実現するために 専用ゲームサーバー（DGS）
18. スマートフォンゲームの主要コンポーネント API サーバー Request Response クライアント 言語：C# リアルタイムサーバー（DGS）
19. 具体例
20. 年表 2014 2016 2018 2020 2022 2024 指一本で本格的な アクションゲーム！ 現実が ドラゴンクエストの世界に！ シンプル操作で リアルなゴルフ体験！ 5分でサクッと チームバトル！ モバイルでの リアルタイム対戦！
21. 約10年前のアーキテクチャ
22. 事件発生
23. スマートフォンゲームのアクセスパターン 新作ローンチ時やイベントリリース時は急激にアクセスが増加
24. 当時よく発生した問題 急激に伸びるユーザー数 データ量及びクエリの増加によるデータベースの負荷の急上昇 データベースが詰まって接続が不安定に...
25. 当時の対応 ▶ 全く同じスキーマの DB インスタンスを後から追加することで対応 ► 時間がない中で、とにかく対応に追われて実施した苦肉の策 ► 本来不要なゲームの設定データなどもまとめて追加
26. 当時の対応 ▶ 全く同じスキーマの DB インスタンスを後から追加することで対応 ► 時間がない中で、とにかく対応に追われて実施した苦肉の策 ► 本来不要なゲームの設定データなどもまとめて追加 ？ API サーバー
27. 当時の対応 ▶ 全く同じスキーマの DB インスタンスを後から追加することで対応 ► 時間がない中で、とにかく対応に追われて実施した苦肉の策 ► 本来不要なゲームの設定データなどもまとめて追加 ▶ シャーディングによる負荷分散 ► 分割数の事前の試算が難しい ► アプリケーションコードの複雑化を招く ► オペレーションコスト増大 後発のゲームタイトルでは...
28. 当時の課題 データベースをなんとかして 運用コストを下げたい！
29. 年表 2018 2020 2014 2016 2022 2024 指一本で本格的な アクションゲーム！ 現実が ドラゴンクエストの世界に！ シンプル操作で リアルなゴルフ体験！ 5分でサクッと チームバトル！ モバイルでの リアルタイム対戦！
30. 約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
31. 実質的に無制限のスケーリング 変更: ユーザーデータに Spanner を採用 　※ Spanner については別のカンファレンスで詳しく話したものがあります Google Cloud の分散型データベース ▶ ボタンひとつでスケールイン・スケールアウト ► オペレーション、運用にかかるコストの削減 ▶ コード側でシャーディングを意識する必要性が少ない ► アプリケーションコードのメンテナンス性の向上 ▶ ゼロダウンタイム ► コロプラの運用ポリシーと相性良し
32. 変更: ワークロードの実行基盤に GKE を採用 コンテナ型仮想化の台頭 Kubernetes の仕組みに乗ることで • ホストエラー発生時の対応 • 自前のデプロイスクリプトの管理 • 自前のサーバー台数管理システム などから解放され、運用コストがおよそ半分に！ また、 Infrastructure as Code を推進することでインフラ構成を文章化し、 運用・管理・オンボーディングなどのコスト削減！
33. 効果 最大規模のタイトルの 安定運用に成功！ ここ5年間で大きな サービスダウンはなし！
34. この頃の社内におけるアーキテクチャ選定の考え Google Cloud + GKE + Spanner は大成功！ 今後の新作もこの組み合わせでやっていく！
35. 一方その頃に開発中の新作タイトルは... 対戦！ 対戦！ 2018 2020 2014 2016 2022 2024 指一本で本格的な アクションゲーム！ 現実が ドラゴンクエストの世界に！ シンプル操作で リアルなゴルフ体験！ 5分でサクッと チームバトル！ モバイルでの リアルタイム対戦！
36. 社内で高まる気運 社内のニーズ 対戦型のゲームをうまく効率よく作っていきたい！ 対戦型ゲームの要件 プレイヤーの操作をリアルタイムにゲーム内に反映 帰結 リアルタイムサーバーの活用が重要！
37. 当時リアルタイムサーバーで抱えていた課題 ▶ デプロイが大変 ► プロトコルが常時接続 ► 更新起因で切断されるとゲームがプレイできなくなる ► 何か工夫が必要 ► サーバー管理が手動 ► 事前にサーバーを用意し、接続先を登録 ► キャパシティプランニングが難しい ▶ なるべくデプロイをしない ► 「リアルタイムサーバーにロジックを入れない」となりがち
38. 当時リアルタイムサーバーで抱えていた課題 ▶ 属人化 ► 高度な専門性を必要とするので、対応者が偏りがち ► チーム内の有識者が都度対応 ▶ 組織としての柔軟性が欠如 ► 個人に知識が集中 ► 進捗が個人の課題解決能力に依存
39. 組織的なアーキテクチャの変更 Realtime Platform Engineering (RTPE) チームが誕生！ ▶ リアルタイム通信基盤を支える中心となるチーム ► 高度な専門性でマルチプレイヤーゲームの開発をリード ► 初期からマルチの開発に関わり、ノウハウを蓄積 ► ベストプラクティスの共有などの情報発信 ► 基盤ライブラリの整備 ► ゲームの性質に応じて複数の選択肢を提供 ► 新技術研究 ► PoC（Proof of Concept：概念実証） ► プロトタイピング ※ 気になった方はぜひブースにも遊びに来てください！
40. 年表 指一本で本格的な アクションゲーム！ 現実が ドラゴンクエストの世界に！ シンプル操作で リアルなゴルフ体験！ 5分でサクッと チームバトル！ 2022 2024 2014 2016 2018 2020 モバイルでの リアルタイム対戦！
41. 最新のアーキテクチャ
42. 変更: DGS の管理に Agones を採用 • GoogleForGames に含まれるオープンソースプロジェクト • Kubernetes の拡張で、DGS の管理機能を追加 • カスタムリソース / コントローラー / SDK などを提供 What is Agones? オープンソースで、必要なものがすべて揃った、マルチプレイヤー専用ゲー ムサーバーのスケーリングとオーケストレーションプラットフォームであり、 Kubernetes が動作する場所ならどこでも実行できます。 ※ https://agones.dev/site/
43. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS) A B C 従来までの動き
44. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS) A B C ふたりで遊びたい！ 従来までの動き
45. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS) A B C ・稼働中の DGS がある？ ・ルールに適している？ ・キャパ的に大丈夫？ 従来までの動き
46. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS) A B C C を使って！ 従来までの動き
47. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS) A B C 従来までの動き
48. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS) A B C ・稼働中の DGS がある？ ・ルールに適している？ ・キャパ的に大丈夫？ 従来までの動き
49. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS) A B C ・稼働中の DGS がある？ ・ルールに適している？ ・キャパ的に大丈夫？ 従来までの動き 実装が大変！
50. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS) A B C 従来までの動き
51. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS) A B C 従来までの動き 　DGS の管理を肩代わり
52. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS) A B C Agones 導入後の動き
53. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS) A B C ふたりで遊びたい！ Agones 導入後の動き
54. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS) A B C DGS ください Agones 導入後の動き
55. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS) A B C C を割り当てました Agones 導入後の動き
56. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS) A B C C を使って！ Agones 導入後の動き
57. ▶ 自前でサーバーを管理する必要がなくなる ► 用意された API 経由で DGS が確保されて接続先を返してくれる ► 利用された分は自動でプロビジョニング ► 常に一定のサーバーを自動で確保 変更: DGS の管理に Agones を採用 ▶ 運用オペレーションが減る ► Kubernetes の恩恵を丸ごと受けられる ▶ サーバーの状態を管理して柔軟に動作 ► 状態 (Creating, Ready, Allocated...)を管理 ► デプロイ時に使用中の DGS は影響を受けない ► ゲームを楽しんでくれているユーザー様への悪影響を心配しなくて良い
58. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS) A B C ❓
59. ▶ 対戦型のゲームでは、一緒に遊ぶプレイヤーをどうやって見つけてくるかと いう問題は非常に重要 ► 全然レベル感の違うプレイヤー同士で対戦させられると双方にとって不都合 ► 適切な相手をずっと探し続けて全然遊べないのは困る ▶ マッチングロジックは非常に複雑化しがち ► レベル、ランク、レーティング、ルール的な制約...etc ▶ これまでは API サーバー（PHP）に実装 ► 仕組み作りから入らないといけないのが辛い ► 密結合な実装により、運用が進むにつれて保守が大変に マッチメイキングの課題
60. 変更: マッチメイキングに Open Match を採用 • こちらも GoogleForGames のオープンソースプロジェクト • Google と Unity が中心となって発足 • クラウドネイティブなマッチメイキングフレームワーク ◦ Kubernetes 上で動かすことが前提 ◦ マイクロサービスアーキテクチャを採用 ◦ 高い柔軟性を備え、マッチングロジックの実装に集中できる What is Open Match? Open Match は、ゲームに合わせてスケーリング可能な 柔軟なマッチメイキングシステムです。 ※ https://open-match.dev/site/
61. 変更: マッチメイキングに Open Match を採用
62. 変更: マッチメイキングに Open Match を採用 試合したい
63. 変更: マッチメイキングに Open Match を採用 チケット作成
64. 変更: マッチメイキングに Open Match を採用 マッチング対象チケット登録
65. 変更: マッチメイキングに Open Match を採用 定期的にマッチ要求
66. 変更: マッチメイキングに Open Match を採用 トリガー
67. 変更: マッチメイキングに Open Match を採用 チケット要求
68. 変更: マッチメイキングに Open Match を採用 チケット取得
69. 変更: マッチメイキングに Open Match を採用 チケット返却
70. 変更: マッチメイキングに Open Match を採用 マッチ候補リストアップ
71. 変更: マッチメイキングに Open Match を採用 マッチ候補返却
72. 変更: マッチメイキングに Open Match を採用 マッチ候補提出
73. 変更: マッチメイキングに Open Match を採用 評価依頼
74. 変更: マッチメイキングに Open Match を採用 評価結果
75. 変更: マッチメイキングに Open Match を採用 マッチ結果
76. 変更: マッチメイキングに Open Match を採用 マッチ結果返却
77. 変更: マッチメイキングに Open Match を採用 DGS 割り当て
78. 変更: マッチメイキングに Open Match を採用 チケット更新依頼
79. 変更: マッチメイキングに Open Match を採用 チケット更新
80. 変更: マッチメイキングに Open Match を採用 次のリクエストで マッチしたチケットを返却
81. 変更: マッチメイキングに Open Match を採用
82. 変更: マッチメイキングに Open Match を採用 Match Profile の定義 マッチングロジック
83. 変更: マッチメイキングに Open Match を採用 ❓
84. 変更: マッチメイキングに Open Match を採用
85. 変更: マッチメイキングに Open Match を採用 Application （PHP） 5年前
86. 変更: マッチメイキングに Open Match を採用 今
87. 変更: マッチメイキングに Open Match を採用 今 仕組み作りから始める必 要がなくなり、ゲームロ ジックの調整に集中でき るように！
88. 変更: マッチメイキングに Open Match を採用 今 最近の DGS について 仕組み作りから始める必 要がなくなり、ゲームロ ジックの調整に集中でき るように！
89. 変更: リアルタイムサーバーの積極的な活用 ▶ 従来のリアルタイムサーバー ► 受信したメッセージをそのまま他のユーザーに送信 ► リレーサーバー ► なるべくデプロイしたくない ► Agones で解決！
90. 変更: リアルタイムサーバーの積極的な活用 ▶ 最近のリアルタイムサーバー ► 必要に応じてサーバー側でもロジックを持つ ► 一貫性の担保 / 不正検知 / データ保護などの面でメリットあり 計算
91. 変更: リアルタイムサーバーの積極的な活用 ▶ 最近のリアルタイムサーバー ► 必要に応じてサーバー側でもロジックを持つ ► 一貫性の担保 / 不正検知 / データ保護などの面でメリットあり ► 用途によって複数の種類の DGS を使い分け
92. 効果 DGS / マッチング の基盤作りから解放！ API サーバー DGS DGS 対戦リクエストなど マッチ依頼 DGS 要求 DGS 割り当て ゲームロジックに 注力できるように！
93. 年表 指一本で本格的な アクションゲーム！ 現実が ドラゴンクエストの世界に！ シンプル操作で リアルなゴルフ体験！ 5分でサクッと チームバトル！ 2022 2024 2014 2016 2018 2020 モバイルでの リアルタイム対戦！
94. 今のアーキテクチャの課題と今後の展望 ▶ GKE のアップグレードが大変問題 ► 数ヶ月に一度コントロールプレーンとノードのバージョン更新 ► 本来であれば特に何も起こらないはずだが... ► 謎の IO 負荷の上昇によりサービス影響 ► GKE 側のコンポーネントが謎のエラー ► なんでも GKE とすると運用中のものを全て上げて回るのも大変 ▶ Cloud Run などのより軽量な実行基盤を検証中 ► 周辺サービスで試験的に導入 ► 運用ノウハウを蓄積し、選択肢の拡大へ
95. 今のアーキテクチャの課題と今後の展望 ▶ Agones ► Kubernetes のバージョンに依存している ► GKE アップグレードに追従しないといけない ► Counters and Lists 機能を使用してリソース効率の改善 ► モバイルゲームのインフラアーキテクチャ特集にて詳しく紹介 ▶ Open Match ► open-match2 というリポジトリが作られている ► 今後の動きについて要チェック
96. まとめ 2014 2019 2024 データベースが詰まってしまう... Google Cloud + GKE + Spanner 構成へ 対戦型ゲームの開発の盛り上がりを受けて... Agones + Open Match + DGS によるマルチ開発 これからも挑戦は続く...
97. ブースにも遊びにきてね！ 共に「新体験」を創る仲間、募集中！