JAWS-UG コンテナ支部 #15 - Amazon ECSの開発環境を動的に管理するツールを作ってみました

PRごとに専用のECS環境を動的に作成、削除できるツールを紹介します。作成経緯や社内での活用について紹介し、今後のロードマップやOSS化について話します。また、サイバーエージェントのインフラ周りのツールのOSS化プロジェクトについて紹介します。

Torgayev Tamirlan (@prog893) - クラウド技術アドバイザ, サイバーエージェント 技術本部 サービスリライアビリティーグループ

Transcript

1. Amazon ECSの開発環境を動的に
 管理するツールを作ってみました 株式会社サイバーエージェント 技術本部 サービスリライアビリティグループ クラウド技術アドバイザ Torgayev Tamirlan (@prog )
2. ⾃⼰紹介 • 2018年 サイバーエージェント新卒⼊社 • Cloud Technologies Advisor ＝ (SA+SRE+DevOps+Infra) / • AWA、REQU、タップル誕⽣、
 CROSSMEなど担当 • 好きなもの: Terraform、Python、 Elasticsearch、Serverless ❤ • 好きなAWSのサービス: ECS Torgayev Tamirlan @prog
3. よく⾒る流れの話をします
4. ECSを導⼊します
5. ECSを導⼊ • ECS簡単じゃん、楽じゃん、最⾼ • 導⼊してみよう • ええ感じやし、このままオンプレからAWSに移設しよう！ • わーい＼(^o^)∕
6. わーい＼(^o^)∕
7. 移設します
8. 移設が終わります
9. ECSでの本格的な
 チーム開発が始まります
10. チーム開発 • localでfeature作った！ • リアルなDBとか周辺サービスとつなぎこんで、
 AWS上でどう動くかマージする前に確認したい • x ⼈ • さらにiOS/Androidのdevアプリで動き⾒たい
11. でも開発環境は1つだけ！
12. どうすれば複数の開発タスクを
 同時に進めるんだよ
13. 理想 • A/B testing (Feature Flags)、microservices、、etc. • ⼤きなアーキテクチャ変更... • いきなり導⼊するの難しい
14. 現実：devxx⽅式 • オンプレ、VPS、EC などではよくみるアレ • 同じdev環境を複数⽤意 • dev , dev , ..., devxx • これを「devxx⽅式」と私が勝⼿に呼んでます
15. 開発レーンが増える
16. 「あっ、dev は私が使ってるから 触らないで」
17. dev環境がまた増える
18. dev環境がまた増える 眠れない夜 疲労 涙 割り当て表管理 原始的コミュニケーション コンフリクト 残業 ⼿動デプロイ 汗 prodまでのlead time延⻑ dev環境がまた増える イライラ Apply Failed dev環境10以上 誰も知らないエンドポイント 腐る環境 余分なコスト Toil 設定差分 Build Failed ※イメージです
19. ∕(^o^)＼
20. Problem • 移設したのはいいが、
 クラウドとアプリケーションの
 稼働プラットフォームが変わっただけで、
 チームとメンバーの意識や開発スタイルは何⼀つ変わっていない
21. devxx ⽅式について考える
22. devxx ⽅式のメリット • オンプレ、VPS、物理サーバ運⽤経験者にとって学習コスト低い • 横に全く同じサーバを⼀時的に増やして、Ansible的なのを流してDNS設定するだけ • 使ってないサーバはシャットダウンしておくなど • 使ってない環境のサーバはシャットダウンしてあればコストがかからない • 導⼊コスト低 • Feature Flagなどではないので環境を横でつくるだけ • コードの修正もいらない • ⼀つ⼀つの環境が完全に分離されている
23. devxx ⽅式のデメリット • 「あっ、dev は私が使ってるから触らないで」のような
 原始的コミュニケーション • チャットベースなどの管理 • 「dev環境全部割り当て表」 • 環境増減is⼿動 • 1環境 = ALB + ECS Service + Route レコード • 特にALBは、作成に時間もかかり、いるだけでprovisioningで課⾦される • 増減作業の⼿間 • お⾦がかかる • サーバシャットダウン忘れ、だるいからあえてシャットダウンしないなど • サーバ以外のリソース（LB、etc.）
