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

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

プルリク作ったらデプロイされる仕組み 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によるキャッシュ利用とマルチアーキテクチャイメージ作成

2537ce662eb08182e617ec7944981437?s=128

CARTA Engineering

May 17, 2022
Tweet

More Decks by CARTA Engineering

Other Decks in Technology

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年に経営統合

  4. None
  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/