プルリク作ったらデプロイされる仕組み on ECS / SRE NEXT 2022

https://sre-next.dev/2022/schedule#sp11

CARTA HOLDINGSで広告配信プラットフォームを提供しているfluctでは、広告配信のオペレーションを行なう管理画面の開発において、featureブランチ毎に自動デプロイされる環境を用意しています。
オンプレからクラウド、コンテナへと環境は変化し、現在ではAWSのコンテナ実行環境であるECSを使って実現しています。
また、1日10回以上デプロイされるワークフローを支える仕組みや開発者の手による改善、ARM環境対応を行ってきました。
これらについてどのように実現しているかをお話します。
・ featureブランチ毎のルーティングを実現するECSサービスディスカバリ
・ GitHub Actions によるデプロイワークフロー
・ ecspresso を使ったECSサービスのデプロイ
・ BuildKitによるキャッシュ利用とマルチアーキテクチャイメージ作成

Transcript

1. SRE NEXT 2022 プルリク作ったらデプロイされる 仕組み on ECS 2022/05/14-15
2. 2 自己紹介 • 大渡 裕太 わっさん • 経歴 ◦ 2015年 旧VOYAGE GROUP新卒入社 • twitter: @yowatari • やって(る|た)こと ◦ オンプレ刷新周り ▪ アップデート系 ◦ オンプレ -> AWS 移行周り ▪ データベースとかとか ◦ データエンジニアリング ▪ 広告効果計測周り ◦ インターン運営 ▪ パフォーマンスチューニング題材
3. CARTA HOLDINGSは2019年1月に VOYAGE GROUP と CCI が経営統合し誕生しました 多くの事業・サービスを運営しています（下記は一部を抜粋） 2019年に経営統合
5. 5 今回お話するwebサービス
6. 6 ブランチ環境 • 開発中の機能を確認できる環境 ◦ 開発者だけでなく、ユーザでも確認できるように ◦ ユーザ = 社内の誰か ◦ データベース等は共通 • プルリクストを作ると自動かつ継続的にデプロイされる • https://${ブランチ名}.example.com でホストされる • 似たようなものに、Hashicorp Waypoint等がある push hoge https://hoge.example.com
7. 7 PRの例
8. 8 古での仕組み • 単にサーバでやってた時代 ◦ nginx + php-fpm • 素朴な方法 ◦ 1. git push を webhook で jenkins に通知してスク リプトを実行する(つらみ) ◦ 2. git worktree add 等で指定ブランチを用意する ◦ 3. nginxで server_name からブランチ名を取って いい感じに document root に 2. を指定する
9. 9 古での仕組み: git worktree + nginx • git-worktree Documentation • git worktree add <path> <branch> で指定のパスに指定 のブランチをチェックアウトできる ◦ git worktree add /home/branch/hoge hoge • nginxではserver_nameからdocument rootのパスを決 める
10. 10 ECS移行 • コンテナに移行することにした ◦ 当初はオンプレ->AWSの移行をゴールに変更の少 ないEC2で稼働させていた ◦ クラウド前提の今、デプロイやミドルウェアをア プリケーション側で面倒見れるようにしたい • 移行 ◦ サーバ前提な部分を書き直したり ◦ Dockerイメージのビルド戦略(タグやキャッシュ) • 本番そのものは容易だったが、前述の仕組みが無い ◦ 開発中において無くては困る
11. 11 余談: ECS化でよかったこと • コンテナの追加や調整等 ◦ 変更は開発者自身で行えている ◦ コンテナ化に際して、すべての設定をアプリのリ ポジトリに揃えている ◦ その変更もブランチ環境で確認できる • ECSの下回り部分は詳しい人が見ている ◦ ECS on EC2でやっているので、その部分 ▪ こちらはこちらでスポットインスタンスの利 用などやりたいことがある ◦ VPC等
12. 12 監視やミドルウェア整備
13. 13 今の仕組み • ブランチ単位でECSサービスを作って都度デプロイ • サービスディスカバリで↑のサービスにアクセスでき るようにする
14. 14 今の仕組み: サービスディスカバリ • Amazon ECS サービスディスカバリ | Amazon Web Services ブログ • サービス定義の serviceRegistries で設定可能 ◦ CloudMap サービスを指定する ◦ ヘルスチェックに基づいて、自動でRoute53のレ コードが更新される (サービス名.名前空間.)
15. 15 今の仕組み: nginx service_name でブランチ名を拾い、該当するECSサービ スに向ける
16. 16 デプロイ • kayac/ecspresso に頼っている ◦ タスク定義にjsonnetが使えて、記述の重複を減らせ て便利。 ◦ 本番とブランチ環境とで使いまわしたりしています
17. 17 GitHub Actions • デプロイ諸々のワークフローはすべてGitHub Actions に集約させている
18. 18 Github Actions: composite • Creating a composite action - GitHub Docs ◦ .github/actions/*/action.yaml で定義 ◦ awsのクレデンシャル取得周りやDockerでのビル ド周りなどの共通なステップで利用してます
19. 19 Github Actions: create-or-update-comment 一度だけPRにコメントさせるのに利用しています
20. 20 一日のデプロイの様子 • 毎日だいたい10回はデプロ イされ、マージの都度リリ ースされるぐらいの頻度 • CIの速度が遅いと困るので、 キャッシュ周りに気を使っ てる
21. 21 余談: arm 対応 • Apple Silicon や AWS Graviton 2 の登場でarm対応に迫ら れがち • マルチアーキテクチャイメージで対応 ◦ 多少調整は必要になったが、比較的ラク ▪ mysqlイメージのarm版が当時は無かったり • ビルド時のエミュレーションは遅いので、キャッシュを最 大限利用するよう気を使う ◦ BuildKit (docker buildx) もしくはdocker/build-push- action ▪ cache-from/to type=gha ▪ 前者では crazy-max/ghaction-github-runtime も併 用
22. 22 まとめ • プルリクストを作ったらデプロイされる環境について 話ました ◦ ECSサービスディスカバリ便利 • 自走できる環境作り ◦ ミドルウェアを含めた変更も自身でトライアンド エラーができるようになった ◦ CIの速度が開発体験を律速するので、CIへの関心 も高まった気がする
23. https://engineering.cartaholdings.co.jp/