カク Open Match における GKE クラスタ間の通信 問題

氏名　 ： 部署　 ： 株式会社コロプラ 2020年新卒入社 - 2020/4 ~ 2021/9: VM のゲームインフラ運用 - 2021/9 ~ 今: Kubernetes のゲームインフラ運用 2 カク 　自己紹介 インフラグループ

白猫ゴルフ

● 待望の白猫シリーズ新作 ● 本物に近いゴルフ体験ゲーム ● 10月26日から約170ヵ国で同時配信 ● プレイヤー間の対人戦 ● ゴルフツアーのマッチングに Open Match 　　　が使われている 4 白猫ゴルフ

Open Match

6 Open Match 概要 ● オープンソースマッチメイクフレームワーク ○ PHP でレーティングマッチの実装が辛い ○ 社内メンテナンス負担の軽減 ○ (コミュニティ活性度やや低い・・) ● Microservices として動いてる ○ 開発側はマッチング処理に集中できる ● 内部通信は全て gRPC ○ (内部構造は結構複雑・・) https://github.com/googleforgames/open-match/

7 Open Match コンポーネント https://open-match.dev/site/docs/guides/matchmaker/ 


Open Match と冗長化

● Game Frontend (PHP) と GameServer (Agones/Go) の可用性 ○ Kubernetes の Pod/Node/Cluster の単位で冗長化されている ○ Pod の再起動や Node/Cluster 障害が発生しても全断はしない ● データーベースの可用性 ○ マネージドサービス Cloud Spanner で高可用性が担保されている ● Open Match の可用性 ○ GKE 更新や Open Match の破壊的な変更もノーメンテナンスでの対応が望まれる ○ 対戦ゲームでマッチングが止まることは致命的 ○ Open Match も他のコンポーネントと同水準の可用性を目指したい 9 ゲームインフラの可用性

● 大部分は Deployment で単純な冗長化が可能 ○ GKE 更新や Node 等の障害でも全断しない ● ただし Open Match Director だけ可用性の担保が難しい ○ Single cluster だとクラスタ障害への対応が難しい 10 Open Match の可用性

● Multi cluster 化は必須 ● クラスタ間の負荷分散を行うコンポーネントが必要 ○ コンポーネント自体の可用性も担保する ● Open Match のコンポーネント間の gRPC 負荷分散も必要 ● 各クラスタの可用性も可能な限り担保する ● 極力マネージドサービスを使って運用を楽にしたい 11 Open Match の冗長化実現したいこと

● 言わずと知れたサーバーレスコ ンテナのマネージドサービス ● LB も含めて Cloud Run にでき るとシンプルな構成になる ● 検証対象として選定した主な理 由は以下 ○ GKE 更新が発生しない ○ Cloud Run の利用実績が作れると 他の利用方法の足掛かりにもなる ○ サーバーコストも抑えられる (か もしれない) 12 Open Match on Cloud Run の検証

13 Pro ● マネージドサービスで楽 ● SLA 99.95% ○ ただ Open Match コンポーネント多いので多少稼働率落ちる Con ● ILB (HTTPS) と Cloud Run (Serverless NEGs) 連携は Preview ○ Cloud Run 上では gRPC の負荷分散が難しい ● Open Match の設定ファイルは Secret Manager にマウントする選択肢し かない ● 第 2 世代の実行環境じゃないと解決できない問題ある ○ 第 2 世代の実行環境はまだ Preview ○ Linux 完全互換な環境を使いたい Open Match on Cloud Run 検証結果

● Cloud Run は採用が難しいことがわかったため GKE での設計を開始 ● 冗長化へ向けていくつか解決すべき課題が存在 ○ 現実的な SLA の確認 ○ クラスタ間の LB の選定 ■ gRPC の負荷分散が必要になる ○ Open Match Director の冗長化 14 Open Match on GKE の冗長化

15 MCI/MCS で Open Match を冗長化 ● HAProxy on GKE Autopilot でクラ スタ間の負荷分散 ● Multi Cluster Ingress (MCI) で HAProxy 自体をマルチクラスタ化 ● Multi Cluster Service ● マルチクラスタにすることで Director を冗長化 ● ただし Active-Active ではなく Active-Standby 構成 ● 上記構成で障害試験を実施して SLA 99.98% を保証できることを確認

HAProxy on GKE AutoPilot ● gRPC に対応している LB の選択肢がそもそも少ない ● HAProxy 自体は社内での利用実績があった Multi Cluster Ingress ● LB をマルチクラスタにする都合上 LB の LB が必要 ○ gRPC 対応 ○ マネージドなのでメンテナンス不要 Multl Cluster Service ● Multi Cluster Ingress (MCI) 使うのに必要 ● ILB だと gRPC の負荷分散ができないので、PHP -> Open Match の gRPC 通信を Headless Service 経由で負荷分散 16 HAProxy, MCI and MCS

● 白猫ゴルフはマッチングサービス Open Match を採用 ○ OSS でメンテナンス負担軽減 ○ 複雑なコンポーネントで冗長化は課題になった ● Open Match with Cloud Run ○ 運用は楽ですがニーズに合わないところ多い ● Open Match with MCI/MCS ←採用 ○ 運用はややこしいですが高可用性である ● 将来展望 ○ 進化している Cloud Run, Gateway API などで冗長化期待 ■ Gateway API: HAProxy on GKE Autopilot も必要なくなる 17 まとめ

18 ご清聴ありがとうご ざいました！