EC2からFargate+ECSへの道のり/ EC2 to ECS And Fargate

Amazon Game Tech Conference 2021
https://gamingtechnight.connpass.com/event/208653/

Transcript

1. EC2からECS+Fargate
 構成への道のり
 Amazon Game Tech Conference 2021
 ワンダープラネット株式会社 
 堤 孝広

2. 自己紹介
 ワンダープラネット株式会社
 タノシムスタジオ 開発グループ長 
 
 堤 孝広 (つつみ たかひろ)
 
 
 
 • 2009年からゲームサーバーの開発とインフラ(AWS)運用を担当 
 • 国内・海外のゲームアプリのサーバーリードを複数経験 
 

3. 楽しいね!を、世界中の日常へ。 
 ワンダープラネット株式会社 
 会 社 紹 介
 Company Material 

4. （C）WonderPlanet Inc. All Rights Reserved. （C）WonderPlanet Inc. All Rights Reserved. 会社概要
 名　称 ワンダープラネット株式会社　/ WonderPlanet Inc. 
 
 　　　 　　 ［名古屋本社］　 愛知県名古屋市中区錦3-23-18　ニューサカエビル5F 
 　　 　　 ［東京オフィス］ 東京都品川区東五反田5-23-7 五反田不二越ビル5F 
 
 楽しいね！を、世界中の日常へ。 
 
 事業 エンターテインメントサービス事業 
 
 設　立 2012年9月3日（10月1日創業） 
 
 代表者 代表取締役社長CEO 常川 友樹 
 
 従業員 198名（2021年2月末時点） 
 名称 所在地 ミッション 事業内容 設立 代表者 従業員数
5. （C）WonderPlanet Inc. All Rights Reserved. ミッション
 楽しいね!を、
 
 世界中の
 
 日常へ。
 私たちの使命は、世界中の一人でも多くの人々の日常に、家族や友達と「楽しいね！」と笑いあえるひとときを届け ることです。
 
 国・言語・文化・年齢・性別などあらゆる壁を越えて誰もが楽しめるプロダクト・サービスを創り、コミュニケーションを 通じた「笑顔」を世界の隅々まで広げていきます。

6. コーポレートサイト
 https://wonderpla.net/

7. 今回の発表について
 この発表では、これまでEC2をメインに運用してきた弊社が、
 
 • ECS+Fargateの導入に至った経緯
 • ECS+Fargate導入のポイント
 • ECS+Fargate運用の実情
 • ECS+Fargateを導入・運用してみた所感
 
 を紹介します

8. ECS+Fargateの導入に至った経緯

9. 背景 - 弊社のインフラ運用
 • 長期にわたるEC2での運用実績
 ◦ AutoScalingを利用した需要に応じたスケール 
 ◦ リザーブドインスタンスやスポットインスタンスを使ったコスト削減 
 
 • サーバーアプリ開発担当者とインフラ担当者が同一
 ◦ ひとくくりにサーバーチームの責務の分担になっている 
 

10. 課題1. インフラ運用にあたって考えることが沢山ある
 • リクエスト増加に対応するスケーリングの手動実行
 ◦ push通知や運営施策によって急激にリクエスト数が変動する 
 
 • AMIの管理
 ◦ デプロイ時のAMIのスナップショット管理 
 ◦ 使わなくなったAMIのメンテナンス 
 
 • EC2インスタンスタイプの検討
 ◦ 台数xスペックx料金のパラメータ 
 ◦ 新規インスタンスタイプの利用検討 

11. 課題2. ミドルウェアのバージョン管理が大変
 • 本番環境のMWバージョンを変えるのはコストがかかる
 ◦ 動作検証をステップにしたがってしっかりと行う必要がある 
 
 • 環境間でMWバージョン差異が発生してしまうケースも
 ◦ 例：検証環境と本番環境でRubyのバージョンが異なる 
 ◦ 検証環境で動作するが本番環境で動作しないなどの事故が発生するリスクあり 

12. つまるところ...

13. 
 インフラ管理の工数を削減して
 開発・運用に集中したい！

