はじめに

• 正直、モノレポという言葉を知らない。ただ、Webアプリケーションの開発現場で、モノレポを使用しているケースが多々あり、その目的やメリットを知っておくべきである。そこで、今回はモノレポとは何かという基本的な概念を掴みたい。

モノレポとは

• 全てのコードベースを単一のリポジトリに管理すること。通常、それぞれのプロジェクトごとに別々のリポジトリを作成するが、モノレポでは全てのプロジェクトが一つのリポジトリで管理されるのが特徴。
• 反対に、各プロジェクトやパッケージごとに別々のリポジトリを作成して管理する方法をポリレポと呼び、従来から多くの開発チームで使用されてきた一般的なリポジトリ運用の形式。

モノレポのメリット

• コードの一貫性 .. 一つのリポジトリでコードを管理するため、異なるプロジェクト間での依存関係のバージョン管理やコードの共有が簡単になる。
• 依存関係の管理 .. 同じリポジトリにあるため、プロジェクト同士の依存関係が明確で管理しやすくなる。例えば、バックエンドとフロントエンドで共通のライブラリが使われている場合に、それらを簡単に更新したりバージョン管理できる。
• 統一された開発環境 .. ビルドツールやテスト環境を一つのリポジトリで管理できるため、全体的な開発体験が一貫する。
• リポジトリの一元化 .. 全てのプロジェクトが一つのリポジトリにあるため、アクセスが簡単で、CI/CDパイプ ラインのセットアップも一括して行える。（ポリレポの場合だと、各担当チームが別々にメンテナンスを行うため、システムに関する知識が分散し、システム全体をビルドしてデプロイする方法を確立するのが難しい）

モノレポに関する誤解とその解決策

• 複数のプログラミング言語やツールの使用とビルドの統一性 .. 複数の言語やツールを使用する場合でも、コンテナ化を活用することで、各マイクロサービスのビルドを独立して管理でき、モノレポでも問題が発生しにくい。
• モノレポとコードの密結合 .. モノレポを使用することでコードが密結合になるという誤解があるが、適切な設計とベストプラクティスを守れば、コードの独立性を維持できる。
• マイクロサービスの更新管理 .. モノレポではマイクロサービスの個別更新が難しいと言われがちだが、ブルーグリーンデプロイやカナリアデプロイなどのデプロイ戦略を用いることで問題を解決できる。
• CI/CD パイプラインによる自動化 .. 自動化されたCI/CDパイプラインを導入すれば、モノレポの運用による問題を解消できる。各マイクロサービスはコンテナ化されているため、個別の開発、テスト、デプロイが可能。
• 大規模モノレポのスケーリング .. モダンなCI/CDツールを活用することで、モノレポが大規模になっても、個別のビルドやテスト、デプロイが容易に行える。

モノレポツールの種類

• monorepo.tools には、モノレポツールの比較がまとめられている。有名どころだと、以下のようなツールがある。
  • Nx
  • Turborepo
  • Lerna
  • Bazel

モノレポを採用している企業事例

• identify株式会社 (2023-05-29時点) では、動画素材サービス「DeLMO」を運営しており、フロントエンドには3つの環境がある。これらを1つのリポジトリで管理するモノレポ構成を、Nxを使って実現していた。
• ファインディ株式会社 (2024-08-05時点) では、主にフロントエンドのリポジトリをモノレポとして運用している。
• メルカリShops (2021-08-18時点) では、各言語ごとにルートディレクトリが分割されており、それらの配下にそれぞれのapplication codeがある。BackendとなるMicroservicesにはGoを採用しており、BFF, FrontendにはTypeScriptを採用しているため、Go以下にMicroservices群、typescript以下にGraphQL, Web Frontendなどが配置されている。

モノレポ構成を考える

• 例) フロントエンドとバックエンドが分かれているプロジェクト.

  • 1つのリポジトリに全てのコードを管理する場合、以下のような構成を想定する。

  - project(root)
    ├── .github
    │   └── workflow
    │       ├── backend.yml
    │       └── frontend.yml
    ├── backend
    │   ├── api
    │   ├── auth
    │   └── test
    ├── frontend
    │   ├── admin
    │   ├── test
    │   └── user
    └── graphql
        └── schema
  

  • backendにはGolang, frontendにはNext.jsを使用。コード的に共通化できる部分はない想定。
  • CI/CD : Github Actionsを用いて実行。frontendの変更が行われた場合は、frontend.ymlが実行され、backendの変更が行われた場合は、backend.ymlが実行されるように設定すれば最低限のCI/CDパイプラインが構築できる。
  • GraphQL : projectディレクトリ以下にgraphqlディレクトリとして配置。バックエンドで作成したスキーマを配置して、フロントエンドでは参照し型定義を作成するようにする。backend、frontendのどちらからもアクセスできるようにするため、projectディレクトリ直下に配置。

まとめ

• 今回はモノレポについての調査を行い、どのような背景の下であったり、どのような利点が得られるのかについて調査を行った。肌間として、小規模のプロジェクトではモノレポを採用するメリットは少ないが、プロジェクトが大きくなり、チームが分割され、サービスの全体が見えにくくなるときに採用すると良さそうに感じた。
• モノレポを採用する場合には、しっかりとした知見が必要だと感じた。特に、リポジトリを一つにするという考え方は、責務の分離とは真逆の行動であるように感じるため、そのあたりを見極める必要がある。
• 今回は、モノレポについてざっと調査を行ったが、今後は実際にモノレポ導入のツールなどを使ってみて、その恩恵などを実感してみたい。

参考

• Findy Tech Blog
• circle ciブログ
• DeLMO Tech Blog
• mercari engineering
• giftee Tech Blog
• monorepo.tools