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

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の実行
コマンドで実行時に変数に対し指定が可能
helm upgrade --install develop-[環境ID] ./develop
--namespace develop-[環境ID]
--set imageTag=[コミットハッシュ]
--set environment_id=[環境ID]
--set environment_name=[環境名]
--set realtime_server_replica_count=1
--namepsace でインストールするnamespaceを指定
--set で環境固有のパラメータを動的に割り当てる

49. Helm template
helm templateはgo templateで記述
apiVersion: v1
kind: Service
metadata:
name: api-server
annotations:
environment_name: {{ .Values.environment_name }}
labels:
app: api-server
environment_id: {{ .Values.environment_id }}
ここでは環境名と環境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 を利用
selector = selectors.map{|k, v| "#{k}=#{v}"}.join(',')
client.get_services(label_selector: selector).map do |service|
OpenStruct.new(
# labelから環境IDを取得
environment_id: service.dig(
:metadata,
:labels,
:environment_id
),
# annotationから環境名を取得
environment_name: service.dig(
:metadata,
:annotations,
:environment_name
),
# serviceの基本情報からLBのIPと割り当てPortを取得
ip: service.dig(:status, :loadBalancer, :ingress, 0, :ip
port: service.dig(:spec, :ports, 0, :port)
)
end

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

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

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

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

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

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