GCP・GKEで作るスケーラブルなゲーム開発環境

GCP・GKE で作るスケーラブルな開発環境

自己紹介植森康友株式会社Aiming 所属のソフトウェアエンジニア主な仕事 Game Web API（Rails） CI
デプロイ Kubernetes/Docker GCPUG 初参加で発表...

Aiming について企画、開発、運営までを社内で行う社内にはPC ゲーム時代からの古参エンジニアが在籍 MMORPG を始めとしたリアルタイムプレイ可能なゲー
ムが得意

代表作剣と魔法のログレスいにしえの女神 CARAVAN STORIES ゲシュタルト・オーディン

アジェンダ以前の開発環境構成以前の開発環境での問題点現在のプロジェクトでの開発環境デプロイフローログインフロー

イントロダクション

ゲームでよくあるサーバ構成データベースにはWebAPI 経由でアクセスリアルタイムサーバにセッションを張ってリアルタイム処理リアルタイムサー
バ同士のやりとりはバックエンドサーバが管理

ゲームでの開発用環境の必要性ゲーム開発では様々な目的で開発用環境が求められるエンジニア、プランナーがプレイして面白さを確認するデザイナーがゲー
ム内でリソースの雰囲気を確認するプランナーが次期アップデートのための設定を行うエンジニアが新規コンテンツの開発を行う外部協力会社にプレイしてもらう etc...

以前の開発環境構成

開発環境構成例

以前の開発環境構成一つの物理サーバに各種サーバが相乗り各物理サーバには様々なリビジョンでデプロイできる接続情報はクライアントに埋め込んであり、接続先を選択できるマスター
データはsamba などを使ってプランナーが直接更新 → いくつかの問題点が発生した

以前の社内環境での問題点

その結果、

以前の社内環境での問題点サーバの数が物理サーバの数に依存している社内のサーバなので簡単に増やせない場合もあるセットアップはゲーム側のエンジニアの手が必要さらにホスト名が固定で用途がわかりにくい環境の追加、
削減にコストが掛かりすぎる社内サーバの空きがない場合は物理サーバの追加が必要社内DNS への登録、DMZ の設定（GIP の数とかも……）だいたいの場合「環境数＜プランナーの数」複数のプランナーで一つの環境を共用することになるどの環境が何の用途で誰が使っているのかの管理が必要 → サーバの台数や環境の数が制約になりスケールしにくかった

あるあるネタ環境追加にひと手間「環境増やしたいです」 → インフラさんに注文「サーバ準備しました」 →
エンジニアがセットアップ環境の更新に待ちが入る「01 環境更新しまーす」「こっちのデータ上げるからちょっとまって」データアップロードのコンフリクト「あれ？なんか設定が反映されてないぞ……」「あ、こっちで同じデータあげちゃった」

エンジニアのローカル開発環境の問題点クライアント、サーバ、Web の各セクションのエンジニアが存在各エンジニアともにVM 上にサーバを構築して開発結果として、
ローカルでも全サーバが動作するよう保守し続ける必要があるクライアントエンジニアもローカルでVM を動かす必要がある

現在のプロジェクトでの開発環境

要件目指すはスケーラブルな開発環境リビジョンをあわせた各サーバをワンセットとしてデプロイするプランナーがマスターデータを手軽に作成・更新できる
物理マシンの数に制約されずに環境数を増減できる

利用したもの

やったこと Kubernetes とdocker によるサーバリソースの抽象化 Kubernetes のAPI を利用したログインフローの構築
helm による環境のパッケージ管理自作デプロイツールとJenkins によるデプロイの実行 Unity のエディタ拡張によるマスターデータアップローダの作成

デプロイフロー

デプロイで利用している関連ツール、サービス GCP のサービス Google Kubernetes Engine
Google Cloud Registory Google Cloud Storage デプロイ Jenkins helm デプロイツール（Rails アプリ）クライアント Unity Unity エディタ拡張

Google Kubernetes Engine Kubernetes はDocker のオーケストレーションツール GKE
はKubernetes のフルマネージドサービス高いスケーラビリティと可用性が特徴 Docker/Kubernetes によるサーバリソースの抽象化バックエンドにGCE を使った自由なノードの増減ロギング、モニタリングなどのGCP サービスとの連携性最初のセットアップの手間がほぼないのも最初はDocker Swarm を使っていたが、運用コストが高かった停電によるswarm のcrash を契機にGKE へ移行

デプロイツール Ruby on Rails 製のWeb アプリ環境管理ツールと各種リンクのダッシュボードを兼ねている
「環境を配膳する人」ということでOKAMI と名付けられた

デプロイツールの機能アカウント、権限管理環境の一覧

デプロイツールの機能クライアントのダウンロード Google Cloud Storage の閲覧

デプロイツールの機能各環境で利用できる各種サービスへのリンク集 WebAPI のswagger UI デバッグツール（Ruby on
Rails アプリ） Cloud Logging

デプロイツールの機能デプロイの実行環境作成時にUUID を使ったID の発行環境情報のDB への永続化実際のデプロイなどはWebAPI 経由でJenkins
ジョブへ

Jenkins ジョブの実行 Unity を使い、AssetBundle とマスターデータを生成 Excel とasset ファイルからsqlite
ファイルを生成している Unity でのみ設定可能なものがあるためUnity を利用 Docker イメージはJenkins Slave で直接ビルドビルドしたイメージはコミットハッシュでタグをつけてGCR へ Helm Chart による環境のデプロイ master ブランチはデイリーで毎日自動更新

