heyにおけるCI/CDの現状と課題

【スタンバイ× hey】急成長スタートアップSREのリアル(https://hey.connpass.com/event/250012/) での発表資料です。

Transcript

1. 　　 ©hey, Inc heyにおけるCI/CDの 現状と課題 プロダクト基盤本部 SRE 藤原涼馬
2. 自己紹介 藤原 涼馬 ヘイ株式会社 プロダクト基盤本部 SRE (他にもいろいろ) 経歴 　SIer R&D →　　　　　　→ 趣味 　自動車の運転 　模型製作 　各種寄稿・登壇 好きなAWSサービス 　ECS Fargate / AWS SSO + 他いろいろ 今ここ
3. 目次 • そもそもCI/CDの目的ってなんだっけ? • heyにおけるCI/CDの現状 • 今後どうしたい?という話
4. CI/CDの目的ってそもそも何？ • CIもCDも基本的には、 ”誰でも、いつでも同じ品質でタスクを実行する”ことを目的としています • CI(Continuous Integration; 継続的インテグレーション) ◦ リポジトリに格納されているコードを自動的にビルド・テストする手法 ref) https://aws.amazon.com/jp/devops/continuous-integration/ • CD(Continuous Deploy/Delivery; 継続的デプロイ/デリバリー) ◦ リポジトリに格納されているコードを自動的に本番環境に配置、配布する手法 ◦ デプロイ...トリガーまで自動化 ◦ デリバリー... トリガーは手動
5. CIを導入することで得られるもの • 個々人のローカル環境に依存しない形でテストが実行できる • コードに沿って機械がテストを実行するので、何回でも確実に同じ手順で実行 される(手順を読み間違えて作業するといったことが起きづらい) • コードに沿ってアプリケーションをビルドするので、誰が実行しても成功 or 失敗が明確
6. CI/CDを導入することで得られるもの • 個々人のローカル環境に依存しない形でテスト・ビルド・デプロイが実行できる • コードにそって機械がテストを実行するので、 誰が実行しても確実に同じ手順で実行される • コードにそって機械がアプリケーションをビルドするので、 誰が実行しても成功 or 失敗が明確 • コードにそって機械がアプリケーションをデプロイするので、 誰が実行しても成功 or 失敗が明確 属人性の削減と高いテスト・デプロイ頻度が得られる
7. CI: 高頻度で自動テストを実施することの重要性 不具合の修正にかかるコストを最小化する 不具合が混入してから長時間経ってから対応するよりも対応コストは低くなる https://speakerdeck.com/fufuhu/devopsdao-ru-zhi-nan-2020nian-du-ban?slide=164より
8. CD: デプロイ頻度の重要性 エンジニアリング観点 と ビジネス観点に分けて解説
9. CD: エンジニアリング観点でのでデプロイ頻度の重要性 高頻度でデプロイすることによる差分の極小化とそれに伴うMTTRの縮小 低頻度デプロイ 時間 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 デプロイ デプロイ 不具合発生 高頻度デプロイ 時間 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 デプロイ デプロイ 不具合発生 デプロイ デプロイ デプロイ 過去の変更に伴うものが爆発したの でなければこの部分の変更が原因の 可能性が高い
10. CD: エンジニアリング観点でのでデプロイ頻度の重要性 高頻度でデプロイすることによる差分の極小化とそれに伴うMTTRの縮小 低頻度デプロイ 時間 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 デプロイ デプロイ 不具合発生 高頻度デプロイ 時間 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 変更 デプロイ デプロイ 不具合発生 デプロイ デプロイ デプロイ 過去の変更に伴うものが爆発したの でなければこの部分の変更が原因の 可能性が高い 不具合原因の特定&修正にかかる時間(= MTTR): 低頻度デプロイ > 高頻度デプロイ 変更失敗率: 低頻度デプロイ(50%) > 高頻度デプロイ(20%)
11. CD: ビジネス観点でのデプロイ頻度の重要性 機能が早くリリースされるほど利用者への提供価値の総和は大きくなる 低頻度デプロイ 高頻度デプロイ 時間 提 供 価 値 時間 提 供 価 値 機能1 機能1 機能2 機能3 機能4 機能5 差分 機能2 機能3 機能4 機能5 差分 リリースせずに 寝かせている期間 リリースせずに 寝かせている期間 デプロイ デプロイ デプロイ デプロイ デプロイ デプロイ デプロイ デプロイ
12. CD: ビジネス観点でのデプロイ頻度の重要性 機能が早くリリースされるほど利用者への提供価値の総和は大きくなる 低頻度デプロイ 高頻度デプロイ 時間 提 供 価 値 時間 提 供 価 値 機能1 機能1 機能2 機能3 機能4 機能5 差分 機能2 機能3 機能4 機能5 差分 リリースせずに 寝かせている期間 リリースせずに 寝かせている期間 デプロイ デプロイ デプロイ デプロイ デプロイ デプロイ デプロイ デプロイ デプロイ頻度が高い方が 時間を跨って見たときの提供価値の総和は大きい
13. ここまでのまとめ 高い頻度でCIを回すし、CDも回した方がお得ですよ
14. heyにおけるCI/CDの現状
15. 現状の概要 • 現時点で全社的なルールが明確にあるわけではない • ある程度仕組みや方法論を揃えていきたいといった雰囲気は感じる ◦ 標準化とは行かなくても他プロダクトの良いところを取り込んだり、すでに直面した課題は回 避したいと思っている ◦ e.g. CI上のテストで積極的にモックを使うのか使わないのか？など • いわゆるCIやCDの品質とか成熟度といった部分はプロダクトによって異なる • なんとなく課題感はある
16. 個別プロダクトの状況 CIは全てのプロダクトに存在しています。 実施している内容や深さはプロダクトによって異なります。 プロダクト1 プロダクト2 プロダクト3 プロダクト4 プロダクト5 CI ・Circle CI ・PR単位でlintとテスト CD ・Circle CI ・mainブランチプッシュでリリース CI ・CircleCI(テスト) ・GitHub Actions 　(コンテナイメージビルド) CD ・Rundeck CI ・CircleCI -> GitHubActions ・lint, テスト(rspec, jest), E2E(mabl) CD ・GitHub Actions(chat ops with slack) 　ECS… ecspresso + CodeDeploy 　EC2… capistrano CI ・GitHub Actions ・テスト, Codacy(静的解析) CD ・GitHub Actions 　ECS … CodeDeploy 　EB … Swap URL CI ・GitHub Actions (C)D ・ローカルからの独自スクリプト
17. 全体的な傾向 • CI基盤としてはCircleCI、GitHub Actions(+ 一部で追加のSaaSを利用) • CDについては多少幅が出てきます ◦ CircleCI, GitHub Actions, Rundeck, (+ 独自スクリプト) ◦ コンピューティング基盤は徐々にECSに寄せていこうとしています
18. (プロダクトによっては)やってること • トランクベース開発 • E2Eテスト ◦ mablを活用した STORES 予約 のE2Eテスト戦略 - hey Product Blog • フィーチャートグルの導入 • CIパフォーマンスの測定
19. 現状の課題(とやりたいこと) • プロダクトによってはデプロイに要する時間が長く、 頻度を上げるための改善をしたい • デプロイ容易性などを上げる目的でECS移行を進めているプロダクトがある • 特定プロダクトの良い取り組みを他にも広めたい ◦ CIのモニタリング/E2Eテスト/フィーチャートグル • CI/CDにおける機密情報管理、セキュリティレベルの底上げ (現時点では具体的に問題が生じているわけではないが) ◦ AWSへのアクセスはOIDCベースに移行したい(GitHub ActionsでAWSのアクセスキーを管理したくない)
20. 現状の課題(とやりたいこと) • プロダクトによってはデプロイに要する時間が長く、 頻度を上げるための改善をしたい • デプロイ容易性などを上げる目的でECS移行を進めているプロダクトがある • 特定プロダクトの良い取り組みを他にも広めたい ◦ CIのモニタリング/E2Eテスト/フィーチャートグル • CI/CDにおける機密情報管理、セキュリティレベルの底上げ (現時点では具体的に問題が生じているわけではないが) ◦ AWSへのアクセスはOIDCベースに移行したい(GitHub ActionsでAWSのアクセスキーを管理したくない) 他にもやりたいことたくさんあります
21. まとめ • 前段セッションでもあった通り、SLO/SLI策定や測定するための仕組み作りは 重要です • それ以上にそもそも高いSLIを実現するにはインフラとアプリケーションその ものが重要です。CIの整備を通じてテストを高頻度で実行し、アプリケーショ ンコードの特性を可視化して改善をすすめられるようにしておきましょう。 • また、アプリケーションが無事にデプロイ出来なければSLOもSLIもありませ ん。ダウンタイムのより少ないデプロイ手法、より確実なデプロイ手法の実現 のためにCDを磨き込んでいきましょう。 • heyのプロダクトでもCI/CDについては状況はまちまちな状態です。取り組み たい事はCI/CDに限らずたくさんあります。CI/CDが何を果たしているのかを 理解した上で適切な優先順位付けをしてより良くしていくための取り組みを進 めたいと考えています。
22. ご清聴ありがとうございました