14. コンテナ運用の導入を検討
 
 
 • なぜコンテナ？
 ◦ AMIの管理が不要になりそう
 ◦ 環境間のMWバージョン差異を無くせそう 
 

15. コンテナ運用にあたってのAWSでの選択肢
 • Amazon ECS + Amazon EC2
 ◦ ECSでコンテナをデプロイし、コンテナ実行環境はEC2で構築 
 
 • Amazon ECS + AWS Fargate
 ◦ ECSでコンテナをデプロイし、コンテナ実行環境はFargateが管理 
 
 • Amazon EKS
 ◦ Kubernetesでコンテナをデプロイする 

16. コンテナ運用にあたってのAWSでの選択肢
 
 • Amazon ECS + Amazon EC2
 ◦ ECSでコンテナをデプロイし、コンテナ実行環境はEC2で構築 
 
 • Amazon ECS + AWS Fargate → 採用
 ◦ ECSでコンテナをデプロイし、コンテナ実行環境はFargateが管理 
 
 • Amazon EKS
 ◦ Kubernetesでコンテナをデプロイする 

17. ECS+Fargateを選んだ理由
 • EKSは学習コストが高いと感じた
 ◦ リリースまで6ヶ月
 ◦ Kubernetesに詳しいメンバーがいなかった 
 
 • ECS+Fargateは管理が簡単そう！！
 ◦ インスタンスのリソ ースを意識せずにスケーリングができる 
 ◦ コンテナのデプロイはECSに任せる 

18. つまりECS+Fargateの導入でいろいろ解決できる
 課題1. インフラ運用にあたって考えることが沢山ある
 → FargateでEC2インスタンスやスケールの検討時間を排除
 
 
 
 課題2. ミドルウェアのバージョン管理が大変
 → ミドルウェアの管理をコンテナにまかせる
 
 
 

19. ECS+Fargate導入のポイント

20. ポイント1/5: Dockerfileの作成
 • まずはアプリケーションのコンテナ化に集中して取り組む
 ◦ つまりDockerfileを作成する
 ◦ まずは動かすことを目標に標準的なベースイメージを選ぶと良い 
 →チューニングはあとでも大丈夫 
 
 • 1つのコンテナで1つのプロセスにする
 ◦ コンテナを別にすることで、プロセスごとにスケールすることが可能に 
 ◦ ログをプロセスごとに分離することができる 

21. ポイント2/5: イメージサイズのチューニング
 • イメージサイズがデプロイ時間・コスト・スケールの速度に影響する
 → サイズが小さい方がうれしい
 
 • Docker Docsのベストプラクティスに則って「不要なパッケージの削除」「レイ ヤの数を最小に」を実施
 
 
 ◦ Dockerfile のベストプラクティス
 
 • 弊社の場合は1309MB→450MBまで減少

22. ポイント3/5: ログの保存方法
 • コンテナを動かす場合、ログの扱 いを工夫の必要あり
 
 • ログ出力先をローカルファイルか ら標準出力へ変更
 
 • ECSのログドライバーに awslogs を設定してCloudWatchLogsに転 送
 

23. ポイント4/5: イメージリポジトリにECRを利用
 • Amazon ECRはコンテナイメージを 登録・管理できるリポジトリ
 ◦ プライベート管理もできる
 
 • ECRのコンソールページに表示さ れる「プッシュコマンドの表示」を 参考に登録
 
 

24. ポイント5/5: ビルドパイプラインの自動化
 
 • AWS CodeBuildを使ってGitHubからコードを取得してコンテナイメージをビ ルド
 • さらにビルドしたコンテナイメージをECRへ登録

25. ポイント5/5: ビルドパイプラインの自動化
 
 • AWS CodeBuildを使ってGitHubからコードを取得してコンテナイメージをビ ルド
 • さらにビルドしたコンテナイメージをECRへ登録
 イメージのタグをGitHubのコミットハッシュに することで、どのコミット時点のイメージかがわ かるように工夫
26. 導入に当たって上記のようなポイントがある
 • 未経験の現場でも本当に導入できるのか？
 
 • 弊社も同じく不安がありました

