PRごとに専用のECS環境を動的に作成、削除できるツールを紹介します。作成経緯や社内での活用について紹介し、今後のロードマップやOSS化について話します。また、サイバーエージェントのインフラ周りのツールのOSS化プロジェクトについて紹介します。 Torgayev Tamirlan (@prog893) - クラウド技術アドバイザ, サイバーエージェント 技術本部 サービスリライアビリティーグループ

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

2. ⾃⼰紹介
• 2018年 サイバーエージェント新卒⼊社
• Cloud Technologies Advisor ＝
(SA+SRE+DevOps+Infra) /
• AWA、REQU、タップル誕⽣、
CROSSMEなど担当
• 好きなもの: Terraform、Python、
Elasticsearch、Serverless ❤
• 好きなAWSのサービス: ECSTorgayev 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. おしまい