天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

Why monorepo? LayerXとソウゾウの採用理由に参加してきた

mercari.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていきたいと思います。

会の概要

以下、connpassのイベントページから引用です。

本イベントは株式会社LayerX 代表取締役CTOの松本勇気氏と株式会社ソウゾウ 取締役CTOの名村卓が、各社のmonorepo採用理由と開発体験、メリット/デメリットについてディスカッションするイベントです。

松本氏が先日公開し話題となった「monorepoをなぜ採用したか、及び大まかな構成: 三井物産デジタルアセットマネジメントでの事例」という記事と、名村がソウゾウのmonorepo運用についても触れた「メルカリShops の技術スタック、その後」の記事の内容を中心に、より深掘った内容をお話しいたします。

Q&Aも随時受け付ける予定です。皆さまのご参加をお待ちしております!

会の様子

monorepoを採用した理由

LayerXではサーバーサイドでスキーマ駆動なインターフェース定義をしていく中で、どのリポジトリにインターフェースを置くのか?このインターフェースが変更された時にどのリポジトリを変更しなきゃいけないの?といった点で開発者体験に課題があったということで、この課題を解決するためにmonorepoを採用したということでした。
この結果、テストが書きやすくなって開発者体験が向上した実感があるということです。

一方ソウゾウでは、マイクロサービスで開発を行っていたときに、マイクロサービスごとのバージョン管理やマイクロサービスごとにどのインターフェースを参照するのか?といった点で課題が出てきて、どんどんマイクロサービスのドメインに閉じた開発が進む引力が働いてしまい、monorepoを採用したという話でした。
こうしてmonorepoを採用したことに伴い、フロントエンドもバックエンドも開発者が一括で参照するようになり、やはり開発者体験が向上したというお話がありました。

また、LayerXでもソウゾウでもmonorepoを採用したことによる副次的な効果として、

  • リポジトリを跨いだsharedライブラリ(またはコピペコード)の肥大化を防げる
  • 柔軟なアーキテクチャ設計の実現(ここはソフトウェア特性的に別の基盤使った方がいいんじゃないの?となった時にサクッと構成変更ができるようになる)を通してアーキテクチャの境界線を開発しながら決めていくことができる

が挙げられていました。

monorepoのデメリット

まず、でかいバイナリファイルなどをリポジトリに置いてしまった時に、全リポジトリが重くなってしまうことが挙げられていました。multirepoだと、このリポジトリだけ重いからキャッシュを検討しようといったことがやりやすいものの、monorepoだと必然的に影響範囲が全てに広がってしまうということです。(これに派生して、将来マイクロサービスが数千単位になったときにリポジトリがめちゃくちゃ重くなってしまう懸念があるということでした)

また、周辺のツールチェーンがmonorepoに対応していないこともあるので、ツールチェーンの制限がされてしまうのは、monorepoのデメリットということでした。

monorepoでの開発体験とビルドシステム

LayerXではMakefileに統一しているということで、新規に参画した開発者もMakeFileを見ればどのようなビルドシステムになっているのかがわかるようになっているということでした。ただし、これは少数チームの早期立ち上げを前提に置いているところがあるため、将来チームやプロダクトをスケールさせていく時には、ビルドの構成を今よりも複雑に管理する必要が出てくるため、このやり方を見直ししないといけない時期が出てくるだろうと考えているそうです。

ソウゾウでは、bazelを採用しているということで、ビルド時にリモートキャッシュの恩恵をチーム開発で大きく受けられているというお話でした。
一方でbazelの整備には非常に時間がかかってしまってしまう*1デメリットがあるということで、この整備しているならネイティブのコンパイラに任せちゃえばいいじゃん、となってしまう面はあるというお話が出ていました。

monorepoの権限管理

LayerXではロールベース管理はしているものの、GithubからAWSをガツガツいじることがないので、teraformでAWSに対してプランかける部分だけOIDC経由でアクセス管理しているということでした。

ソウゾウではコードの権限管理はチーム全体に委ねている(&CIでチェックする)ということでした。
また、デプロイのパイプラインはGithub Actionsで全部管理(self-hosted runnerを活用)しており、プロダクションリリース時にApprovalを特定のエンジニアがするような仕組みにしているということです。

全体を通した感想

豪華な登壇者のお陰で、実際にmonorepoを採用してみて得られたメリットや起きた課題がかなり高い解像度でわかり、非常に学びが多いイベントでした。

冒頭で紹介されていたnoteと併せて、是非見返してみようと思います。

*1:bazelのルールは非常に独特で概念を理解するまでの時間がかかってしまう