Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

563d2e1e4cabf5ca21404f7104c90e91?s=128

Tamirlan 893 Torgayev

August 29, 2019
Tweet

More Decks by Tamirlan 893 Torgayev

Other Decks in Programming

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つくるの誰か⼿伝って…
  44. None
  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. おしまい