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

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

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

Transcript

1. Amazon ECSの開発環境を動的に

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

   View Slide

2. ⾃⼰紹介
   • 2018年 サイバーエージェント新卒⼊社
   • Cloud Technologies Advisor ＝
   (SA+SRE+DevOps+Infra) /
   • AWA、REQU、タップル誕⽣、

   CROSSMEなど担当
   • 好きなもの: Terraform、Python、
   Elasticsearch、Serverless ❤
   • 好きなAWSのサービス: ECS
   Torgayev Tamirlan
   @prog
   

   View Slide

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

   View Slide

4. ECSを導⼊します
   

   View Slide

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

   View Slide

6. わーい＼(^o^)∕
   

   View Slide

7. 移設します
   

   View Slide

8. 移設が終わります
   

   View Slide

9. ECSでの本格的な

   チーム開発が始まります
   

   View Slide

10. チーム開発
    • localでfeature作った！
    • リアルなDBとか周辺サービスとつなぎこんで、

    AWS上でどう動くかマージする前に確認したい
    • x ⼈
    • さらにiOS/Androidのdevアプリで動き⾒たい
    

    View Slide

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

    View Slide

12. どうすれば複数の開発タスクを

    同時に進めるんだよ
    

    View Slide

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

    View Slide

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

    View Slide

15. 開発レーンが増える
    

    View Slide

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

    View Slide

17. dev環境がまた増える
    

    View Slide

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

    View Slide

19. ∕(^o^)＼
    

    View Slide

20. Problem
    • 移設したのはいいが、

    クラウドとアプリケーションの

    稼働プラットフォームが変わっただけで、

    チームとメンバーの意識や開発スタイルは何⼀つ変わっていない
    

    View Slide

21. devxx ⽅式について考える
    

    View Slide

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

    View Slide

23. devxx ⽅式のデメリット
    • 「あっ、dev は私が使ってるから触らないで」のような

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

    View Slide

24. よし、⾃動化しよう
    

    View Slide

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

    View Slide

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

    View Slide

27. Introducing eden
    ECS Dynamic Environment Manager
    

    View Slide

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
    

    View Slide

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

    View Slide

30. Configファイル is 何
    • 開発アプリケーション（Web or Native）に、

    どんな環境があるかを知らせるためのJSONファイル
    • 隠しメニューを出すとJSONから⽣成された環境⼀覧が出る
    • 環境が切り替えられる
    

    View Slide

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

    View Slide

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
    

    View Slide

33. Developing with eden
    

    View Slide

34. ࣮͸TwitterͰͪΐΖͬͱݴͬͯͨ
    ϑΥϩʔͨ͠Βͨ·ʹ͜͏ݴ͏ͷ͕؍ଌͰ͖·͢

    ʢ༗ӹͳ৘ใϨΞ౓ߴΊʣ
    

    View Slide

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

    View Slide

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

    View Slide

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ファイルに記述
    

    View Slide

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

    View Slide

39. とある⼈に⾒せました
    

    View Slide

40. とある⼈に⾒せました
    

    View Slide

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

    View Slide

42. ちょうど社内インフラ周り

    OSS化プロジェクトがある
    

    View Slide

43. Baikonur Project
    • Terraform Moduleや各種ツールの共通化、OSS化プロジェクト
    • https://github.com/baikonur-oss/docs
    • PR⼤歓迎！コントリビュータ募集中！
    • Terraform Moduleも随時募集中
    • 相談やお問い合わせは、

    各レポジトリの Issue か@prog まで
    edenつくるの誰か⼿伝って…
    

    View Slide

44. View Slide

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

    View Slide

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

    View Slide

47. 出ました
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

52. おしまい
    

    View Slide