好きを組織還元していく~ギットハ部の取り組みを通じて~

この記事は CARTA TECH BLOG アドベントカレンダー2024 の 12/12 の記事です。

サポーターズでエンジニアをしている@y_chu5です。私はGitHubというサービスが大好きで、DashboardのLatest changesをワクワクしながら眺めるのが日課となっています。

そんな私が、社の仮想組織であるギットハ部に「GitHubが好きだから！」という理由で参加して、どう全社のGitHubの運用に携わっていったかを紹介します。また弊社のギットハ部のような、全社で採用しているサービスを実際に使っているエンジニアたちが管理する体制のススメについても触れていきます。

ギットハ部とは

ギットハ部は、CARTAのエンジニアが集まってGitHubの運用を考える部活です。

ギットハ部参加者は以下のとおりです。

CTO （suzuken）
事業部エンジニア（私含む数名）
ICT本部エンジニア（GitHubのowner、数名）

CTOのsuzukenが部長を務め、各事業部のエンジニアが数人、そしてICT本部のエンジニアが集まって、GitHubを全社でより活用できるように活動しています。

CARTA HOLDINGSでは、社内プロダクトのコードを直雇用社員のエンジニアが誰でも見えるような状態にしています*1。これにより、他事業部のコードから学ぶ機会が増え、更に透明性の向上にも繋がっています。

GitHubをより活用することはCARTAのソフトウェアエンジニアリングのレベルを高める上で重要なため、ギットハ部は立ち上がりました。

ギットハ部の活動

ギットハ部としていくつかの活動を行っていますが、メインの活動としては、おおむね2つあります。

各事業部のGitHub運用における課題の解決
- 入社タイミングからGitHubにアクセスするためのリードタイムの短縮
- 外部コラボレータの棚卸しプロセスの改善
開発者目線での知見共有
- 各事業部活用事例の共有
- GitHubのアプデ内容の共有

今まではICT本部（ホールディングスのコーポレートエンジニアリング部門）がGitHubの運用をメインに行なっていましたが、ギットハ部が立ち上がってからは、各事業部のエンジニアが事業部の抱えるGitHub活用への課題を持ってきて運用しています。これにより、各事業部の現場のエンジニアの声がより近くなりました。また、普段からGitHubを利用しているエンジニアの方がアプデに敏感だったり、こういうことを試してみたいという意見が多いため、それを元とした改善も行っています。

実例: GitHub-hosted Larger Runnersの導入

ここからは、私がギットハ部にジョインして行った活動の一つ、GitHub-hosted Lerger Runnersの導入について紹介します。

CARTAでは主にCIにGitHub Actionsを利用しています。柔軟なワークフローが組め、一般的に利用されているツール類を容易に使うことが出来るCustomActionsも豊富にあり、開発に欠かせないサービスとなっています。

しかし、時折CIの実行時間が長いという声が上がっていました。デフォルトで用意されているGitHub-hosted Runnersは、一般的なCIには十分なスペックを持っていますが、特定のプロジェクトにおいてはCPUスペックが足りなかったり、メモリが足りないということがあります。適切なキャッシュなどの利用によって、一部のStepは高速化できることもありますが、それでもCIの実行時間が長いということがありました。

その対応として、GitHub-hosted Larger Runnersの導入を検討しました。 GitHub-hosted Larger Runners（以下Larger Runners）は、GitHub-hosted Runnersよりもスペックが高いマシンを提供してくれるものです。

https://docs.github.com/ja/enterprise-cloud@latest/actions/using-github-hosted-runners/using-larger-runners/about-larger-runners

TeamプランやEnterprise CloudプランにIncludeされているクレジット以外の追加の料金課金が必要ですが、CI/CDの待ち時間などは開発体験、生産性に直結するため、追加課金以上の価値があると考えました。多くの企業の場合、無料枠のクレジットは通常の開発ですぐに使い切って、通常のRunnerに対して課金をすることが多いでしょう。しかしその課金をLarger Runnersにかけて、時間単位のコストが2倍かかっても時間が1/2、もしくはそれ程度になれば、1サイクルを回す速度が向上するため、人的コスト的に考えると十分な効果は得られるでしょう。

これらのコストのことを考慮しつつ、実際にLarger Runnersを導入するために行ったことを以下に記載します。

1. 事前調査

現在のCIの実行時間や何起因で遅くなっていそうかについて調査しました。

https://github.com/catchpoint/workflow-telemetry-action

このActionsにより、CPU使用率やメモリの使用量、I/Oのメトリクスなどを取得することができます。これにより、そのJobがCPU起因なのか、単純にキャッシュが効いていなくてネットワーク経由で取りに行っているのかを確認することが出来ます。

この収集した情報と、CIの実行時間を記録し、実際にLarger Runnersを導入することでどれだけ効果が出たかを比較できるようにしました。

2. 試験的導入

実際に調査を行ったリポジトリに対してLarger Runnersを導入しました。最もボトルネックになっているJobに対してLarger Runnersを導入し、そのJobの実行時間を比較しました。 およそ25%程度の時間短縮に繋がる結果となり、時間換算で1ワークフローが5分程度短縮されました。

CIが通ってからmerge、というフローを取っているため、レビューが通ってからデプロイまでの時間が1PRに対して5分以上短縮されることを考えると、十分な効果があると判断しました。

この実例を元に、Larger Runnersを導入することで、CIの実行時間を短縮することが出来るものもありそうだとギットハ部に共有し、導入を進めました。