白猫ゴルフを支える Gaming OSS と Google Cloud

※資料内の参照リンクを選択し閲覧する場合は、ダウンロードをお願いいたします

＼積極的に技術発信を行なっております／

▽ Twitter/COLOPL_Tech
https://twitter.com/colopl_tech

▽ connpassページ
http://colopl.connpass.com

▽ COLOPL Tech Blog
http://blog.colopl.dev

Transcript

1. 白猫ゴルフを支える Gaming OSS と Google Cloud Date 2023.03.15
2. スピーカー自己紹介 コロプラで運用・開発を行っているゲーム向けに、 GKE や Cloud Spanner など、コンテナやマネージド サービスを用いたゲームイ ンフラの運用・設計を行っています。 “第 1 回 Game Engineers Meetup - Agones 特集” 登壇 Professional Cloud Architect 認定 杉浦 綜介 株式会社コロプラ 技術基盤本部 インフラストラクチャ部
3. 白猫ゴルフと要件 インフラ全体像 アプリケーション データストア Agones Open Match ゲームプレイの流れ まとめ 01 02 03 04 05 06 07 08
4. 白猫ゴルフと要件 01
5. 白猫ゴルフ • スマートフォン向けオンラインゲーム ◦ 白猫シリーズ最新作 ◦ 2022 年 10 月 26 日リリース ◦ 約 170 カ国同時リリース • ゴルフゲーム ◦ 「リアルなゴルフ体験」 ◦ プレイヤー間マルチプレイ ◦ レートマッチ ※1 https://colopl.co.jp/shironekogolf/
6. 白猫ゴルフ特有のシステム要件 • ルーム制のオンライン対戦 ◦ プレイヤー間の通信を中継するための専用サーバが必要 • マッチングシステム ◦ レートなどの条件に基づいた、マッチングシステムが必要 ◦ システムとマッチルールの管理の分離 ▪ 以前は、マッチングシステムを各ゲームごとに内製していた ※1 https://colopl.co.jp/shironekogolf/
7. コロプラのインフラの要件 • 高可用性 ◦ K8s クラスター障害に耐えられる ◦ 自動復旧 • ノーダウンタイムメンテナンス ◦ ゲームサービスを継続したまま、インフラメンテナンスを行う ▪ K8s クラスターアップグレード • 3 〜5 ヶ月ごと ▪ 破壊的変更のあるミドルウェアのアップグレード
8. インフラ全体像 02
9. インフラ全体像 1 • アプリケーション ◦ フロントエンド アプリケーション サーバ ◦ マルチクラスター ◦ HAProxy + Multi Cluster Ingress • データストア ◦ Cloud Spanner (ユーザーデータ） ◦ TiDB（マスターデータ） ◦ Redis Enterprise（キャッシュ）
10. インフラ全体像 2 • Agones ◦ Dedicated game server 管理 ◦ マルチクラスター • Open Match ◦ マッチングシステム ◦ マルチクラスター ◦ Memorystore for Redis
11. アプリケーション 03
12. アプリケーション • GKE Standard ◦ マルチクラスター（3 クラスター）※１ ◦ Node のゾーン分散 ◦ クラスターごとに Canary の Pod ▪ 先行リリース用 • 負荷分散 ◦ Multi Cluster Ingress ▪ HAProxy の分散 ◦ HAProxy (GKE Autopilot) ▪ HTTP ヘッダーでのルーティング ※1 『ドラゴンクエストウォーク』で、 Kubernetesのマルチクラスター構成を採用した経緯 https://colopl.co.jp/recruit/team/en-blog_vol6.php
13. アプリケーション • Agones Gameserver からの通信 ◦ ゲームプレイ終了後の結果通知 • RabbitMQ ◦ キューイング ◦ バッチ処理用
14. データストア 04
15. データストア • Cloud Spanner ◦ ユーザーデータ ◦ ランダムアクセスに非常に強い ▪ UUID を用いた分散を行い、ホットスポットを回避 • TiDB ◦ マスターデータ ◦ MySQL 互換で高可用性 • Redis Enterprise ◦ キャッシュ ◦ 早い failover ◦ ダウンタイム無しで、 Scale UP 出来る
16. データストア • 高可用性 ◦ サービス側で冗長性が保たれている • ノーダウンタイムのメンテナンス ◦ バックグラウンドでメンテナンスが行われる ◦ ゲームサービスのノーダウンタイムに貢献
17. Agones 05
18. Agones に求めたもの • オートスケール ◦ アクセス量に応じた Dedicated Game Server の増減で、 パフォーマンスの最適化 • Dedicated Game Server の接続先情報の自動管理 ◦ Allocator が管理することで、 接続 IP や Port など管理の手間を減らす • 高可用性 ◦ マルチクラスターの実装 ◦ 自動復旧
19. Agones 構成 • マルチクラスター（3 クラスター） ◦ Agones Allocator をロードバランサーでバランシング • GKE クラスター内で完結 ◦ クラスター切替時に影響を与えない ▪ クラスターアップグレードなど • 接続 ◦ アプリケーション と Open Match から Allocator ◦ クライアントから Gameserver • 詳細は “第 1 回 Game Engineers Meetup - Agones 特集” ※1 ※1 第 1 回 Game Engineers Meetup - Agones 特集 https://cloudonair.withgoogle.com/events/innovators-live-jp/watch?talk=game_220810_1
20. Open Match 06
21. Open Match に求めたもの • 内製マッチングシステムからの脱却とメンテナーの分離 ◦ マイクロサービス ◦ マッチングシステムのメンテナンスを、専門チームに任せる ◦ ゲーム開発チームは、マッチング内容に集中出来る • マッチングの高効率化と自動復旧 ◦ データベースに負荷をかけず、かつ効率的にマッチングを行う ◦ 自動復旧可能な構成を行う ▪ キャッシュをクラスター内で持たない構成
22. Open Match 構成 ※1 【Google Cloud × GAME】ゲーム開発における Google Cloud 活用事例: https://blog.colopl.dev/entry/2022/12/23/110059 • Open Match ◦ GKE ◦ Memorystore for Redis • マルチクラスター ※1 ◦ 一部コンポーネントはアクティブスタン バイ ◦ Director のみ 1 つ ▪ マッチング不整合防止のため
23. Open Match 構成 2 • Memorystore for Redis ◦ チケットのキャッシュ ◦ 高負荷にならないことから採用 ▪ 小規模利用であればコスト◯ • Istio, Anthos Service Mesh などは採用せず ◦ コロプラでの利用実績が無い ◦ 設計が必要以上に複雑になる懸念
24. ゲームプレイの流れ 07
25. ゲームプレイの流れ １． マッチリクエスト - クライアントからアプリケーション ２．マッチメイキング開始 - アプリケーション から Open Match にチケットを発行
26. ゲームプレイの流れ ３．Open Match でマッチメイクを行う - 対戦相手の決定 ４．Agones から Game Server の接続先を取得する - Open Match の Director が行う
27. ゲームプレイの流れ ５．クライアントがゲームサーバーに接続 - クライアント間の通信は Agones経由 - ショットデータなどの一部アクションは、 アプリケーションサーバにも送信 ６．プレイ後に結果を アプリケーション に送信
28. まとめ 08
29. まとめ • 白猫ゴルフの要件 ◦ ルーム制オンライン対戦 ◦ レートマッチング ◦ 高可用性 ◦ ノーダウンタイムメンテナンス • Gaming OSS ◦ Agones ▪ オートスケールされる Dedicated Game Server ◦ Open Match ▪ システムとマッチング内容の分離 • データストア ◦ Cloud Spanner（ユーザーデータ） ◦ TiDB（マスターデータ） ◦ Redis Enterprise（キャッシュ） ◦ Memorystore for Redis（チケットキャッシュ）
30. Thank you. Proprietary + Confidential