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

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

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

　　　　　　　　　 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 

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

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

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

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

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

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

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

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

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

　　　　　　　　　 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 つのマイナーバージョンまで離れても動作可 

　　　　　　　　　 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

　　　　　　　　　 COLOPL, Inc. All Rights Reserved｜CONFIDENTIAL 16  GKE Release Channel 
• Release channel を使用するとノードも強制的に自動更新  ◦ ノードの自動更新をオフにできない  ◦ Google Cloud の推奨する更新方法  • クラスターの更新時刻はメンテナンスウィンドウで指定可能  ◦ 32 日間で 48 時間以上確保が必要  ◦ クラスターの更新順序を明示的に指定不可  ◦ メンテナンスの除外設定もあるにはあるが制限がある  ◦ 開発/本番環境で release channel を変えることを推奨  • ノーメンテナンスで Release channel を使うのは怖い... 

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

　　　　　　　　　 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 やクリティカルなバグ修正が入る場合はノードも上げる   • 事前に検証環境で負荷を掛けながら動作確認 

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

　　　　　　　　　 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 リレーサーバー 

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

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

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

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

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

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

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

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

• GKE バージョン更新のワークフローを Temporal + Go で実装  ◦ 時間指定でワークフローを実行  ◦ 複数クラスターを順々に更新するワークフローを実行 

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

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

　　　　　　　　　 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 

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

　　　　　　　　　 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

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

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

More Decks by Tsubasa Nagasawa

Other Decks in Programming

Featured

Transcript