Open MatchにおけるGKEクラスタ間の通信問題 /ColoplTech-09-02

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

＼積極的に技術発信を行なっております／
▽ Twitter/COLOPL_Tech
https://twitter.com/colopl_tech

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

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

Transcript

1. カク Open Match における GKE クラスタ間の通信 問題
2. 氏名　 ： 部署　 ： 株式会社コロプラ 2020年新卒入社 - 2020/4 ~ 2021/9: VM のゲームインフラ運用 - 2021/9 ~ 今: Kubernetes のゲームインフラ運用 2 カク 　自己紹介 インフラグループ
3. 白猫ゴルフ
4. • 待望の白猫シリーズ新作 • 本物に近いゴルフ体験ゲーム • 10月26日から約170ヵ国で同時配信 • プレイヤー間の対人戦 • ゴルフツアーのマッチングに Open Match 　　　が使われている 4 白猫ゴルフ
5. Open Match
6. 6 Open Match 概要 • オープンソースマッチメイクフレームワーク ◦ PHP でレーティングマッチの実装が辛い ◦ 社内メンテナンス負担の軽減 ◦ (コミュニティ活性度やや低い・・) • Microservices として動いてる ◦ 開発側はマッチング処理に集中できる • 内部通信は全て gRPC ◦ (内部構造は結構複雑・・) https://github.com/googleforgames/open-match/
7. 7 Open Match コンポーネント https://open-match.dev/site/docs/guides/matchmaker/ 

8. Open Match と冗長化
9. • Game Frontend (PHP) と GameServer (Agones/Go) の可用性 ◦ Kubernetes の Pod/Node/Cluster の単位で冗長化されている ◦ Pod の再起動や Node/Cluster 障害が発生しても全断はしない • データーベースの可用性 ◦ マネージドサービス Cloud Spanner で高可用性が担保されている • Open Match の可用性 ◦ GKE 更新や Open Match の破壊的な変更もノーメンテナンスでの対応が望まれる ◦ 対戦ゲームでマッチングが止まることは致命的 ◦ Open Match も他のコンポーネントと同水準の可用性を目指したい 9 ゲームインフラの可用性
10. • 大部分は Deployment で単純な冗長化が可能 ◦ GKE 更新や Node 等の障害でも全断しない • ただし Open Match Director だけ可用性の担保が難しい ◦ Single cluster だとクラスタ障害への対応が難しい 10 Open Match の可用性
11. • Multi cluster 化は必須 • クラスタ間の負荷分散を行うコンポーネントが必要 ◦ コンポーネント自体の可用性も担保する • Open Match のコンポーネント間の gRPC 負荷分散も必要 • 各クラスタの可用性も可能な限り担保する • 極力マネージドサービスを使って運用を楽にしたい 11 Open Match の冗長化実現したいこと
12. • 言わずと知れたサーバーレスコ ンテナのマネージドサービス • LB も含めて Cloud Run にでき るとシンプルな構成になる • 検証対象として選定した主な理 由は以下 ◦ GKE 更新が発生しない ◦ Cloud Run の利用実績が作れると 他の利用方法の足掛かりにもなる ◦ サーバーコストも抑えられる (か もしれない) 12 Open Match on Cloud Run の検証
13. 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 検証結果
14. • Cloud Run は採用が難しいことがわかったため GKE での設計を開始 • 冗長化へ向けていくつか解決すべき課題が存在 ◦ 現実的な SLA の確認 ◦ クラスタ間の LB の選定 ▪ gRPC の負荷分散が必要になる ◦ Open Match Director の冗長化 14 Open Match on GKE の冗長化
15. 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% を保証できることを確認
16. 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
17. • 白猫ゴルフはマッチングサービス 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. 18 ご清聴ありがとうご ざいました！