24. よし、⾃動化しよう
25. devxx ⽅式の⾃動化を考える • CloudFormation/Terraform/CDK • ⼿動で今これでやっている • IaaCのソース⾃体がGit管理で、⾃動コミットとか⾃動apply怖い、やりたくない • ⾃前ツール • dev環境の増減するところをあえてIaaCで管理しないスタイル • さぁどうつくる
26. 動的devxx（仮） • devxx⽅式のメリットを活かしつつ、デメリットを解消 = コスト最適化しつつ、⾃動化する = ALB使い回し、それ以外はええ感じに⾃動化 • 1 環境 ( = environment) のライフサイクルを考える = featureの追加、修正は1つのPRで完結する場合が多いので、環境とPRは1:1の関係 = PRが作成されたら環境を作成、クローズorマージされたら削除
27. Introducing eden ECS Dynamic Environment Manager
28. eden概要 • create/deleteの2コマンドのみ • 既存の環境へのcreateはTask Definitionの作成とdeployのみ • REST⾵ APIとCLIがあります • REST⾵ != RESTful • Reference (参照)となるECS Serviceを指定するとそれをパクってくれる • dev 的reference serviceはIaaC（Terraformなど）で管理想定 • 環境を作成するたびにDescribeを⾏う • dev を変更すれば、それ以降に作成された動的環境が新しい設定で作成される • 既存の環境を更新したければ、⼀旦delete
29. edenがつくるもの . ECS Task Definition . ALB Target Group . ECS Service . ALB Listener Rule（共通ALBにHostHeaderルール追加のみ） . Route CNAME record（共通ALBを指すだけ） . Configファイルの更新（後述） （環境削除は逆順）
30. Configファイル is 何 • 開発アプリケーション（Web or Native）に、
 どんな環境があるかを知らせるためのJSONファイル • 隠しメニューを出すとJSONから⽣成された環境⼀覧が出る • 環境が切り替えられる
31. { "environments": [ { "env": "dev", "name": "dev-dynamic-test", "api_endpoint": "api-test.dev.example.com" } ] } Configファイル
32. { "environments": [ { "env": "dev", // ݻఆɺNativeͰͷAPNS౳ɺ֎෦APIͷdev/stg/prd੾Γସ͑༻ "name": "dev-dynamic-test", "api_endpoint": "api-test.dev.example.com" } ] } // ಉҰ؀ڥͰෳ਺ͷendpoint΋Ͱ͖·͢… // api_endpointͷΩʔ໊͕ม͑ΒΕ·͢… Configファイル static
 prefix branch name ಈత؀ڥઐ༻Zone branch name static
 prefix
33. Developing with eden
34. ࣮͸TwitterͰͪΐΖͬͱݴͬͯͨ ϑΥϩʔͨ͠Βͨ·ʹ͜͏ݴ͏ͷ͕؍ଌͰ͖·͢
 ʢ༗ӹͳ৘ใϨΞ౓ߴΊʣ
35. タップル誕⽣で導⼊してみた
36. eden導⼊ - CLI • まずはCLIから • 環境作成3秒、削除2秒ぐらい • なお、既存の環境へのcreateはdeployするだけになるのでチョッパヤ • Task⼊れ替えはまた別の話…
37. eden導⼊ - API • eden REST API をデプロイした • ALB、Lambda、Python . + Flask、全部で1300⾏ぐらい • CIで、ビルドとECRへのpushが終わった直後に条件分岐追加 • commit: GET eden.example.com/v /create?branch=foo&image_uri=xxxxxx • merge: GET eden.example.com/v /delete?branch=foo • Native devアプリの環境選択メニュー変更 • Configファイルの中⾝を元に⽣成するよう変更 • dev (パクり元)/stg/prdはedenで管理されないので、⼿でConfigファイルに記述
38. eden導⼊ - 開発者の声 • 感想 • 「⾃動デプロイでlead timeが短縮できる」 • 「Terraformのdev 以外のdevが消せる」 • 「利⽤が終わったdev環境にmaster流し直すとかしなくてもよくなった」 • Feedback • staleなPRの環境が⾃動的に削除されてほしい • どんな環境があるかの⼀覧がほしい
39. とある⼈に⾒せました
40. とある⼈に⾒せました
41. いいじゃん いつOSS化する？ シンプル
42. ちょうど社内インフラ周り
 OSS化プロジェクトがある
43. Baikonur Project • Terraform Moduleや各種ツールの共通化、OSS化プロジェクト • https://github.com/baikonur-oss/docs • PR⼤歓迎！コントリビュータ募集中！ • Terraform Moduleも随時募集中 • 相談やお問い合わせは、
 各レポジトリの Issue か@prog まで edenつくるの誰か⼿伝って…
45. 年内にedenも、 Baikonurに出します
46. 年内にedenも、 Baikonurに出します
47. 出ました
48. Baikonur eden • aws-eden-core • APIとCLIの共通部分 • aws-eden-cli • CLIツール • pip install aws-eden-cliでインストールできる • インストール後 eden で実⾏できる • eden API • Lambda + Terraform module
49. 開発ロードマップ サービス側からのFBで出た要望を元に、改善して完成度を上げていく • 作成された環境のstateを持つ • DynamoDBで管理 • 「Target group name cannot be longer than ' ' characters」回避⽤branch名略称登録 • stale environment auto-cleaner • 放置されてそうなブランチのenvを消すやつ • e.g. ⽇以上デプロイがない開発環境を削除 • remote-ls • 環境⼀覧出すやつ
50. 開発ロードマップ (cont.) • ここまでできたら、他のサービスへの導⼊ができる • 導⼊サービス増やしていく • そしてまたFBもらって開発を回す
51. まとめ • ECS Serviceとか環境⼀式を（literally）秒で作成、削除できるツール作った • かなり反響がよかった • 管理コスト、リソースコストが削減可能 • OSS化しました • が、ハッカソンのノリで作ったを綺麗に作り直さないといけない • 設計を考え直して、コードを清書したい • ⼿伝ってくれるニキいないかな
52. おしまい