エンジニアリングMay 24, 20218 分 READ

Monorepo開発のメリット vs デメリット

Senior Manager, Marketing Insights and Strategy

Monorepoとは？

Monorepo(モノレポ)とは、アプリケーションやマイクロサービスの全コードを単一のモノリシックなリポジトリ (普通は Git) に保存するパターンを指します。一般的には、さまざまなアプリコンポーネントのコードをサブフォルダーに分割し、新機能やバグ修正には Git ワークフローを使用します。モノリシックアーキテクチャでアプリケーションやシステムを開発するのであれば、たいていは、こうしたアプローチを自然と採用することになります。

通常、このようなMonorepoでは、コードから実行可能なアプリケーションを生成するビルドパイプラインも 1 つだけです。この手法は、メンテナンスはしやすいのですが、全体的な開発速度は落ちます。修正に手間のかかるバグが少しあるだけで、リリース候補版を本番環境にデプロイできなくなってしまうからです。

この記事では、MonorepoとPolyrepo (ポリレポ) の違いを説明し、モノレポのメリットとデメリットを比較してから、モノレポがみなさんの開発チームにとって適切な手法かを判断する際のポイントをお伝えします。

マイクロサービス開発でのMonorepoとPolyrepo

マイクロサービスアーキテクチャの普及につれて、コードを多数のリポジトリに分割する (いわゆるポリレポです) チームが増えてきました。各マイクロサービスの開発チームはそれぞれ独立しており、それぞれの課題に合ったツールとプログラミング言語を使用します。たとえば、人工知能 (AI) を開発する開発者は Python を使用する一方で、API の実装を担当する開発者は Java や .NET を使用しているという具合です。

ポリレポのメリットは明白です。チームが 1 つだけでありその規模が小さければ、マイクロサービスを迅速に実装し、担当者が別々にデプロイを行なうことで、ソフトウェア開発のスピードを大きく高められます。

しかし、リポジトリの分割にはリスクもあります。複数のリポジトリを各担当チームがバラバラにメンテナンスするので、システムに関する知識が分散してしまうのです。 その結果、システム全体をビルドしデプロイする方法を知っている人がだれもいないという事態になりかねません。

マイクロサービスの開発では、ポリレポが当然の選択肢に思えます。しかし、モノレポの問題点は、ビルドとデプロイのパイプラインを統一し自動化することでほぼ解決できるものです。モノレポならではのメリットやよくある誤解を詳しく見て、みなさんのチームに適しているかどうかを考えてみましょう。

Monorepoのメリットとは？

モノレポには次のようなメリットがあります。

見やすい: 担当のマイクロサービスで他のマイクロサービスを呼び出す場合、該当するコードを見てしくみを把握できます。バグが発生した場合も、原因が自分の担当範囲にあるのか、他のチームのマイクロサービスにあるのかを突き止められます。
コードを共有できる: 複数のチームでさまざまなマイクロサービスを開発していると、コードが重複し、エンジニアリングの間接コストが増えがちです。リポジトリを単一化し、共通モデル、共有ライブラリ、ヘルパーコードをすべてまとめておけば、マイクロサービスが多くてもこれらを使いまわせます。
コラボレーションがしやすい: モノレポなら、チーム間に障壁やサイロが生じることがないので、連携性の高いマイクロサービスを設計、メンテナンスしやすくなります。
標準化が容易: モノレポは、ポリレポに比べてチーム間でのコードやツールの標準化が簡単です。ブランチポリシーを適用することで、メインブランチの簡素化や特定のブランチへのアクセス制限、命名ガイドラインの適用、コードレビュアーの配置、ベストプラクティスの実践を強制できるからです。完了済みの成果物に開発中のコードが混じってしまうこともありません。
状況を把握しやすい: モノレポでは、コード全体をひと目で把握できます。ポリレポに比べて、リポジトリ全体の状態の確認、全ブランチの調査、変更の追跡が大幅に簡単になります。
リリースを管理しやすい: モノレポなら、システム全体をデプロイする方法がわからなくなることはありません。ビルドとデプロイのパイプラインを自動化すれば、一部のチームだけがデプロイ方法を知っているという状況も避けられます。
リファクタリングが容易: モノレポでは、すべてのマイクロサービスに直接アクセスできるため、コードをリファクタリングしやすくなります。コードの構造変更も行えます。ソースコードを移動する際も、リポジトリ間ではなくフォルダーやサブフォルダー間で移動すればよいので、手間がかかりません。

Monorepoのデメリット

