CI/CD Conference 2023より、Herokuから移行を行った小規模チームのCI/CD改善セッションを紹介

連載 [第4回] :

CI/CD Conference 2023レポート

2023年6月12日(月)

CI/CD Conference 2023から、5名という小規模の開発チームがCI/CDの改善を行ったセッションを紹介する。

CI/CDに特化したカンファレンスCI/CD Conference 2023から、小規模開発チームがHerokuからPaaSを移行した体験を解説するセッションを紹介する。タイトルは「インフラ専任者・チームがいない組織で開発ワークフローの継続的改善に挑戦してみた」というもので、セッションはchiroru氏、Kosuke Ida氏、trowems氏がそれぞれのパートを解説するというチームワークで実行したセッションとなっている。chiroru氏は問題点の概要と解説、フロントエンド環境の移行について、Kosuke Ida氏はバックエンドをHerokuからRenderへの移行の解説とテストについて、trowems氏は最後の総評をそれぞれ担当している。

●動画：インフラ専任者・チームがいない組織で開発ワークフローの継続的改善に挑戦してみた

セッションのアジェンダを紹介

この3人が所属する株式会社みんせつは「企業IR部門と機関投資家がつながるプラットフォーム」としてSaaSで投資家向けの情報提供サービスを行っているスタートアップで、「みんせつ」という社名の由来は「みんなの説明会」であるという。2015年に別名で創業した後にさまざまなアプリケーションを開発し、サービスの拡充を行っている。正社員の開発エンジニアは5名という小規模な構成で、インフラストラクチャーの専任が存在せず、当初の開発者も全員退職し、ドキュメントも残っていない機能が多いという。このような人材の回転が速いスタートアップならではの悩みを持っていることが紹介された。

みんせつの開発チームは5名の少数構成。しかも技術負債も山積み

CI/CDの改善という観点から、Googleが提唱するCI/CDの原則の中の指標について解説。これを改善前、改善後に比較することで定量的に改善を行おうという意図が感じられる。

CI/CDの原則を紹介

ここではアプリケーションの本番環境へのデプロイの頻度、変更が反映されるために必要な準備時間（リードタイム）、変更によって障害が発生する確率、障害から正常なサービスの状態に戻るために必要な時間、以上の4つを指標として採用するべきと説明した。

改善前はデータが採取されていたのは2つの指標のみだった

ただし、後半の2つの指標、変更障害率とサービス復元時間については、実際に障害が起こった経験がないということで計測されていないという。つまりデプロイ頻度と変更のリードタイムだけが改善前に測定されていたことになる。デプロイは毎日実行、変更のリードタイムも10分程度ということでここだけみれば改善が必要なのか？という疑問も湧くだろう。

きっかけはセキュリティ面の強化、開発ワークフローの改善などであると次のスライドで説明した。

Heroku、CIフロー、フロントエンドのプラットフォームの見直しを実行

実際の構成図を使って説明し、AWS上のECS on Fargate、Vercel、GitHubなどを使って開発していたが、Vercelによるレビュー環境とFargateのステージング＆本番環境に分かれており、環境差分とコストの二重化が発生していたと語った。

フロントエンドの改善前の状況

これをVercelに全面的に移行し、レビュー、ステージング、本番ともPaaSであるVercelで実行したことで、開発エンジニアの使い勝手が向上したと説明した。

Vercelに全面移行し、DXが向上

またCIについてはRuby on Rails/React.jsを採用したプロジェクトについて、RubyのLinterであるRoboCopが4年前に導入されたままの状態でメンテナンスされていなかったこと、単体テストの実行で不安定な結果を出すものが50％程度存在し、フレーキーテスト（実行結果が不安定なテスト）となっていたこと、テストカバレッジを採取していなかったことなどを改善すべきポイントとして挙げた。

CIの改善が必要なポイントを整理

バックエンド環境についてはHerokuとGitHub Integrationを使っていたが、BuildpackがDockerではないことなどのHerokuに依存する問題点が発生したことやクレデンシャル漏洩問題なども含めて、Herokuから別のプラットフォームへの移行を決めたことなどを解説した。

バックエンド環境をHeroku以外に移行

そこでHerokuの代替としてRenderの検証を行ったという。ここではRenderをKubernetesベースのPaaSと紹介し、Herokuの持つ多くの機能を代替できることを説明した。

Renderを使ってHerokuから移行を検証

参考：https://render.com/

選択をする際のポイントとして、コンテナベースのアプリケーションイメージをそのまま実行に使いたいということが大きかったという。

HerokuからRenderに移行する時のポイントはアプリケーションイメージの違い

比較も行っており、Herokuが永らくPaaSとして存在する背景をまとめた内容となったが、新しいPaaSであるRenderのメリットについては、価格が安いこととコンテナイメージを採用していることなどを挙げている。

HerokuとRenderの比較を実行

またCIについてはHerokuには独自のCIサービスが提供されているが、Renderにはそれがないこと、プルリクエストごとにレビューを行う機能もないことなどが挙げられている。

CIについてのHerokuとRenderの比較

またCDについてはビルドの仕組みが大きく異なっており、Herokuが1回のビルドで複数のサービスや環境に利用できる反面、Renderはプルリクエストのたびに毎回ビルドが実行されてしまうことなどを説明した。

CDについての比較

ビルドの実行についてはチャートを用いて説明。ここでもHerokuが効率的なイメージビルドを行っていることを紹介した。

HerokuとRenderのビルド実行に違い

また不安定なテスト結果については、トレンドを可視化することで解決しなければいけない問題点を明らかにし、徐々に改善を行ったと説明。

フレーキーテストを解消するためにトレンドを分析

ここでHerokuからRenderに移行したことでCI/CDの4つの指標がどう変化したのか？を説明。このスライドでは変更のリードタイムが増加していることを説明したが、コスト面や環境による違いがなくなったことなど、デベロッパーにとっては大きな改善点があることがわかる。

変更のリードタイムが増加した原因はビルド時間の増加？

まとめとして、CI/CDや開発プロセスの改善はSREチームだけで完結しない、プラットフォーム側のパートナーとも協力する姿勢が重要、「お金を払う顧客だからと言ってもすぐに対応してくれるわけではない」などを挙げて、小規模チームならではの考察を加えて説明を終えた。

CI/CDの改善のポイントはチームワーク

最後にtrowems氏が1ヶ月半という短い時間の中でPaaS移行、CI/CDの改善が行えたことを自賛してセッションを終えた。5名のエンジニアチームで2名をSREに割り当ててPaaSの乗り換えからCI/CDの改善までを行ったという、みんせつのセッションだった。以下のエンジニアリングブログには少数のポストしか存在しないが、こういうタイトルでブログ記事を書きたいというメモ的なものがAdvent Calenderの形で残っている。

●参考：みんせつのエンジニアが書いているブログ

●参考：Advent Calender 2022

今回のセッションの解説も含めてブログの投稿が持続することを期待したい。