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 クラスタ間の通信
   問題
   

   View Slide

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

   View Slide

3. 白猫ゴルフ
   

   View Slide

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

   View Slide

5. Open Match
   

   View Slide

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

   View Slide

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

   

   View Slide

8. Open Match と冗長化
   

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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 検証結果
    

    View Slide

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

    View Slide

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% を保証できることを確認
    

    View Slide

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
    

    View Slide

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
    まとめ
    

    View Slide

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

    View Slide