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

by cohalz

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介 ● こはる(@cohalz) ● 株式会社はてな SRE ○ はてなブックマーク ○ はてなブログ ● 福岡移住してもうすぐ1年 ○ リモート勤務 2

Slide 3

Slide 3 text

今日話すこと ● はてなにおけるCI/CDの改善 ○ はてなブログを例に ● ECSのCI/CDを標準化する取り組み 3

Slide 4

Slide 4 text

今日話さないこと ● ECSに移行する方法の話 ○ はてなブログをECSに移行してリリース頻度も改善した話 ● EKSの話 ○ Kubernetes撤退、その後のはてなの取り組み 4

Slide 5

Slide 5 text

5 はてなブログ

Slide 6

Slide 6 text

はてなブログ ● 2011 EC2でサービス開始 ● 2019~2022 ECSに移行 ○ 関連サービスを含め10種類程度のコンポーネント 6

Slide 7

Slide 7 text

ECS移行して起きた問題 ● 各サービスをモノレポでCDK管理していた ● CDKの設定を書いた人がバラバラ ○ いろんな人が移行していった ○ 元々の開発オーナーが違うサービスも ● その結果CI/CDがバラバラに 7

Slide 8

Slide 8 text

CI/CDがバラバラだと ● 認知負荷が高い ○ n通りのデプロイ方法を正しく覚える必要 ○ 手作業の手順もあり事故りやすい ● 改善の手が周りきらない ○ 一個だけ改善しても残りと差分が広がってしまう 8

Slide 9

Slide 9 text

CI/CDの見直しを行う ● 最後のはてなブログ本体のECS移行のタイミングで統一することに ● デプロイ・運用しやすいものを目指す 9

Slide 10

Slide 10 text

10 ECSのCI/CD改善

Slide 11

Slide 11 text

改善のテーマ ● 全サービスを同じ方法でデプロイする ● 手元からデプロイしない ● 作り込みすぎない 11

Slide 12

Slide 12 text

何をしたか ● CDKではなくecspressoで管理 ● デプロイ用のリポジトリを作る ● GitHub Actionsでデプロイ ● 既存のCDK管理されたものも移行 12

Slide 13

Slide 13 text

ecspressoの採用 ● 既存の設定を簡単にコード管理できる ● diffやverifyなど便利なコマンドがある ● CI/CDのライフサイクル分離と高相性 13

Slide 14

Slide 14 text

デプロイ用のリポジトリ ● コードともCDKとも違うリポジトリを作るように ● このリポジトリに全サービスのECS設定を置く 14

Slide 15

Slide 15 text

GitHub Actionsを使ったデプロイ ● GitHub Actionsでecspresso deployを実行 ○ mainブランチの更新をトリガーに実行 ○ GitOpsの考えを採用 ● 社内のEKS+ArgoCDのデプロイを真似した ○ 「はてラボ」のサービスも利用しているEKSクラスタの構成と運用について 15

Slide 16

Slide 16 text

イメージのタグを更新するPRが自動で作成される 16

Slide 17

Slide 17 text

改善の結果 ● 全サービスを同一の方法でデプロイ可能に ● デプロイ用の環境構築も不要に ○ デザイナーでもデプロイ可能に ● 開発者がメンテしやすくなったメリットも ○ 複雑なCDKの設定と切り離された 17

Slide 18

Slide 18 text

Tips: CDKからecspressoへ移行する方法 ● 方法1: 別のサービス名で作りなおす ○ ecspresso initしてサービス名を変えて並行稼働 ○ その後CDKの設定を削除 or 0台にする ● 方法2 : サービスを残して移行する ○ CDK側でDeletionPolicy: Retainを設定 ○ その後CDKの設定を削除することでリソースを残せる 18

Slide 19

Slide 19 text

19 標準化

Slide 20

Slide 20 text

全社の課題 ● はてなではプロダクトがたくさんある ○ ブログ、ブクマ、Mackerel、マンガ、... ● 各チームも同様にCI/CDの課題があった ○ うまくいった例を広めたい ○ チーム間でも統一化したい 20

Slide 21

Slide 21 text

社内で標準化の動きが活発に ● 社内で標準化のプロセスが整備され始めた ○ CI/CDもその動きに乗っかりたい ● 標準を定めることによって ○ 注力する技術を絞って集中できる ○ 改善をそこに集約できる 21

Slide 22

Slide 22 text

22 標準化の進め方

Slide 23

