白猫ゴルフを支える 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
   

   View Slide

2. スピーカー自己紹介
   コロプラで運用・開発を行っているゲーム向けに、 GKE や Cloud
   Spanner など、コンテナやマネージド サービスを用いたゲームイ
   ンフラの運用・設計を行っています。
   “第 1 回 Game Engineers Meetup - Agones 特集” 登壇
   Professional Cloud Architect 認定
   杉浦 綜介
   株式会社コロプラ
   技術基盤本部
   インフラストラクチャ部
   

   View Slide

3. 白猫ゴルフと要件
   インフラ全体像
   アプリケーション
   データストア
   Agones
   Open Match
   ゲームプレイの流れ
   まとめ
   01
   02
   03
   04
   05
   06
   07
   08
   

   View Slide

4. 白猫ゴルフと要件
   01
   

   View Slide

5. 白猫ゴルフ
   ● スマートフォン向けオンラインゲーム
   ○ 白猫シリーズ最新作
   ○ 2022 年 10 月 26 日リリース
   ○ 約 170 カ国同時リリース
   ● ゴルフゲーム
   ○ 「リアルなゴルフ体験」
   ○ プレイヤー間マルチプレイ
   ○ レートマッチ
   ※1 https://colopl.co.jp/shironekogolf/
   

   View Slide

6. 白猫ゴルフ特有のシステム要件
   ● ルーム制のオンライン対戦
   ○ プレイヤー間の通信を中継するための専用サーバが必要
   ● マッチングシステム
   ○ レートなどの条件に基づいた、マッチングシステムが必要
   ○ システムとマッチルールの管理の分離
   ■ 以前は、マッチングシステムを各ゲームごとに内製していた
   ※1 https://colopl.co.jp/shironekogolf/
   

   View Slide

7. コロプラのインフラの要件
   ● 高可用性
   ○ K8s クラスター障害に耐えられる
   ○ 自動復旧
   ● ノーダウンタイムメンテナンス
   ○ ゲームサービスを継続したまま、インフラメンテナンスを行う
   ■ K8s クラスターアップグレード
   ● 3 〜5 ヶ月ごと
   ■ 破壊的変更のあるミドルウェアのアップグレード
   

   View Slide

8. インフラ全体像
   02
   

   View Slide

9. インフラ全体像 1
   ● アプリケーション
   ○ フロントエンド アプリケーション サーバ
   ○ マルチクラスター
   ○ HAProxy + Multi Cluster Ingress
   ● データストア
   ○ Cloud Spanner (ユーザーデータ）
   ○ TiDB（マスターデータ）
   ○ Redis Enterprise（キャッシュ）
   

   View Slide

10. インフラ全体像 2
    ● Agones
    ○ Dedicated game server 管理
    ○ マルチクラスター
    ● Open Match
    ○ マッチングシステム
    ○ マルチクラスター
    ○ Memorystore for Redis
    

    View Slide

11. アプリケーション
    03
    

    View Slide

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
    

    View Slide

13. アプリケーション
    ● Agones Gameserver からの通信
    ○ ゲームプレイ終了後の結果通知
    ● RabbitMQ
    ○ キューイング
    ○ バッチ処理用
    

    View Slide

14. データストア
    04
    

    View Slide

15. データストア
    ● Cloud Spanner
    ○ ユーザーデータ
    ○ ランダムアクセスに非常に強い
    ■ UUID を用いた分散を行い、ホットスポットを回避
    ● TiDB
    ○ マスターデータ
    ○ MySQL 互換で高可用性
    ● Redis Enterprise
    ○ キャッシュ
    ○ 早い failover
    ○ ダウンタイム無しで、 Scale UP 出来る
    

    View Slide

16. データストア
    ● 高可用性
    ○ サービス側で冗長性が保たれている
    ● ノーダウンタイムのメンテナンス
    ○ バックグラウンドでメンテナンスが行われる
    ○ ゲームサービスのノーダウンタイムに貢献
    

    View Slide

17. Agones
    05
    

    View Slide

18. Agones に求めたもの
    ● オートスケール
    ○ アクセス量に応じた Dedicated Game Server の増減で、
    パフォーマンスの最適化
    ● Dedicated Game Server の接続先情報の自動管理
    ○ Allocator が管理することで、
    接続 IP や Port など管理の手間を減らす
    ● 高可用性
    ○ マルチクラスターの実装
    ○ 自動復旧
    

    View Slide

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
    

    View Slide

20. Open Match
    06
    

    View Slide

21. Open Match に求めたもの
    ● 内製マッチングシステムからの脱却とメンテナーの分離
    ○ マイクロサービス
    ○ マッチングシステムのメンテナンスを、専門チームに任せる
    ○ ゲーム開発チームは、マッチング内容に集中出来る
    ● マッチングの高効率化と自動復旧
    ○ データベースに負荷をかけず、かつ効率的にマッチングを行う
    ○ 自動復旧可能な構成を行う
    ■ キャッシュをクラスター内で持たない構成
    

    View Slide

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 つ
    ■ マッチング不整合防止のため
    

    View Slide

23. Open Match 構成 2
    ● Memorystore for Redis
    ○ チケットのキャッシュ
    ○ 高負荷にならないことから採用
    ■ 小規模利用であればコスト◯
    ● Istio, Anthos Service Mesh などは採用せず
    ○ コロプラでの利用実績が無い
    ○ 設計が必要以上に複雑になる懸念
    

    View Slide

24. ゲームプレイの流れ
    07
    

    View Slide

25. ゲームプレイの流れ
    １． マッチリクエスト
    - クライアントからアプリケーション
    ２．マッチメイキング開始
    - アプリケーション から Open Match にチケットを発行
    

    View Slide

26. ゲームプレイの流れ
    ３．Open Match でマッチメイクを行う
    - 対戦相手の決定
    ４．Agones から Game Server の接続先を取得する
    - Open Match の Director が行う
    

    View Slide

27. ゲームプレイの流れ
    ５．クライアントがゲームサーバーに接続
    - クライアント間の通信は Agones経由
    - ショットデータなどの一部アクションは、
    アプリケーションサーバにも送信
    ６．プレイ後に結果を アプリケーション に送信
    

    View Slide

28. まとめ
    08
    

    View Slide

29. まとめ
    ● 白猫ゴルフの要件
    ○ ルーム制オンライン対戦
    ○ レートマッチング
    ○ 高可用性
    ○ ノーダウンタイムメンテナンス
    ● Gaming OSS
    ○ Agones
    ■ オートスケールされる Dedicated Game Server
    ○ Open Match
    ■ システムとマッチング内容の分離
    ● データストア
    ○ Cloud Spanner（ユーザーデータ）
    ○ TiDB（マスターデータ）
    ○ Redis Enterprise（キャッシュ）
    ○ Memorystore for Redis（チケットキャッシュ）
    

    View Slide

30. Thank you.
    Proprietary + Confidential
    

    View Slide