Helm Kubernetes のパッケージマネージャ各種リソースをChart と呼ばれる単位でパッケージングする Chart
は公式のものの他に自作することも可能現在のプロジェクトでは専用のdevelop パッケージを自作 kustomize と比較したメリット変数による自由なinjection が可能公開されているchart を使えば自分で書かなくてすむ manifest ファイルの動的な展開が可能デメリットとしては複雑化しやすく、chart の管理などに少しクセがある

Helm の実行コマンドで実行時に変数に対し指定が可能 h e l m u p g
r a d e - - i n s t a l l d e v e l o p - [ 環境I D ] . / d e v e l o p \ - - n a m e s p a c e d e v e l o p - [ 環境I D ] \ - - s e t i m a g e T a g = [ コミットハッシュ] \ - - s e t e n v i r o n m e n t _ i d = [ 環境I D ] \ - - s e t e n v i r o n m e n t _ n a m e = [ 環境名] \ - - s e t r e a l t i m e _ s e r v e r _ r e p l i c a _ c o u n t = 1 - - n a m e p s a c e でインストールするnamespace を指定 - - s e t で環境固有のパラメータを動的に割り当てる

Helm template helm template はgo template で記述 a p i
V e r s i o n : v 1 k i n d : S e r v i c e m e t a d a t a : n a m e : a p i - s e r v e r a n n o t a t i o n s : e n v i r o n m e n t _ n a m e : { { . V a l u e s . e n v i r o n m e n t _ n a m e } } l a b e l s : a p p : a p i - s e r v e r e n v i r o n m e n t _ i d : { { . V a l u e s . e n v i r o n m e n t _ i d } } ここでは環境名と環境ID をlabel とannotation にinjection している → 後述するログインフローで利用するため

環境数のスケール Kubernetes のnamespace を利用することで柔軟にスケール可能環境の最大数は、「ノードのスペック☓
ノードの台数 / 環境あたりの利用リソース」 GKE の場合、ノードのバックエンドにGCE を利用しているためリソースを簡単に追加可能現在は5 台のノードで10～15 環境以上が稼働。以前から比べるとホスト台数の3 倍以上が稼働可能になった

Unity 統合開発環境を内蔵したクロスプラットフォームなゲームエンジン Unity は自前でスクリプトを書いてエディタを拡張することが可能 Unity 上からマスターデータの生成と、GCS
へのアップロードを行えるようにしている

Unity Editor 拡張プランナーはこのエディタ拡張を利用し、Excel やUnity で設定を行った後にマスターデータをビルド
アップロードしたい環境を選択してデータをアップロードする

ログインフロー

Ruby によるKubernetes マスタへの問い合わせ https://github.com/abonas/kubeclient を利用 s e l e c
t o r = s e l e c t o r s . m a p { | k , v | " # { k } = # { v } " } . j o i n ( ' , ' ) c l i e n t . g e t _ s e r v i c e s ( l a b e l _ s e l e c t o r : s e l e c t o r ) . m a p d o | s e r v i c e | O p e n S t r u c t . n e w ( # l a b e l から環境I D を取得 e n v i r o n m e n t _ i d : s e r v i c e . d i g ( : m e t a d a t a , : l a b e l s , : e n v i r o n m e n t _ i d ) , # a n n o t a t i o n から環境名を取得 e n v i r o n m e n t _ n a m e : s e r v i c e . d i g ( : m e t a d a t a , : a n n o t a t i o n s , : e n v i r o n m e n t _ n a m e ) , # s e r v i c e の基本情報からL B のI P と割り当てP o r t を取得 i p : s e r v i c e . d i g ( : s t a t u s , : l o a d B a l a n c e r , : i n g r e s s , 0 , : i p p o r t : s e r v i c e . d i g ( : s p e c , : p o r t s , 0 , : p o r t ) ) e n d

クライアントの環境選択 WebAPI が返した環境情報を元にプルダウンメニューを表示選択した環境のエンドポイント情報を自動で選択する

こうしてスケーラブルな開発環境ができた

以前の開発環境よりも改善された点プランナーが自由に環境を増やすことができるようになったノードの追加だけでスケールするようになった社内からGCP への移行によりリソースの増減が柔軟になったエンジニアの作業フロー
も変化クライアントエンジニアもGCP 上のサーバを利用するようにデプロイ・ログインして動作確認して削除するなどが可能に GCP、GKE を利用した仕組みづくりによって、エンジニア・プランナーの作業フローが格段に改善された

今後の課題 Jenkins のGCP への移行社内にあるためにスレーブの追加が一手間 Unity のためにMac が必須となっており簡単に移行できない Docker
ビルドのGoogle Cloud Build への移行一台のスレーブで全イメージを並列ビルドしているため遅い Jenkins Slave がDocker ビルドに専有されるうまく行った点の社内への共有他プロジェクトでも再利用できる点は多いハズ

まとめ " 開発環境がスケールすることで開発もスケールできる"

ご静聴ありがとうございました

GCP・GKEで作るスケーラブルなゲーム開発環境

GCP・GKEで作るスケーラブルなゲーム開発環境

Transcript

More Decks by Yasutomo Uemori

Other Decks in Programming

Featured