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

GCPUG Kansai Summit Day 2018での登壇スライドです
https://gcpug-osaka.connpass.com/event/103023/

Transcript

1. GCP・GKE で作る スケー ラブルな開発環境
2. 自己紹介 植森 康友 株式会社Aiming 所属のソフトウェアエンジニア 主な仕事 Game Web API（Rails） CI デプロイ Kubernetes/Docker GCPUG 初参加で発表...
3. Aiming について 企画、 開発、 運営までを社内で行う 社内にはPC ゲー ム時代からの古参エンジニアが在籍 MMORPG を始めとしたリアルタイムプレイ可能なゲー ムが得意
4. 代表作 剣と魔法のログレス いにしえの女神 CARAVAN STORIES ゲシュタルト・ オー ディン
5. アジェンダ 以前の開発環境構成 以前の開発環境での問題点 現在のプロジェクトでの開発環境 デプロイフロー ログインフロー
6. イントロダクション
7. ゲー ムでよくあるサー バ構成 デー タベー スにはWebAPI 経由でアクセス リアルタイムサー バにセッションを張ってリアルタイム処理 リアルタイムサー バ同士のやりとりはバックエンドサー バが管理
8. ゲー ムでの開発用環境の必要性 ゲー ム開発では様々 な目的で開発用環境が求められる エンジニア、 プランナー がプレイして面白さを確認する デザイナー がゲー ム内でリソー スの雰囲気を確認する プランナー が次期アップデー トのための設定を行う エンジニアが新規コンテンツの開発を行う 外部協力会社にプレイしてもらう etc...
9. 以前の開発環境構成
10. 開発環境構成例
11. 開発環境構成例
12. 開発環境構成例
13. 開発環境構成例
14. 開発環境構成例
15. 以前の開発環境構成 一つの物理サー バに各種サー バが相乗り 各物理サー バには様々 なリビジョンでデプロイできる 接続情報はクライアントに埋め込んであり、 接続先を選択できる マスター デー タはsamba などを使ってプランナー が直接更新 → いくつかの問題点が発生した
16. 以前の社内環境での問題点
17. 以前の社内環境での問題点
18. 以前の社内環境での問題点
19. その結果、
20. 以前の社内環境での問題点 サー バの数が物理サー バの数に依存している 社内のサー バなので簡単に増やせない場合もある セットアップはゲー ム側のエンジニアの手が必要 さらにホスト名が固定で用途がわかりにくい 環境の追加、 削減にコストが掛かりすぎる 社内サー バの空きがない場合は物理サー バの追加が必要 社内DNS への登録、DMZ の設定（GIP の数とかも……） だいたいの場合「 環境数＜ プランナー の数」 複数のプランナー で一つの環境を共用することになる どの環境が何の用途で誰が使っているのかの管理が必要 → サー バの台数や環境の数が制約になりスケー ルしにくかった
21. あるあるネタ 環境追加にひと手間 「 環境増やしたいです」 → インフラさんに注文 「 サー バ準備しました」 → エンジニアがセットアップ 環境の更新に待ちが入る 「01 環境更新しまー す」 「 こっちのデー タ上げるからちょっとまって」 デー タアップロー ドのコンフリクト 「 あれ？ なんか設定が反映されてないぞ……」 「 あ、 こっちで同じデー タあげちゃった」
22. エンジニアのロー カル開発環境の問題点 クライアント、 サー バ、Web の各セクションのエンジニアが存在 各エンジニアともにVM 上にサー バを構築して開発 結果として、 ロー カルでも全サー バが動作するよう保守し続ける必要がある クライアントエンジニアもロー カルでVM を動かす必要がある
23. 現在のプロジェクトでの開発環境
24. 要件 目指すはスケー ラブルな開発環境 リビジョンをあわせた各サー バをワンセットとしてデプロイする プランナー がマスター デー タを手軽に作成・ 更新できる 物理マシンの数に制約されずに環境数を増減できる
25. 利用したもの
30. やったこと Kubernetes とdocker によるサー バリソー スの抽象化 Kubernetes のAPI を利用したログインフロー の構築 helm による環境のパッケー ジ管理 自作デプロイツー ルとJenkins によるデプロイの実行 Unity のエディタ拡張によるマスター デー タアップロー ダの作成
31. デプロイフロー
32. デプロイで利用している関連ツー ル、 サー ビス GCP のサー ビス Google Kubernetes Engine Google Cloud Registory Google Cloud Storage デプロイ Jenkins helm デプロイツー ル（Rails アプリ） クライアント Unity Unity エディタ拡張
33. Google Kubernetes Engine Kubernetes はDocker のオー ケストレー ションツー ル GKE はKubernetes のフルマネー ジドサー ビス 高いスケー ラビリティと可用性が特徴 Docker/Kubernetes によるサー バリソー スの抽象化 バックエンドにGCE を使った自由なノー ドの増減 ロギング、 モニタリングなどのGCP サー ビスとの連携性 最初のセットアップの手間がほぼないのも 最初はDocker Swarm を使っていたが、 運用コストが高かった 停電によるswarm のcrash を契機にGKE へ移行
37. デプロイツー ル Ruby on Rails 製のWeb アプリ 環境管理ツー ルと各種リンクのダッシュボー ドを兼ねている 「 環境を配膳する人」 ということでOKAMI と名付けられた
38. デプロイツー ルの機能 アカウント、 権限管理 環境の一覧
39. デプロイツー ルの機能 クライアントのダウンロー ド Google Cloud Storage の閲覧
40. デプロイツー ルの機能 各環境で利用できる各種サー ビスへのリンク集 WebAPI のswagger UI デバッグツー ル（Ruby on Rails アプリ） Cloud Logging
41. デプロイツー ルの機能 デプロイの実行 環境作成時にUUID を使ったID の発行 環境情報のDB への永続化 実際のデプロイなどはWebAPI 経由でJenkins ジョブへ
44. Jenkins ジョブの実行 Unity を使い、AssetBundle とマスター デー タを生成 Excel とasset ファイルからsqlite ファイルを生成している Unity でのみ設定可能なものがあるためUnity を利用 Docker イメー ジはJenkins Slave で直接ビルド ビルドしたイメー ジはコミットハッシュでタグをつけてGCR へ Helm Chart による環境のデプロイ master ブランチはデイリー で毎日自動更新
47. Helm Kubernetes のパッケー ジマネー ジャ 各種リソー スをChart と呼ばれる単位でパッケー ジングする Chart は公式のものの他に自作することも可能 現在のプロジェクトでは専用のdevelop パッケー ジを自作 kustomize と比較したメリット 変数による自由なinjection が可能 公開されているchart を使えば自分で書かなくてすむ manifest ファイルの動的な展開が可能 デメリットとしては複雑化しやすく、chart の管理などに少しクセがある
48. 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 で環境固有のパラメー タを動的に割り当てる
49. 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 している → 後述するログインフロー で利用するため
52. 環境数のスケー ル Kubernetes のnamespace を利用することで柔軟にスケー ル可能 環境の最大数は、 「 ノー ドのスペック☓ ノー ドの台数 / 環境あたりの利用リソー ス」 GKE の場合、 ノー ドのバックエンドにGCE を利用しているためリソ ー スを簡単に追加可能 現在は5 台のノー ドで10～15 環境以上が稼働。 以前から比べるとホスト台数の3 倍以上が稼働可能になった
54. Unity 統合開発環境を内蔵したクロスプラットフォー ムなゲー ムエンジン Unity は自前でスクリプトを書いてエディタを拡張することが可能 Unity 上からマスター デー タの生成と、GCS へのアップロー ドを行 えるようにしている
55. Unity Editor 拡張 プランナー はこのエディタ拡張を利用し、Excel やUnity で設定を行 った後にマスター デー タをビルド アップロー ドしたい環境を選択してデー タをアップロー ドする
56. ログインフロー
60. 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
61. クライアントの環境選択 WebAPI が返した環境情報を元にプルダウンメニュー を表示 選択した環境のエンドポイント情報を自動で選択する
68. こうしてスケー ラブルな開発環境ができた
69. 以前の開発環境よりも改善された点 プランナー が自由に環境を増やすことができるようになった ノー ドの追加だけでスケー ルするようになった 社内からGCP への移行によりリソー スの増減が柔軟になった エンジニアの作業フロー も変化 クライアントエンジニアもGCP 上のサー バを利用するように デプロイ・ ログインして動作確認して削除するなどが可能に GCP、GKE を利用した仕組みづくりによって、 エンジニア・ プランナー の作業フロー が格段に改善された
70. 今後の課題 Jenkins のGCP への移行 社内にあるためにスレー ブの追加が一手間 Unity のためにMac が必須となっており簡単に移行できない Docker ビルドのGoogle Cloud Build への移行 一台のスレー ブで全イメー ジを並列ビルドしているため遅い Jenkins Slave がDocker ビルドに専有される うまく行った点の社内への共有 他プロジェクトでも再利用できる点は多いハズ
71. まとめ " 開発環境がスケー ルすることで開発もスケー ルできる"
73. ご静聴ありがとうございました