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

Slide 1

Slide 1 text

Amazon ECSの開発環境を動的に  管理するツールを作ってみました株式会社サイバーエージェント技術本部サービスリライアビリティグループクラウド技術アドバイザ Torgayev Tamirlan (@prog )

Slide 2

Slide 2 text

⾃⼰紹介 • 2018年サイバーエージェント新卒⼊社 • Cloud Technologies Advisor ＝ (SA+SRE+DevOps+Infra) / • AWA、REQU、タップル誕⽣、  CROSSMEなど担当 • 好きなもの: Terraform、Python、 Elasticsearch、Serverless ❤ • 好きなAWSのサービス: ECS Torgayev Tamirlan @prog

Slide 3

Slide 3 text

よく⾒る流れの話をします

Slide 4

Slide 4 text

ECSを導⼊します

Slide 5

Slide 5 text

ECSを導⼊ • ECS簡単じゃん、楽じゃん、最⾼ • 導⼊してみよう • ええ感じやし、このままオンプレからAWSに移設しよう！ • わーい＼(^o^)∕

Slide 6

Slide 6 text

わーい＼(^o^)∕

Slide 7

Slide 7 text

移設します

Slide 8

Slide 8 text

移設が終わります

Slide 9

Slide 9 text

ECSでの本格的な  チーム開発が始まります

Slide 10

Slide 10 text

チーム開発 • localでfeature作った！ • リアルなDBとか周辺サービスとつなぎこんで、  AWS上でどう動くかマージする前に確認したい • x ⼈ • さらにiOS/Androidのdevアプリで動き⾒たい

Slide 11

Slide 11 text

でも開発環境は1つだけ！

Slide 12

Slide 12 text

どうすれば複数の開発タスクを  同時に進めるんだよ

Slide 13

Slide 13 text

理想 • A/B testing (Feature Flags)、microservices、、etc. • ⼤きなアーキテクチャ変更... • いきなり導⼊するの難しい

Slide 14

Slide 14 text

現実：devxx⽅式 • オンプレ、VPS、EC などではよくみるアレ • 同じdev環境を複数⽤意 • dev , dev , ..., devxx • これを「devxx⽅式」と私が勝⼿に呼んでます

Slide 15

Slide 15 text

開発レーンが増える

Slide 16

Slide 16 text

「あっ、dev は私が使ってるから触らないで」

Slide 17

Slide 17 text

dev環境がまた増える

Slide 18

Slide 18 text

dev環境がまた増える眠れない夜疲労涙割り当て表管理原始的コミュニケーションコンフリクト残業⼿動デプロイ汗 prodまでのlead time延⻑ dev環境がまた増えるイライラ Apply Failed dev環境10以上誰も知らないエンドポイント腐る環境余分なコスト Toil 設定差分 Build Failed ※イメージです

Slide 19

Slide 19 text

∕(^o^)＼

Slide 20

Slide 20 text

Problem • 移設したのはいいが、  クラウドとアプリケーションの  稼働プラットフォームが変わっただけで、  チームとメンバーの意識や開発スタイルは何⼀つ変わっていない

Slide 21

Slide 21 text

devxx ⽅式について考える

Slide 22

Slide 22 text

devxx ⽅式のメリット • オンプレ、VPS、物理サーバ運⽤経験者にとって学習コスト低い • 横に全く同じサーバを⼀時的に増やして、Ansible的なのを流してDNS設定するだけ • 使ってないサーバはシャットダウンしておくなど • 使ってない環境のサーバはシャットダウンしてあればコストがかからない • 導⼊コスト低 • Feature Flagなどではないので環境を横でつくるだけ • コードの修正もいらない • ⼀つ⼀つの環境が完全に分離されている

Slide 23

Slide 23 text

devxx ⽅式のデメリット • 「あっ、dev は私が使ってるから触らないで」のような  原始的コミュニケーション • チャットベースなどの管理 • 「dev環境全部割り当て表」 • 環境増減is⼿動 • 1環境 = ALB + ECS Service + Route レコード • 特にALBは、作成に時間もかかり、いるだけでprovisioningで課⾦される • 増減作業の⼿間 • お⾦がかかる • サーバシャットダウン忘れ、だるいからあえてシャットダウンしないなど • サーバ以外のリソース（LB、etc.）

Slide 24

Slide 24 text

よし、⾃動化しよう

Slide 25

Slide 25 text

devxx ⽅式の⾃動化を考える • CloudFormation/Terraform/CDK • ⼿動で今これでやっている • IaaCのソース⾃体がGit管理で、⾃動コミットとか⾃動apply怖い、やりたくない • ⾃前ツール • dev環境の増減するところをあえてIaaCで管理しないスタイル • さぁどうつくる

Slide 26

Slide 26 text

動的devxx（仮） • devxx⽅式のメリットを活かしつつ、デメリットを解消 = コスト最適化しつつ、⾃動化する = ALB使い回し、それ以外はええ感じに⾃動化 • 1 環境 ( = environment) のライフサイクルを考える = featureの追加、修正は1つのPRで完結する場合が多いので、環境とPRは1:1の関係 = PRが作成されたら環境を作成、クローズorマージされたら削除

Slide 27

Slide 27 text

Introducing eden ECS Dynamic Environment Manager

Slide 28

Slide 28 text

