はじめに
マイクロサービス化は、サービスごとの独立性を高め、スケールや開発速度を向上させる有効な手段です。一方で、運用を続けていく中でさまざまな課題も見えてきます。
今回はその中でも、リポジトリ数の増加によって発生した、依存ライブラリのバージョン管理などのメンテナンスコストの問題について書きたいと思います。
本記事は、プロダクト内製化やモダナイズに関する経験や試行錯誤を共有する、以下のアドベントカレンダーへの参加記事です。
マイクロサービス化で直面した課題
マイクロサービスを進めていくと、サービスごとにリポジトリが分かれ、結果としてリポジトリの数が膨大になります。
これにより、以下のような問題が発生しました。
- 共通ライブラリのバージョン管理が煩雑になる
- 依存関係の更新作業が各リポジトリに分散する
- CI や設定変更など、横断的な対応にコストがかかる
サービス自体は小さく保たれていても、全体としての運用負荷は徐々に大きくなっていきました。
対策としての mono repo
これらの課題に対する一つの対策として、mono repo を採用するという選択肢があります。
mono repo では、複数のサービスやライブラリを一つのリポジトリで管理します。これにより、以下のようなメリットが得られます。
- ライブラリのバージョンを一元管理できる
- 共通ライブラリを publish せずに直接参照できる
- 横断的な変更を一度に反映しやすい
- デプロイされるアプリケーション自体はマイクロサービス構成を維持できる
特に、共通処理や基盤系ライブラリの管理コストを下げられる点は、大きな利点だと感じました。
mono repo のデメリット
一方で、mono repo にも注意すべき点があります。
- リポジトリのサイズが肥大化する
- サービスをまとめる範囲を適切に検討する必要がある
- リリース単位や変更影響範囲の管理が難しくなる
すべてを一つにまとめれば良いというものではなく、どこまでを同一リポジトリで扱うかの設計が重要になります。
おわりに
mono repo にはメリットだけでなくデメリットもあるため、プロジェクトの特性に応じて慎重に判断する必要があります。
私のチームでは新規プロジェクトで mono repo を採用していますが、現時点では良い選択だったと感じています。
今後、運用を進める中で新たに困ったことなどが出てきたら、続編の記事としてまとめてみたいと思います。