ECSのCI/CD改善と標準化の取り組み / JAWS FESTA 2023 in Kyushu

https://jft2023.jaws-ug.jp/ の発表資料です

Transcript

1. ECSのCI/CD改善と 標準化の取り組み id:cohalz / @cohalz JAWS FESTA 2023 in Kyushu 1
2. 自己紹介 • こはる(@cohalz) • 株式会社はてな SRE ◦ はてなブックマーク ◦ はてなブログ • 福岡移住してもうすぐ1年 ◦ リモート勤務 2
3. 今日話すこと • はてなにおけるCI/CDの改善 ◦ はてなブログを例に • ECSのCI/CDを標準化する取り組み 3
4. 今日話さないこと • ECSに移行する方法の話 ◦ はてなブログをECSに移行してリリース頻度も改善し た話 • EKSの話 ◦ Kubernetes撤退、 その後のはてなの取り組み 4
5. 5 はてなブログ
6. はてなブログ • 2011 EC2でサービス開始 • 2019~2022 ECSに移行 ◦ 関連サービスを含め10種類程度のコンポーネント 6
7. ECS移行して起きた問題 • 各サービスをモノレポでCDK管理していた • CDKの設定を書いた人がバラバラ ◦ いろんな人が移行していった ◦ 元々の開発オーナーが違うサービスも • その結果CI/CDがバラバラに 7
8. CI/CDがバラバラだと • 認知負荷が高い ◦ n通りのデプロイ方法を正しく覚える必要 ◦ 手作業の手順もあり事故りやすい • 改善の手が周りきらない ◦ 一個だけ改善しても残りと差分が広がってしまう 8
9. CI/CDの見直しを行う • 最後のはてなブログ本体のECS移行のタイミ ングで統一することに • デプロイ・運用しやすいものを目指す 9
10. 10 ECSのCI/CD改善
11. 改善のテーマ • 全サービスを同じ方法でデプロイする • 手元からデプロイしない • 作り込みすぎない 11
12. 何をしたか • CDKではなくecspressoで管理 • デプロイ用のリポジトリを作る • GitHub Actionsでデプロイ • 既存のCDK管理されたものも移行 12
13. ecspressoの採用 • 既存の設定を簡単にコード管理できる • diffやverifyなど便利なコマンドがある • CI/CDのライフサイクル分離と高相性 13
14. デプロイ用の リポジトリ • コードともCDKとも違 うリポジトリを作るよ うに • このリポジトリに全 サービスのECS設定を 置く 14
15. GitHub Actionsを使ったデプロイ • GitHub Actionsでecspresso deployを実行 ◦ mainブランチの更新をトリガーに実行 ◦ GitOpsの考えを採用 • 社内のEKS+ArgoCDのデプロイを真似した ◦ 「はてラボ」のサービスも利用しているEKSクラスタ の構成と運用について 15
16. イメージのタグを更新するPRが自動で作成される 16
17. 改善の結果 • 全サービスを同一の方法でデプロイ可能に • デプロイ用の環境構築も不要に ◦ デザイナーでもデプロイ可能に • 開発者がメンテしやすくなったメリットも ◦ 複雑なCDKの設定と切り離された 17
18. Tips: CDKからecspressoへ移行する方法 • 方法1: 別のサービス名で作りなおす ◦ ecspresso initしてサービス名を変えて並行稼働 ◦ その後CDKの設定を削除 or 0台にする • 方法2 : サービスを残して移行する ◦ CDK側でDeletionPolicy: Retainを設定 ◦ その後CDKの設定を削除することでリソースを残せる 18
19. 19 標準化
20. 全社の課題 • はてなではプロダクトがたくさんある ◦ ブログ、ブクマ、Mackerel、マンガ、... • 各チームも同様にCI/CDの課題があった ◦ うまくいった例を広めたい ◦ チーム間でも統一化したい 20
21. 社内で標準化の動きが活発に • 社内で標準化のプロセスが整備され始めた ◦ CI/CDもその動きに乗っかりたい • 標準を定めることによって ◦ 注力する技術を絞って集中できる ◦ 改善をそこに集約できる 21
22. 22 標準化の進め方
23. SRE標準化委員会の発足 • 2021/8から各チームのSREsが有志で集まっ たグループ • プロダクトの運用知見やツールを共有し、シ ステム構築・運用の効率化、省力化を目指す 23
24. 委員会メンバーで標準化を進める • CI/CDの標準化をするサブチームを作る ◦ 週次の定例で各チームの改善を共有 ◦ Scrapboxに書いて非同期でコミュニケーションも • 開発合宿も利用 ◦ 同期的に集中してツールを作る • 定期的に社内勉強会で成果を周知 24
25. 各チームに ヒアリング • 各チームのテックリー ドにECS周りについて ヒアリング • チームが求めているも のとのミスマッチを減 らす 25
26. ヒアリングした結果 • 多くのチームはGitHub Actionsを利用 • ECSのデプロイに課題を感じている • ブログで作ったワークフローを改善して再利 用することに 26
27. GitHub Actionsの再利用 • PublicでないReusable WorkflowやComposite Actionを同一組織で再利用可能に(2022/12) ◦ GitHub Actions – Sharing actions and reusable workflows from private repositories is now GA • ワークフローを集めたリポジトリを作る形に ◦ 各チームでそのワークフローを利用する 27
28. リリース用リポジトリの展開 • どんなサービスでもecspressoのファイルと そのCI/CDで中身はほとんど同じ • ワークフローを配るよりももっと楽にしたい • ブログで作ったものをテンプレートリポジト リとして用意 28
29. リリース用リポジトリのテンプレート • 必要なワークフローなど揃えたテンプレート • Cloneしてecspressoのファイルを置く ◦ 既に構築したCI/CDをすぐ使える 29
30. 標準化されたCI/CDを利用する流れ 30
31. CI/CDの実装もブラッシュアップ • ブログの実装をMackerelチームで再構築 • それをブックマークチームでさらに改善 • その後標準として広めていく ◦ 2チームで動く実績がある説得力がある 31
32. 行った改善の例 • ビルド待ちの短縮 ◦ イメージにもう一度タグを付ける - Amazon ECR • デプロイ履歴を確認しやすく ◦ GitHubのリリースと連携 ◦ Mackerelにアノテーション • デプロイ順序を制御できるように ◦ AとBを同時や順番にデプロイする 32
33. 標準のアップデートをどう広めるか • 考えられる懸念 ◦ 各チームがアップデートに気付けない ◦ アップデート作業が面倒で放置 • Renovateを使うことで改善 33
34. Renovateで社内のActionを更新 リリースノートも確認できる 34
35. 標準化を狙うことで得られるメリット • 影響範囲が広がり品質が上がる ◦ 各チームからフィードバックがある ◦ テストコードを書いたり変更管理をしたり • OSSだと思ってメンテするような感じ ◦ 将来OSSにしても良い 35
36. 改善の成果 • 採用したチームで現れた効果 ◦ チームによってはデプロイ頻度が2倍に ◦ ワークフローが整理されメンテナンスしやすく • 複数チームで採用が始まる ◦ 新卒研修でも使われるように ◦ 採用したチームからフィードバックも 36
37. 37 標準化する上で 気をつけること
38. 標準化する上で気をつけること • 全チームの要望を解決しようとしない ◦ 作るのにも時間が掛かる、メンテナンスも大変 ◦ 汎用的すぎても課題を解決しづらくなる ◦ 利用の強制はしない • 意思決定やアップデートのプロセスを決める ◦ 起きた問題をフィードバックして改善できるように 38
39. 認知度を上げる • 作るだけでなくちゃんと使われるようにする のが大事 • 定期的に存在をアピールする ◦ そもそも他の人が存在を知らないところから始まる • 検証に協力してくれる人を探す ◦ ファンを増やす 39
40. おわり • はてなにおけるECSのCI/CD改善を紹介しました • CI/CDの標準化に向けた動きとそれをうまく進め るための工夫についても紹介しました 40