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

by Tsubasa Nagasawa

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

　　　　　　　　　 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 

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

　　　　　　　　　 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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

　　　　　　　　　 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, ランキング, ...  

Slide 26

Slide 26 text

　　　　　　　　　 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 に似てる   ■ インフラ作業をコード化して実行  

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

　　　　　　　　　 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 

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

　　　　　　　　　 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