大規模ゲームインフラとしての Kubernetes とノーメンテナンス運用

1. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 1
 大規模ゲームインフラとしての Kubernetes とノーメンテナンス運用
 2021/12/3
 Cloud Native Lounge #3
 「Kubernetesで実現する大規模サービス基盤運用」

2. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 2
 Table of Contents
 • ソーシャルゲームのバックエンド
 • ゲームインフラのアーキテクチャ変遷
 • Kubernetes 及び GKE のリリースサイクル
 • GKE バージョン更新や新機能の導入戦略
 • 課題と今後について

3. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 3
 About Me
 • 長澤 翼 (Tsubasa Nagasawa)
 • インフラエンジニア
 • 株式会社コロプラ所属 (2020.3-)
 • 横断的なチームでゲームタイトルの GKE クラスター運用と改善
 • 外部登壇
 ◦ Zero Scale Abstraction in Knative Serving
 ◦ Reliable and Performant DNS Resolution with High Available NodeLocal DNSCache

4. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 4
 Original Backend Components
 • API Server
 ◦ ゲームロジックが実装された REST API サーバー
 • Realtime Game Server
 ◦ UDP/TCP でメッセージをやり取り
 ◦ 対戦・協力・チャットルーム
 ◦ コロプラ内製の仕組み
 ▪ Game Server の管理
 ▪ リアルタイム通信のフレームワーク 

5. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 5
 Original Architecture

6. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 6
 Original Architecture
 • API Gateway クラスター
 ◦ HAProxy とフォワードプロキシが動作
 • API Server クラスター
 ◦ 複数クラスターで同一のコンポーネントを動かす
 ▪ Kubernetes のコントロールプレーンへの負荷軽減 
 ▪ Application のデプロイ時間の短縮 
 ▪ Blast radius の縮小
 ◦ HAProxy でトラフィック分割
 ▪ 5% (canary) クラスター
 ▪ 割合は問題が起きない限り固定 

7. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 7
 Original Architecture
 • Game Server クラスター
 ◦ パブリッククラスターでクライアントが Pod (ノード) に直接接続
 ◦ コロプラ内製の仕組みの上で動く
 • GKE 上でデータストアを動作
 ◦ 揮発性のキャッシュ
 ◦ 更新頻度の低いリレーショナルデータ
 ▪ 自作の MySQL Operator を駆使 
 ◦ 複雑なマルチクラスターのサービスディスカバリー
 ▪ NodeLocal DNSCache (CoreDNS) + CoreDNS 

8. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 8
 No Maintenance Policy
 • ノーメンテナンスで GKE を運用する上で避けられない作業
 ◦ GKE クラスターの定期的なバージョン更新
 ◦ GKE の新機能への移行
 ◦ アプリケーションの展開とイベント前の台数調整
 ▪ 開発者が気軽に実行できるようにパイプラインを組む 
 ◦ GKE 上で動作するミドルウェアやツールの更新
 ▪ こまめに更新できる仕組みを作る 
 ◦ 外部システムのメンテナンスに耐える
 ▪ e.g. キューにタスクを積んで後処理 

9. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 9
 Original Upgrade Strategy
 • クラスター切り替えによる GKE バージョン更新
 ◦ API Gateway クラスター
 ◦ API Server クラスター
 ◦ Datastore クラスター
 • Surge upgrade による GKE バージョン更新
 ◦ Game Server クラスター
 ◦ Miscellaneous クラスター
 ◦ Spinnaker クラスター

10. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 10
 Original Upgrade Strategy
 • API Gateway クラスター
 ◦ Terraform で新規クラスターと必要なリソース作成
 ◦ ベースの Helm chart を手動インストール
 ◦ HAProxy の設定で古いクラスターに向ける
 ◦ 動作確認
 ◦ DNS レコードを切り替えて 2 週間程度待つ
 ◦ HAProxy の設定で徐々に新クラスターに向ける
 ◦ HAProxy の設定から古いクラスターの情報を削除

11. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 11
 Original Upgrade Strategy
 • API Server クラスター
 ◦ Terraform で新規クラスターと必要なリソース作成
 ◦ ベースの Helm chart を手動インストール
 ◦ Spinnaker への登録とパイプライン作成と展開
 ◦ QA 含めた動作確認
 ◦ Pod の最小台数をピーク時の台数に調整
 ◦ 切り替えが終わったら Pod の最小台数を元に戻す

12. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 12
 Original Upgrade Strategy
 • Datastore クラスター
 ◦ Terraform で新規クラスターと必要なリソース作成
 ◦ ベースの Helm chart を手動インストール
 ◦ クラスター間のサービスディスカバリの設定
 ◦ MySQL のスナップショットの作成と復元
 ◦ RabbitMQ に残ったメッセージの後始末

13. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 13
 Original Upgrade Strategy
 • 安全だが工数が掛かる
 ◦ 2 人月程度
 ◦ 開発チームとの調整事項が多い
 ▪ データベースの更新停止期間の調整 
 ▪ QA のお願い
 ▪ Spinnaker のパイプライン移行の共有 
 ▪ …
 ◦ 毎回この工数を掛けられない
 ▪ 横断チームなので運用タイトルが増えると破綻する 
 ▪ GKE のバージョン更新の頻度は？ 

14. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 14
 Kubernetes Release Cycle
 • Kubernetes のリリースは年間 3 回 (2021/4~)
 ◦ v1.23 -> 2021/12/7
 ◦ v1.24 -> 2022/4/12
 ◦ v1.25 -> 2022/8/9
 ◦ v1.26 -> 2022/12/6
 • 最新の 3 つのマイナーバージョンがサポート対象
 ◦ マスターとノードは 2 つのマイナーバージョンまで離れても動作可

15. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 15
 GKE Release Channel
 • Rapid channel
 ◦ Kubernetes の新機能を試す人向け
 • Regular channel
 ◦ 新機能をある程度安定した状態で利用したい人向け
 ◦ Google Cloud のオススメ
 • Stable channel
 ◦ 新機能よりも安定度を優先
 ◦ コロプラで利用したいが...
 出典: https://cloud.google.com/kubernetes-engine/docs/concepts/release-channels#what_channel_should_i_use
16. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 16
 GKE Release Channel
 • Release channel を使用するとノードも強制的に自動更新
 ◦ ノードの自動更新をオフにできない
 ◦ Google Cloud の推奨する更新方法
 • クラスターの更新時刻はメンテナンスウィンドウで指定可能
 ◦ 32 日間で 48 時間以上確保が必要
 ◦ クラスターの更新順序を明示的に指定不可
 ◦ メンテナンスの除外設定もあるにはあるが制限がある
 ◦ 開発/本番環境で release channel を変えることを推奨
 • ノーメンテナンスで Release channel を使うのは怖い...

17. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 17
 GKE Release Cycle
 • GKE release schedule が公開
 ◦ 各マイナーバージョンが利用可能になる大まかな日程が分かる
 ◦ Stable channel のデフォルトバージョンの更新予定は非公開
 • GKE のマイナーバージョンのサポート期間
 ◦ Regular channel で利用可能になってから 14 ヶ月で EOL
 ▪ 12 ヶ月のサポートと 2 ヶ月のメンテナンス期間 
 ▪ 強制的なノードのバージョン更新が開始 

18. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 18
 GKE Upgrade Cycle in Colopl
 • No channel で Stable channel 風な運用
 ◦ Stable channel のマイナーバージョンの更新サイクルに合わせる
 ▪ Stable channel のデフォルトバージョンが一番安定なはず... 
 ▪ No channel ならノードの自動更新を無効にできる 
 ▪ 3 - 4 ヶ月に 1 回は更新作業が発生 
 ◦ コントロールプレーンは自動で上がる
 ▪ ノードとパッチバージョンの差異は目をつむる 
 ▪ CVE やクリティカルなバグ修正が入る場合はノードも上げる 
 • 事前に検証環境で負荷を掛けながら動作確認

19. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 19
 Difficulties in Original Architecture
 • API Gateway クラスターの切り替えに時間が掛かる
 ◦ HAProxy の DNS 切り替えが浸透するまで待つ時間
 ◦ HAProxy の設定ファイルの更新とリロードが手動作業
 • Datastore クラスターの切り替えに時間が掛かる
 ◦ MySQL の移行に工数が掛かる
 ◦ RabbitMQ のメッセージが微妙に残る問題
 ◦ 複雑なサービスディスカバリ
 • アプリケーションの実装に変更はないが QA が必要
 ◦ マニフェストの更新に伴って動作が変わる場合がある

20. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 20
 Current Backend Components
 • API Server
 ◦ ゲームロジックが実装された REST API サーバー
 • Realtime Game Server
 ◦ UDP/TCP でメッセージをやり取り
 ◦ 対戦・協力・チャットルーム
 ◦ Agones で Game Server の管理
 ◦ リアルタイム通信部分は内製のフレームワーク
 • Live Streaming
 ◦ 配信用の UDP リレーサーバー

21. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 21
 Current Architecture

22. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 22
 Current Architecture
 • API Gateway クラスター (廃止)
 ◦ HAProxy とフォワードプロキシをそれぞれ VM に移行
 • API Server クラスター
 ◦ 以前とほぼ変更なし
 ◦ 定期実行のバッチ処理を Misc から移動
 ▪ 複数起動でロック取得できた子が処理 
 ◦ Grafana を各クラスターで起動
 ▪ Cloud SQL バックエンド
 ▪ HAProxy で各クラスターに振り分け 

23. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 23
 Current Architecture
 • Game Server クラスター
 ◦ Agones Controller が SPOF
 ▪ Game Server の台数とライフサイクルの管理 
 ▪ 複数クラスターにして冗長性を担保 
 ▪ 割り当て済みの Game Server に影響はない 
 ◦ Allocator を独自実装
 ▪ Game Server に複数の”部屋”を作る 
 ▪ 部屋を割り当てて接続先を返却 
 ▪ クライアントは部屋に直接接続
 ▪ 部屋の割り当てに失敗したらクライアント側でリトライ 

24. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 24
 Current Architecture
 • Game Server クラスター
 ◦ Live Streaming
 ▪ ゲーム + 配信というコロプラの新しい試み 
 ▪ 複数クラスター構成に現状できない 
 • 配信システムのコンポーネントを冗長化 
 • UDP 接続が不安定な場合に CDN にフォールバック 

25. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 25
 Current Architecture
 • Datastore クラスター (廃止)
 ◦ RabbitMQ (VM)
 ▪ 外部システム依存な処理や非同期処理で利用 
 ◦ MySQL (VM) or TiDB Cloud (MySQL 互換)
 ▪ 利用用途で使い分け
 ▪ MySQL Operator を VM 対応
 ◦ Redis (VM) or Redis Enterprise
 ▪ レスポンスキャッシュ, KVS, ランキング, ... 

26. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 26
 Current Architecture
 • Infra Tools クラスター
 ◦ ArgoCD
 ▪ Helmfile + go-task (Makefile) でマニフェストを生成 
 ▪ GitLab と ArgoCD を連携して GitOps 風 
 ▪ App of Apps で ArgoCD Application を Helm chart 化 
 ◦ Temporal
 ▪ Uber の Cadence からスピンオフ
 ▪ 耐障害性のある状態を持った Workflow エンジン 
 • Azure Durable Functions に似てる 
 ▪ インフラ作業をコード化して実行 

27. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 27
 Current Upgrade Strategy
 • GKE バージョン更新は Surge upgrade
 ◦ Agones の破壊的変更などがなければ
 • GKE の新機能や CA 証明書の更新
 ◦ これまで通りクラスター切り替えで対応
 ◦ 重いクラスターがいないので以前よりは楽なはず...

28. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 28
 Current Upgrade Strategy
 • GKE バージョン更新は Surge upgrade
 ◦ ステートレスなワークロードなら問題なし
 ▪ アプリケーションの展開と挙動は同じ 
 ▪ PDB を正しく設定する
 ◦ K8s に依存する部分の更新は慎重に
 ▪ Agones の更新は最悪切り替えを覚悟 
 ◦ K8s の API バージョンの更新対応はすぐに
 ◦ HAProxy のトラフィック分割の設定は基本的に触らない
 ▪ Canary クラスターから更新
 ◦ 工数が大幅に削減 (2 人月 -> 2 人日)

29. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 29
 Current Upgrade Strategy
 • GKE バージョン更新のワークフローを Temporal + Go で実装
 ◦ コントロールプレーン
 ▪ バージョン更新
 ▪ 更新完了待ち
 ◦ ノードプール
 ▪ Max surge の台数を割合から動的に計算 
 ▪ 自動修復の機能を無効化
 ▪ バージョン更新
 ▪ 更新完了待ち
 ▪ 自動修復の有効化

30. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 30
 Current Upgrade Strategy
 • GKE バージョン更新のワークフローを Temporal + Go で実装
 ◦ 時間指定でワークフローを実行
 ◦ 複数クラスターを順々に更新するワークフローを実行

31. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 31
 Upcoming Major Changes
 • GKE Dataplane v2 (1.20.6-)
 ◦ Cilium によるコンテナネットワークの置き換え
 ◦ eBPF ベースのルーティング、ネットワークポリシーとロギング
 ◦ さようなら kube-proxy
 ◦ 有効にするにはクラスターの再作成が必須
 ▪ クラスター切り替えが必須
 ◦ その他に固有の新機能が登場する可能性

32. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 32
 Other Considerations
 • GKE (Kubernetes) が内部的に使用している証明書の更新
 ◦ CA 証明書の更新とそれに伴う発行済みの証明書の更新
 ◦ GKE における CA 証明書の有効期限は 5 年
 ▪ 有効期限が切れると GKE クラスターが壊れてサービス影響が出る 
 ◦ 証明書の in-place での更新も可能だが...
 ▪ ノードプールが再作成される
 ▪ コントロールプレーンの IP も変わる 
 ▪ kubeconfig の更新
 • Spinnaker などのツール
 • kubectl のクライアントを実行する環境 

33. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 33
 Planned Changes 
 • Container-Optimized OS (COS) への移行
 ◦ Ubuntu のノードイメージの安定性の問題
 ◦ COS でしか使えない機能の登場
 • Compute Engine persistent disk CSI Driver への移行
 ◦ 既存の In-tree GCE PD Volume Plugin も使えるが...
 • Artifact Registry への移行
 ◦ Artifact Registry でしか使えない機能の登場
 • マルチクラスター間通信のネイティブ実装への移行
 ◦ Multi-cluster Services/Gateways

34. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 34
 Summary
 • GKE のノーメンテナンス運用は可能
 ◦ クラスター切り替えと Surge upgrade の使い分け
 ▪ GKE のバージョン更新は基本的に Surge upgrade 
 ▪ GKE の一部の新機能の導入はクラスター切り替え 
 ◦ 運用しながらアーキテクチャを変えられるように
 ▪ 最初から完璧なアーキテクチャを目指さない 
 ▪ コンポーネントは置き換え可能な形で設計 
 ▪ コンポーネントの最新化も短いスパンで定期的に 

35. 　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 35
 We are Hiring!
 • コロプラでは Kubernetes エンジニアを積極採用中です!!
 ◦ GKE, Cloud Spanner を使ったゲームや基盤の開発
 ◦ Kubernetes のエコシステムを含めた Cloud Native への取り組み
 コロプラ　採用 検索 ▼詳しくは https://be-ars.colopl.co.jp/recruit/career/engineer/kubernetes.html