上述のようなメリットがある一方で、モノレポにはデメリットもいくつか存在します。共通のコードを変更すると、数多くのアプリケーションコンポーネントに影響が及んでしまいます。ソースの競合によりマージしにくい場合もあります。デプロイプロセスが複雑化する可能性があり、ソース管理システムのスケーリングも必要です。

とはいえ、状況さえ整っていれば、こうしたデメリットよりもモノレポを導入するメリットが上回ります。

Monorepoに関する誤解

マイクロサービスアーキテクチャでアプリを開発している現場では、モノレポについていくつかの誤解が見受けられます。たとえば、プログラミング言語やツールを複数使用している場合、ビルドプロセスを統一しづらいのでモノレポは適さないという意見があります。しかし、この問題は、コンテナを使用することで解消できます。各マイクロサービスをコンテナイメージ内でビルドしてから、それらを個々のユニットとしてデプロイすればよいのです。

マイクロサービスをコンテナ化すれば、個別のテストも可能になります。つまり、ビルドステージを多数のリポジトリに分散させることなく、モノレポで管理できます。ビルドターゲットがコンテナになることしか、違いはありません。

モノレポを導入するとコードの密結合が起きてしまう、という声もよく聞かれますが、必ずしもそうなるわけではありません。ただし、コードどうしが複雑にからみあうことのないよう、判断には注意が必要です。

マイクロサービスを開発する場合は、サービス間に依存関係が生じないように、それぞれの独立性を維持しなければなりません。チームでマイクロサービス開発のベストプラクティスとガイドラインを守れば、モノレポでもこれは実現可能です。

マイクロサービスは、コンポーネントと似ています。どちらのアイデアも、大きなシステムを、個別にデプロイ可能な結びつきのゆるい単位にまで分割する点は同じです。ただし、コンポーネントとは違い、マイクロサービスでは個々の単位がプロセスの境界を超え、(一般には REST API を使用して )互いに通信します。モノレポではマイクロサービスアーキテクチャのパターンがくずれやすいのは事実です。しかし、モノレポを導入するだけでコードの密結合が生じてしまうということはありません。

マイクロサービスの更新は個別に行うべきですが、モノレポではそれが不可能だと思われがちです。しかし、ローリングアップデートではなく、ブルーグリーンデプロイやカナリアデプロイなどの高度なデプロイ戦略を採用すれば、こうした問題は解決できます。前バージョンと並行して新しいバージョンをデプロイするので、新バージョンのマイクロサービスが期待どおりに動作するか確認できます。バグが見つかっても、すぐにトラフィックを前バージョンへリダイレクトすることが可能です。

自動化したCI/CD パイプラインを導入すれば、これまでに述べたモノレポのデメリットはすべて解消できます。それぞれの開発チームは、他のチームを邪魔することなく独立してマイクロサービスの開発に取り組み、コンテナイメージをビルドしてデプロイできるようになります。マイクロサービスをテスト環境でバリデーションしてから本番環境にリリースしたり、前バージョンと新バージョンを共存させたりすることも可能です。コンテナ化を導入すれば、それぞれのマイクロサービスのデプロイやテストを独立して行えるので、ツールやプログラミング言語の違いを気にする必要もありません。

モダンな CI/CD ツールなら、スケーリングは自動で行われ、複雑なデプロイの管理も簡単です。モノレポの規模が大きくなっても、マイクロサービスのビルド、テスト、さらにはデプロイまで個別に行えます。

チームに最適な戦略は？

それでは、みなさんのマイクロサービス開発には、モノレポとポリレポのどちらが適しているのか考えてみましょう。 1 つ目のポイントは、チームの文化。モノレポのメリットであるコラボレーションが盛んな開発は、みなさんのチームに合っているでしょうか？

2 つ目は、決まりごとの徹底。みなさんのチームでは、密結合のコードをつくらないような体制を築けるでしょうか？モノレポ内では、マイクロサービス間に依存関係が生じないようにしなければなりません。ただし、ブランチポリシーや権限の制限を利用すれば、この決まりごとは義務付けることができます。また、本番環境へのマイクロサービスのデプロイを行えるメンバーも制御できます。権限の設定を通じて、各サービスをデプロイ可能なチームやメンバーを指定することも可能です。

統一された自動 CI/CD パイプラインなら、こうした手法をすべて実装し、モノレポが大型化してもマイクロサービスを個々にビルド、テスト、デプロイできます。パイプラインを自動化することで、迅速にデプロイしながらもモノレポを簡単に管理できるしくみを整えられます。