Slide 23 text

SRE標準化委員会の発足 ● 2021/8から各チームのSREsが有志で集まったグループ ● プロダクトの運用知見やツールを共有し、システム構築・運用の効率化、省力化を目指す 23

Slide 24

Slide 24 text

委員会メンバーで標準化を進める ● CI/CDの標準化をするサブチームを作る ○ 週次の定例で各チームの改善を共有 ○ Scrapboxに書いて非同期でコミュニケーションも ● 開発合宿も利用 ○ 同期的に集中してツールを作る ● 定期的に社内勉強会で成果を周知 24

Slide 25

Slide 25 text

各チームにヒアリング ● 各チームのテックリードにECS周りについてヒアリング ● チームが求めているものとのミスマッチを減らす 25

Slide 26

Slide 26 text

ヒアリングした結果 ● 多くのチームはGitHub Actionsを利用 ● ECSのデプロイに課題を感じている ● ブログで作ったワークフローを改善して再利用することに 26

Slide 27

Slide 27 text

GitHub Actionsの再利用 ● PublicでないReusable WorkﬂowやComposite Actionを同一組織で再利用可能に(2022/12) ○ GitHub Actions – Sharing actions and reusable workﬂows from private repositories is now GA ● ワークフローを集めたリポジトリを作る形に ○ 各チームでそのワークフローを利用する 27

Slide 28

Slide 28 text

リリース用リポジトリの展開 ● どんなサービスでもecspressoのファイルとそのCI/CDで中身はほとんど同じ ● ワークフローを配るよりももっと楽にしたい ● ブログで作ったものをテンプレートリポジトリとして用意 28

Slide 29

Slide 29 text

リリース用リポジトリのテンプレート ● 必要なワークフローなど揃えたテンプレート ● Cloneしてecspressoのファイルを置く ○ 既に構築したCI/CDをすぐ使える 29

Slide 30

Slide 30 text

標準化されたCI/CDを利用する流れ 30

Slide 31

Slide 31 text

CI/CDの実装もブラッシュアップ ● ブログの実装をMackerelチームで再構築 ● それをブックマークチームでさらに改善 ● その後標準として広めていく ○ 2チームで動く実績がある説得力がある 31

Slide 32

Slide 32 text

行った改善の例 ● ビルド待ちの短縮 ○ イメージにもう一度タグを付ける - Amazon ECR ● デプロイ履歴を確認しやすく ○ GitHubのリリースと連携 ○ Mackerelにアノテーション ● デプロイ順序を制御できるように ○ AとBを同時や順番にデプロイする 32

Slide 33

Slide 33 text

標準のアップデートをどう広めるか ● 考えられる懸念 ○ 各チームがアップデートに気付けない ○ アップデート作業が面倒で放置 ● Renovateを使うことで改善 33

Slide 34

Slide 34 text

Renovateで社内のActionを更新リリースノートも確認できる 34

Slide 35

Slide 35 text

標準化を狙うことで得られるメリット ● 影響範囲が広がり品質が上がる ○ 各チームからフィードバックがある ○ テストコードを書いたり変更管理をしたり ● OSSだと思ってメンテするような感じ ○ 将来OSSにしても良い 35

Slide 36

Slide 36 text

改善の成果 ● 採用したチームで現れた効果 ○ チームによってはデプロイ頻度が2倍に ○ ワークフローが整理されメンテナンスしやすく ● 複数チームで採用が始まる ○ 新卒研修でも使われるように ○ 採用したチームからフィードバックも 36

Slide 37

Slide 37 text

37 標準化する上で気をつけること

Slide 38

Slide 38 text

標準化する上で気をつけること ● 全チームの要望を解決しようとしない ○ 作るのにも時間が掛かる、メンテナンスも大変 ○ 汎用的すぎても課題を解決しづらくなる ○ 利用の強制はしない ● 意思決定やアップデートのプロセスを決める ○ 起きた問題をフィードバックして改善できるように 38

Slide 39

Slide 39 text

認知度を上げる ● 作るだけでなくちゃんと使われるようにするのが大事 ● 定期的に存在をアピールする ○ そもそも他の人が存在を知らないところから始まる ● 検証に協力してくれる人を探す ○ ファンを増やす 39

Slide 40

Slide 40 text

おわり ● はてなにおけるECSのCI/CD改善を紹介しました ● CI/CDの標準化に向けた動きとそれをうまく進めるための工夫についても紹介しました 40