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

2 自己紹介 ● 大渡 裕太 わっさん ● 経歴 ○ 2015年 旧VOYAGE GROUP新卒入社 ● twitter: @yowatari ● やって(る|た)こと ○ オンプレ刷新周り ■ アップデート系 ○ オンプレ -> AWS 移行周り ■ データベースとかとか ○ データエンジニアリング ■ 広告効果計測周り ○ インターン運営 ■ パフォーマンスチューニング題材 

CARTA HOLDINGSは2019年1月に VOYAGE GROUP と CCI が経営統合し誕生しました 多くの事業・サービスを運営しています（下記は一部を抜粋） 2019年に経営統合 

No content

5 今回お話するwebサービス 

6 ブランチ環境 ● 開発中の機能を確認できる環境 ○ 開発者だけでなく、ユーザでも確認できるように ○ ユーザ = 社内の誰か ○ データベース等は共通 ● プルリクストを作ると自動かつ継続的にデプロイされる ● https://${ブランチ名}.example.com でホストされる ● 似たようなものに、Hashicorp Waypoint等がある push hoge https://hoge.example.com 

7 PRの例 

8 古での仕組み ● 単にサーバでやってた時代 ○ nginx + php-fpm ● 素朴な方法 ○ 1. git push を webhook で jenkins に通知してスク リプトを実行する(つらみ) ○ 2. git worktree add 等で指定ブランチを用意する ○ 3. nginxで server_name からブランチ名を取って いい感じに document root に 2. を指定する 

9 古での仕組み: git worktree + nginx ● git-worktree Documentation ● git worktree add で指定のパスに指定 のブランチをチェックアウトできる ○ git worktree add /home/branch/hoge hoge ● nginxではserver_nameからdocument rootのパスを決 める 

10 ECS移行 ● コンテナに移行することにした ○ 当初はオンプレ->AWSの移行をゴールに変更の少 ないEC2で稼働させていた ○ クラウド前提の今、デプロイやミドルウェアをア プリケーション側で面倒見れるようにしたい ● 移行 ○ サーバ前提な部分を書き直したり ○ Dockerイメージのビルド戦略(タグやキャッシュ) ● 本番そのものは容易だったが、前述の仕組みが無い ○ 開発中において無くては困る 

11 余談: ECS化でよかったこと ● コンテナの追加や調整等 ○ 変更は開発者自身で行えている ○ コンテナ化に際して、すべての設定をアプリのリ ポジトリに揃えている ○ その変更もブランチ環境で確認できる ● ECSの下回り部分は詳しい人が見ている ○ ECS on EC2でやっているので、その部分 ■ こちらはこちらでスポットインスタンスの利 用などやりたいことがある ○ VPC等 

12 監視やミドルウェア整備 

13 今の仕組み ● ブランチ単位でECSサービスを作って都度デプロイ ● サービスディスカバリで↑のサービスにアクセスでき るようにする 

14 今の仕組み: サービスディスカバリ ● Amazon ECS サービスディスカバリ | Amazon Web Services ブログ ● サービス定義の serviceRegistries で設定可能 ○ CloudMap サービスを指定する ○ ヘルスチェックに基づいて、自動でRoute53のレ コードが更新される (サービス名.名前空間.) 

15 今の仕組み: nginx service_name でブランチ名を拾い、該当するECSサービ スに向ける 

16 デプロイ ● kayac/ecspresso に頼っている ○ タスク定義にjsonnetが使えて、記述の重複を減らせ て便利。 ○ 本番とブランチ環境とで使いまわしたりしています 

17 GitHub Actions ● デプロイ諸々のワークフローはすべてGitHub Actions に集約させている 

18 Github Actions: composite ● Creating a composite action - GitHub Docs ○ .github/actions/*/action.yaml で定義 ○ awsのクレデンシャル取得周りやDockerでのビル ド周りなどの共通なステップで利用してます 

19 Github Actions: create-or-update-comment 一度だけPRにコメントさせるのに利用しています 

20 一日のデプロイの様子 ● 毎日だいたい10回はデプロ イされ、マージの都度リリ ースされるぐらいの頻度 ● CIの速度が遅いと困るので、 キャッシュ周りに気を使っ てる 

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 まとめ ● プルリクストを作ったらデプロイされる環境について 話ました ○ ECSサービスディスカバリ便利 ● 自走できる環境作り ○ ミドルウェアを含めた変更も自身でトライアンド エラーができるようになった ○ CIの速度が開発体験を律速するので、CIへの関心 も高まった気がする 

https://engineering.cartaholdings.co.jp/