27. 安心してください！〜コンテナハンズオンの開催
 • コンテナ化を検討し始めた初期にAWSさんにコンテナハンズオンを開催し てもらえた
 
 • コンテナとは何か〜コンテナサービスの入門、まで一通りどういったものか を学習できた

28. ECS+Fargate運用の実情

29. スケールをさくさく変更する
 • リリース直後はアクセスのスパイクに備えて十分なタスクを用意
 
 • リリース当日中に負荷を見ながらスケールをリアルタイムに変更
 

30. スケール変更の実際の方法
 • コンソールのECSで「必要なタスクの数」を更新するだけ!

31. ログの性質に応じて収集・確認方法を分けた
 • 緊急度の高いエラーログはAuroraに保存
 ◦ CloudWatchLogsの分析になれていなかった 
 ◦ 管理ページからAuroraに接続しており、すぐにエラー詳細を調べられるため 

32. インスタンスタイプを検討する行為がなくなった
 • アプリに適しているファミリータイプの検討
 
 • 新しいインスタンスタイプへの乗り換えの検討
 
 • ただしvCPUとMemoryの組み合わせの検討は必要

33. コンテナへミドルウェア追加が発生・スムーズに対応
 • ファイルタイプを判別するミドルウェアが必要になった
 
 • Dockerfileにミドルウェアをインストールするコードを追加
 
 • 検証環境でデプロイして確認→本番環境でデプロイ
 ◦ 問題なく本番で動かすことができた! 
 ◦ ミドルウェアのアップデートもアプリのデプロイと同じ感覚でできる! 

34. ECS+Fargateを
 導入・運用してみた所感

35. インフラであれこれ考えるコスト(運用工数)が少なくなった
 • AMIの管理やインスタンスタイプを検討することから開放
 
 • 管理や検討していた時間を開発に使えるようになった！

36. コスト(料金)に関しての比較と考察
 • コスト比較(2vCPU, 4GB)
 ◦ EC2(c5.large): 0.107$/時間
 ◦ Fargate: 0.12324$/時間
 
 • 考察
 ◦ 単純な比較ではコスト増だが、かわりに管理コストが減る 
 ◦ 開発に集中することでプロダクトの品質向上に繋がる 
 ◦ FargateはvCPUとMemoryの組み合わせが柔軟なためコスト削減の余地がある 
 ＊リージョンはアジアパシフィック(東京)を参照(2021/04時点)

37. 環境間のMWバージョンが自然と統一されるようになった
 • 差分がなくなることで、検証環境では動くのに本番環境では動かない、と いったリスクから開放
 
 • ばっちり差分がなくなるので安心できるようになった
 
 

38. 実際に6ヶ月で導入・運用してみてどうだったか？
 • 導入期間中はEC2と運用の感覚が異なる点で苦労
 ◦ sshができないことでログの調査がCloudWatchLogsに変わった 
 ◦ デプロイのたびにビルドしなおすため、デプロイ時間自体は長くなった 
 
 • 運用をはじめてEC2を管理しなくなり楽になったことを実感

39. 今後考えていること
 • さらなる自動化
 ◦ AWSコンソールからのデプロイ作業 
 →AWS CodeDeployを利用してデプロイの自動化 
 ◦ 負荷ベースのオートスケール
 →AutoScalingを設定
 ◦ ログをフィルタリングしてコストを削減するためにFireLensを導入 
 
 • ECS+Fargate構成は社内他プロジェクトでの利用を検討
 ◦ PHPベースのプロジェクトでも大部分の知見を流用できる 

40. まとめ

41. まとめ
 • ECS+Fargateの導入事例を紹介
 ◦ 弊社の事情と導入に至った経緯 (サーバーアプリ/インフラエンジニアが同一) 
 ◦ 導入あたってのポイント5つ
 
 • Fargateを使ってみた実情
 ◦ 運用がとてもシンプルになる
 ◦ EC2インスタンスタイプやAMIの管理が不要になる 
 ◦ インフラ運用・検討コストを開発のリソースにまわせる 
 
 • 今後は社内の他プロジェクトでも利用を検討
 

42. ありがとうございました!