インフラ専任者・チームがいない組織で 開発ワークフローの継続的改善に挑戦してみた / Challenge to improve development workflow

CI/CD Conference 2023
chiroru & Kousuke Ida & trowemsによる発表資料です。

https://event.cloudnativedays.jp/cicd2023/talks/1780

Transcript

1. インフラ専任者・チームがいない組織で 開発ワークフローの継続的改善に挑戦してみた chiroru & Kousuke Ida & trowems CI/CD Conference 2023
2. 自己紹介 chiroru (@chiroru_choooco) RailsやReactを用いて開発をしてきました。2022年12月〜SRE兼任 課外活動では、Rails GirlsやKaigi on Railsのオーガナイザーをしています。 (宣伝) Rails Girls Nagasakiを4/14,15に開催します！ https://connpass.com/event/276354/
3. 今日話すこと • 前提説明 (chiroru) ◦ 私たちが開発ワークフロー改善に取り組むことになった背景 ◦ 手始めにフロントエンド改善に取り組んだ話 ◦ 状況説明(バックエンド、CI) • 実際の改善内容 (Kousuke Ida) ◦ 1. Renderの検証 ◦ 2. Heroku v.s. Render ◦ 3. CIの見直し ◦ 番外編. 当社のOSS活動 • まとめ (chiroru) ◦ 番外 (trowems)
4. 今日話さないこと • 大規模な組織における新規サービス立ち上げ時のCI/CDブートストラップ • 改善したことの詳細な手順、機能の利用方法
5. 私たちについて • 企業のIR部門や金融機関向けのサービスを作っているスタートアップ • 正社員の開発者が5人しかいない小規模開発組織。 ◦ 全員が新規機能開発実装者 ◦ インフラ専任のエンジニアがいない • 立ち上げ当初から関わっていた開発者は、全員退職済み。資料が残っていない機能が多い。技術 負債も山ほどある。 ◦ ブログ参照 https://qiita.com/msetsu/items/cdab9c841d96cd4aa4c1 • ビジネス上の非機能要件の明確化、チーム内での信頼性を少しでも上げたい機運、trowems参画 が重なり、SREチームが2022年12月に立ち上がって、Kousuke Idaとchiroruが改善に尽力してい る。
6. アーキテクチャ図(変更前)
7. CI/CDの原則 開発チームのパフォーマンスを示す指標 Four Keys • デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度 • 変更のリードタイム - commit から本番環境稼働までの所要時間 • 変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%） • サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間 https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys -to-measure-your-devops-performance?hl=ja
8. かつてのFour Keys状況 デプロイの頻度 毎日 変更のリードタイム 10分程度 変更障害率 計測なし サービス復元時間 計測なし
9. きっかけ ビジネス的な成長が進み、後回しにしてきた課題の見直しフェーズに • セキュリティ面の強化 / 開発ワークフローの改善 ◦ 以前から利用していたHerokuの再検討を行うことに ◦ CI見直し ◦ フロントエンド見直し
11. フロントエンド環境(改善前) ステージング環境・本番環境のみをECS on Fargateで構築 • 担当者の使ってみたい欲ベースで技術決定 • レビュー環境が容易に作れない状況が続いてきた • 後任者がレビュー環境としてVercelを導入した • 環境差分と二重課金問題が生じた
12. フロントエンド環境(改善したこと) 比較検討した結果、全て環境をVercelに移行することを決定 • 手軽に簡単にVercel一本化ができた ◦ DXを高めることに成功した ◦ フルスタックのPaaSであるがゆえにCDNも手軽に導入できた
14. フロントエンド環境(改善その後) • Vercelでの全環境運用に今のところ問題はなし ◦ GitHub Integrationによる安定的なデプロイ • 強いて言えば、レビュー環境は改善の余地あり ◦ APIを伴う実装時の、手動対応が存在している • PaaSのフィット感 ◦ 環境構築や運用面での手軽さ
16. CI(改善前) • Ruby on Rails / React プロジェクト内には、4年前に導入された状態のRuboCop の設定ファイルが存在 ◦ 設定ファイルの更新を行ったが、実行は任意 • 不安定なテストが存在しており、単体結合テストが50%程度の確率で落ちる ◦ Flaky Testをトラッキングできず、修正が進まない • テストカバレッジを計測していなかったため、トレンドを認識できない
18. バックエンド環境(変更前) • Herokuを利用 ◦ Heroku BuildpackとRelease, GitHub Integrationにより安定的なCD (CDeployment) ◦ Herokuのオペレーティングシステムイメージである Stack（非Docker）に強く依存 ◦ VPC Peeringのネットワークレイヤーの複雑性が残ったまま • オレオレデプロイ問題 ◦ もともとHerokuではGitHub Integrationを使っていた（〜2022/4） ◦ 2022/4のHeroku Credentialsの漏洩問題 https://blog.heroku.com/april-2022-incident-review を受けてGitHub Actionsを利用した Herokuへのデプロイをするようにしていた（= オレオレデプロイ問題） ▪ Credentialsなどの管理対象の増加とActions minutesの浪費が問題
19. 作業内容の紹介 Kousuke Ida GitHub: @kotarou1192
20. 1. Renderの検証 そもそもRenderとは・・・？ • KubernetesベースのPaaS • HerokuのWeb dyno, Worker dynoと同等の機能 • Cron式でスケジューリングしてJobを実行できる • 静的サイト、プライベートサービス等も充実している • チーム単位で、固定アウトバウンドIPをもっている
21. なぜRenderを選択したのか？ • Fly.ioはVMベースだから選択肢から外れた • 一般的なDocker/OCIイメージベースでビルドしたアプリ ケーションをデプロイしたい • Herokuからの移行がスムーズに行えそう →Renderを検証してみた
22. Render検証結果 • Web dyno, Worker dynoの動作を確認できた • まだ荒削りな面があるが、開発が活発 → 本番環境としての利用にむけて準備を進めることに
23. HerokuからRenderへ移行完了🎉 • RenderはSyslogの出力をサポート • 私達はHerokuでPapertrailを使っていた ◦ PapertrailはSyslogにも対応している → そのまま使える！ • HerokuではOne-offなジョブのログをPapertrailに残していなかった ◦ Render移行で対応し、全体の見通しが良くなった
24. 2. HerokuとRenderの比較 Heroku • 洗練されたビルダーやランタ イム • アドオンが充実している • 日本語での手厚いサポート • 開発環境-本番環境のパイプ ラインを作成できる • UIが親切 Render • 後発だからこそのナウでヤン グな機能(IaC,コンテナランタ イム) • 低価格で最低限の機能 • 将来性 V.S.
25. CI面の比較 Heroku Render CIサービス 有(Heroku CI) 無 PRごとのレビュー環境 ボタン一つで可能 ボタン一つ/IaCで可能（難有り） Quality Gateなリリース ボタン一つで可能 自前実装が必要
26. CI面の比較 Heroku Render CIサービス 有(Heroku CI) 無 PRごとのレビュー環境 ボタン一つで可能 ボタン一つ/IaCで可能（難有り） Quality Gateなリリース ボタン一つで可能 自前実装が必要
27. CI面の比較 Heroku Render CIサービス 有(Heroku CI) 無 PRごとのレビュー環境 ボタン一つで可能 ボタン一つ/IaCで可能（難有り） Quality Gateなリリース ボタン一つで可能 自前実装が必要
28. CD面の比較 Heroku Render GitHub Integration 対応 対応 リリース毎のビルド回数 1アプリ(サービスN個)で1回 NこのサービスでN回 リリース時にコマンド実行 リリースフェーズで実行 難あり ビルドのキャッシュ効率 高効率 非効率
29. Heroku Render
30. CD面の比較 Heroku Render GitHub Integration 対応 対応 リリース毎のビルド回数 1アプリ(サービスN個)で1回 NこのサービスでN回 リリース時にコマンド実行 リリースフェーズで実行 難あり ビルドのキャッシュ効率 高効率 非効率
31. CD面の比較 Heroku Render GitHub Integration 対応 対応 リリース毎のビルド回数 1アプリ(サービスN個)で1回 NこのサービスでN回 リリース時にコマンド実行 リリースフェーズで実行 難あり ビルドのキャッシュ効率 高効率 非効率
32. 3. CIの見直し • Formatterが実行されていたり、いなかったりする問題 • Linterに従っていないコードが蔓延している問題 →Quality GateとしてCIに組み込んで解決！ うちのコード品質はどの程度のものなのか？ 定量化する方法はないか？ 品質はどのように推移しているか？ → Code Climate Qualityの利用で可視化 https://zenn.dev/msetsu/articles/43ed91339ed816
33. 不安定なテストの改善 Flaky Testのトレンドを可視化 → 頻度の高いものから解消
34. 不安定なテストの改善 Flaky Testのトレンドを可視化 → 頻度の高いものから解消
35. 番外編. 当社のOSS活動 https://devcenter.heroku.com/changelog-items/2528
36. Heroku buildack GoをGo1.20に対応させた https://github.com/heroku/he roku-buildpack-go/pull/508 (わたしです)
37. まとめ
38. PaaS変更での私たちのFour Keysの差分 Heroku時代 → Render移行後 デプロイの頻度 変わりなし 変更のリードタイム 10分から25分程度へ増加 変更障害率 変わりなし サービス復元時間 ネットワークレイヤー : 改善 アプリケーションレイヤー : 悪化
39. 継続的な改善 • CI/CDや開発プロセスの改善はSREチーム内で完結する訳ではない • 協業が必要 ◦ パートナー（Heroku, Render, AWS） ▪ お金を払う客だからと言ってすぐに応えてくれるわけではない ▪ OSS化された部分も多く、一緒によくしていくことが可能 ◦ 社内開発者 ▪ 「開発者」から「エンジニア」へ教育と理解が必要
40. ふりかえり
41. わずか1.5か月での改善 • エンジニアリングマネジメント • 開発からエンジニアリングへ • 開発プロセスの強化 • 2022年晩夏の大型資金調達 • 大手金融機関への導入がスタート • さらなるプロセスの改善を目指して CI/CD・DevSecOps・SETに関心の高いソフトウェアエ ンジニア(Ruby, TypeScript, Go)を募集しています @trowems (t郎): ソフトウェアエンジニアとしてキャリアをスタート。その後、 CTOやテク ニカルリード、エンジニアリングマネージャー、 ITスタートアップで SREチームやデータ分 析チームの立ち上げ、エンジニア採用タスクフォース、金融機関での金融新規サービス の立ち上げ、CtoCプラットフォームの開発、 DXスタートアップ複数などを経て、 4Q 2022のエンジニアリング組織マネジメント業務をミッションにみんせつに技術責任者とし てジョインし、エンジニア・プロダクトマネージャー・デザイナーの採用の改善と既存内部 環境の改善を並行して担う（現在）。複数社のハンズオンベースでの（技術的）顧問とし て活躍（現在）。過去に、 CI/CD系カンファレンスのプロポーザルレビュアーや CI/CD OSSなどの開発・コミュニティリードも兼務（一部進行形）。 Rails Girls Nagasaki ’23の ローンチメンバーとは仲良し。 Photo: https://unsplash.com/photos/fh2tFKFiqOc T: twitter.com/trowems23 Z: zenn.dev/trowems Q: qiita.com/trowems
42. 免責事項: 本発表内容は発表者個々人の見解に基づくものであり、発表者と関係する法人・組織などを代表するも のではありません。 本セッションサポートページ