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