本記事はサムザップ #1 Advent Calendar 2019の初日の記事です。
ゲーム開発においてどんな環境で開発を行っているのかを少し紹介できたらなと思います。
本題に入る前に
初日の投稿ということで少し会社のことを紹介させていただきます。
私の所属しているサムザップは2009年に設立した会社で、サイバーエージェントの子会社になります。
スマートフォンゲームの企画・運営・配信事業を行っている会社で、先日このファン
の事前登録を開始しました。興味がありましたらぜひ登録お願いします。
私自身は現在SREチームに所属しており、システムの構築・改善・効率化などを主に行っております。
ということで前置きはこのくらいにして
早速....
タイトルで上げている内容に移っていきます。
前提
・ インフラ歴2半年
・ GCP歴2年
・ 新規プロジェクト始動時にアサイン
・ AWSは今回初挑戦!!
・ 基本的にterraformで構築
・ 実装期間(作業時間ベース)2週間くらい
目指したこと
・ とりあえずコンテナ使いたいよね
・ 2017年のアドベントカレンダーでAWSちょっとさわった時のノウハウを使う
・ なるべくコストは抑えたい(みんなそうだよね 
)
・ 今どきっぽいデプロイしたいよね
構築したデプロイの流れ
今回作成したデプロイシステムは主に2種類あります。
- gitへのpushを契機に開発環境を自動生成
- slackから固定環境へのデプロイ
1.のシステム
まず1. のシステムから説明してきます。
今回はデプロイ周りをメインに紹介したいので、各リソースの作成は予め行っている前提で話を進めます。
開発環境の構成は下記の図のようになっています。
構成だけ見るとめっちゃシンプルですね
上記環境に対してデプロイを行う処理の流れは以下です。
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
1-1. githubへの特定リポジトリの特定ブランチ(feature/dev-〇〇)をCodeBuildでhook。
1-2. 特定ブランチ内のbuildspec.ymlを読み込んでユニットテスト実行
1-3. ユニットテストが成功したらイメージを作成
1-4. 作成されたイメージをECRにPUSH
1-5. DBの作成とマイグレーション
1-6. TerraformでLBのターゲットグループとFargateのサービスを作成
※ DBは予めAuroraを1クラスター立てておき、その中でブランチ名をサフィックスにしてDBを作成しています。
※ Cacheは予めElastiCacheを1クラスター立てておき、キャッシュキーにブランチ名をサフィックスとして保存しています。
2.の構成
次に2. のシステムを説明します。
デプロイを行う環境自体は1.の構成と変わりありませんが、別環境を用意します。
デプロイを行う処理の流れは以下です。
図がカオス
2-1. slackからスラッシュコマンドを発行
2-2. API Gateway①を通してLambda①を起動
2-3. Lambda①が対象のCodePipelineを起動
2-4. CodePipelineがgithubからソースを取得
2-5. ソースの取得が終わったらCodeBuildを起動し、イメージ作成+ECRへPUSH
(ここでDBのマイグレーションも行っている)
2-6. イメージの作成が終わったらCodeDeployが起動しBlue Greenデプロイ開始
2-7. 再ルーティング待ち状態をCloud Watch Eventsで拾ってLambda(2)を起動
2-8. Lambda②からslackに通知
2-9. デプロイが正しいかテストを行い「再ルーティング」か「ロールバック」かを選択
2-10. 選択結果をAPI Gateway②が拾いLambda③を起動
2-11. lambda③がCodedeployのステータスを変更する
パイプラインは現在ステージが3つ
slackでの実行結果はこのようになります。
まとめ
今回は使用状況に合わせて2つのデプロイシステムを構築しました。
1.のシステムは開発の初期段階から導入をしています。
デプロイ周りの実装は今まで優先順位が低くなりがちで開発後期に回されることが多かったですが、はじめにしっかり設計することでかなり効率的に開発を進めることができています。もしこのあたりの実装を後回しにしていたり、そもそも自動化されていないシステムで運用しているところがあるならば、かなりの工数をロスしていることになります。ぜひ参考にしていただき取り入れていただきたいです。
2.のシステムは固定環境構築時に合わせて実装したデプロイシステムです。
どのような環境かというと例えばアプリをストアに申請する際に使用する環境とか、プロモーションなどで使用する環境です。このような環境はアクセス先を固定化する必要があるので動的に環境を構築するのではなく、必要な時に必要なアップデートを対象の環境に行う必要があります。またステージング環境や本番環境もこちらに属しますね。こういった環境のデプロイもアプリ開発においてはとても多く、またミスも許されない状況が多いです。なのでシステム化をしっかりしてミスを無くすと共に、slackから手軽にデプロイできる仕組みはとても有効だと思います。
今後の改善
上記で上げているようなデプロイの仕組みが既に開発フローとして定着しつつあります。
ただ、これで完成！！！ということではなく、やはりまだまだ改善しなくてはいけない点は多々あります。
本番までには対応しないとなとざっくり思っていることを下記に上げて今回はしめたいと思います。
・ CodeBuildの処理高速化
-> 毎回デプロイするのに5分以上かかっている
こちらの原因はいろいろ合って、対応手段もあるのですが、1つ大きな原因だけ上げておきます。
現在のプロジェクトがPHPを使用しているためCodeBuild上でイメージを作成する際にcomposer installを行っているのですが、イメージを作成後にmigrationをするためにCodeBuildが入っているサーバでもcomposer installを走らせています。つまり時間のかかる処理が2重に走っていることになります。ここだけ解消するだけでもかなり時間を短縮できると思います。なので作成したイメージを使ってdocker runからのexecでmigrationする方法に変更対応を入れるつもりです。
・ slackのスラッシュコマンドをボットに変更
-> slackのスラッシュコマンドでは3つほど問題があります。
1. デプロイ可能ユーザを制限できない(頑張れば可能だが) - ボット化してデプロイできるチャンネルを制限
2. レスポンスタイムアウトが3秒である - そのためエラーメッセージが出る
3. インタラクティブメッセージが使えない - ボタンが使えない、選択ボタンが消えない
この辺は最初から分かっていたことですが、ボットを作っている工数が無かったのでスラッシュコマンドで済ませてしまった感じです。機能は揃っているので開発には問題ないですが、ステージング環境以降はユーザ制限やミス防止は必須ですので、取り入れて行こうと思います。
参考
ECSでCodeDeployを使用したBlue/Green Deploymentがサポートされたので早速試してみた
AWS CodePipeline で ECS(Fargate) へ Blue/Green デプロイする
CodePipelineのステータスをSlackへ通知
slack スラッシュコマンドでaws cliを実行させる方法
明日は @ozaki_shinya の記事です。