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 パイプラインなら、こうした手法をすべて実装し、モノレポが大型化してもマイクロサービスを個々にビルド、テスト、デプロイできます。 パイプラインを自動化することで、迅速にデプロイしながらもモノレポを簡単に管理できるしくみを整えられます。
まとめ
Monorepoには、見やすさ、コラボレーションのしやすさ、コードの共有のしやすさなど、多くのメリットがあります。しかし、すべてのチームに最適とまでは言い切れません。 みなさんのチームの強みと弱みに基づいて、モノレポが本当に適切な選択肢かどうかを判断してください。
モノレポを採用することに決めた場合は、統一された自動 CI/CD パイプラインを導入して、ソフトウェアのデプロイのペースを維持しつつ、マイクロサービス開発でありがちな落とし穴を回避しましょう。 ぜひ、すぐに使い始められる CircleCI の無料トライアルをご活用ください。