eden概要 • create/deleteの2コマンドのみ • 既存の環境へのcreateはTask Deﬁnitionの作成とdeployのみ • REST⾵ APIとCLIがあります • REST⾵ != RESTful • Reference (参照)となるECS Serviceを指定するとそれをパクってくれる • dev 的reference serviceはIaaC（Terraformなど）で管理想定 • 環境を作成するたびにDescribeを⾏う • dev を変更すれば、それ以降に作成された動的環境が新しい設定で作成される • 既存の環境を更新したければ、⼀旦delete

Slide 29

Slide 29 text

edenがつくるもの . ECS Task Deﬁnition . ALB Target Group . ECS Service . ALB Listener Rule（共通ALBにHostHeaderルール追加のみ） . Route CNAME record（共通ALBを指すだけ） . Conﬁgファイルの更新（後述）（環境削除は逆順）

Slide 30

Slide 30 text

Conﬁgファイル is 何 • 開発アプリケーション（Web or Native）に、  どんな環境があるかを知らせるためのJSONファイル • 隠しメニューを出すとJSONから⽣成された環境⼀覧が出る • 環境が切り替えられる

Slide 31

Slide 31 text

{ "environments": [ { "env": "dev", "name": "dev-dynamic-test", "api_endpoint": "api-test.dev.example.com" } ] } Conﬁgファイル

Slide 32

Slide 32 text

{ "environments": [ { "env": "dev", // ݻఆɺNativeͰͷAPNS౳ɺ֎෦APIͷdev/stg/prd੾Γସ͑༻ "name": "dev-dynamic-test", "api_endpoint": "api-test.dev.example.com" } ] } // ಉҰ؀ڥͰෳ਺ͷendpoint΋Ͱ͖·͢… // api_endpointͷΩʔ໊͕ม͑ΒΕ·͢… Conﬁgファイル static  prefix branch name ಈత؀ڥઐ༻Zone branch name static  prefix

Slide 33

Slide 33 text

Developing with eden

Slide 34

Slide 34 text

࣮͸TwitterͰͪΐΖͬͱݴͬͯͨ ϑΥϩʔͨ͠Βͨ·ʹ͜͏ݴ͏ͷ͕؍ଌͰ͖·͢  ʢ༗ӹͳ৘ใϨΞ౓ߴΊʣ

Slide 35

Slide 35 text

タップル誕⽣で導⼊してみた

Slide 36

Slide 36 text

eden導⼊ - CLI • まずはCLIから • 環境作成3秒、削除2秒ぐらい • なお、既存の環境へのcreateはdeployするだけになるのでチョッパヤ • Task⼊れ替えはまた別の話…

Slide 37

Slide 37 text

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アプリの環境選択メニュー変更 • Conﬁgファイルの中⾝を元に⽣成するよう変更 • dev (パクり元)/stg/prdはedenで管理されないので、⼿でConﬁgファイルに記述

Slide 38

Slide 38 text

eden導⼊ - 開発者の声 • 感想 • 「⾃動デプロイでlead timeが短縮できる」 • 「Terraformのdev 以外のdevが消せる」 • 「利⽤が終わったdev環境にmaster流し直すとかしなくてもよくなった」 • Feedback • staleなPRの環境が⾃動的に削除されてほしい • どんな環境があるかの⼀覧がほしい

Slide 39

Slide 39 text

とある⼈に⾒せました

Slide 40

Slide 40 text

とある⼈に⾒せました

Slide 41

Slide 41 text

いいじゃんいつOSS化する？シンプル

Slide 42

Slide 42 text

ちょうど社内インフラ周り  OSS化プロジェクトがある

Slide 43

Slide 43 text

Baikonur Project • Terraform Moduleや各種ツールの共通化、OSS化プロジェクト • https://github.com/baikonur-oss/docs • PR⼤歓迎！コントリビュータ募集中！ • Terraform Moduleも随時募集中 • 相談やお問い合わせは、  各レポジトリの Issue か@prog まで edenつくるの誰か⼿伝って…

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

年内にedenも、 Baikonurに出します

Slide 46

Slide 46 text

年内にedenも、 Baikonurに出します

Slide 47

Slide 47 text

出ました

Slide 48

Slide 48 text

Baikonur eden • aws-eden-core • APIとCLIの共通部分 • aws-eden-cli • CLIツール • pip install aws-eden-cliでインストールできる • インストール後 eden で実⾏できる • eden API • Lambda + Terraform module

Slide 49

Slide 49 text

開発ロードマップサービス側からのFBで出た要望を元に、改善して完成度を上げていく • 作成された環境のstateを持つ • DynamoDBで管理 • 「Target group name cannot be longer than ' ' characters」回避⽤branch名略称登録 • stale environment auto-cleaner • 放置されてそうなブランチのenvを消すやつ • e.g. ⽇以上デプロイがない開発環境を削除 • remote-ls • 環境⼀覧出すやつ

Slide 50

Slide 50 text

開発ロードマップ (cont.) • ここまでできたら、他のサービスへの導⼊ができる • 導⼊サービス増やしていく • そしてまたFBもらって開発を回す

Slide 51

Slide 51 text

まとめ • ECS Serviceとか環境⼀式を（literally）秒で作成、削除できるツール作った • かなり反響がよかった • 管理コスト、リソースコストが削減可能 • OSS化しました • が、ハッカソンのノリで作ったを綺麗に作り直さないといけない • 設計を考え直して、コードを清書したい • ⼿伝ってくれるニキいないかな

Slide 52

Slide 52 text

おしまい