マイクロサービス導入を決断する前に: モジュラーモノリスという選択肢

はじめに

こんにちは、サービスシステムグループの佐々木です。

最近、多くの開発チームでマイクロサービスアーキテクチャが話題になっていますが、実際に導入してみると「思ってたより大変だった…」という声もよく聞きます。そんな中で注目されているのが「モジュラーモノリス」という考え方。今回は勉強会や自主学習で学んだことをまとめてみました。

モジュラーモノリスとは

モジュラーモノリスは、ソフトウェアアーキテクチャの一つのアプローチです。

従来のモノリシックアーキテクチャとマイクロサービスアーキテクチャの中間的な位置づけとして考えられていて、マイクロサービスを取り入れる上で課題があるのでモジュラーモノリスからはじめようといった選択肢でもあります。

まずは、マイクロサービス導入にあたっての課題について触れたいと思います。

マイクロサービスの現実：理想と現実のギャップ

マイクロサービスが解決してくれること

マイクロサービスアーキテクチャには確かに魅力的な利点があります。

• スケーラビリティ: サービスごとに必要な分だけスケールできる
• 技術の自由度: サービスに最適な技術を選べる
• チームの独立性: 各チームが自分のペースで開発・デプロイできる

ですが、新しい悩みも生まれてきます…

分散システムならではの難しさ

ネットワーク通信による複雑さ

マイクロサービスでは各サービス間の通信がネットワークを介して行われるため、モノリスにはない課題が生まれます。

• ネットワーク障害への対応: 通信エラー、タイムアウト、パケットロスなどへの対処が必要
• レイテンシの増加: サービス間の呼び出しにネットワーク遅延が発生
• 障害の波及: 1つのサービスの障害が他のサービスに連鎖的に影響する可能性

トランザクション管理の複雑さ

モノリスでは簡単だった処理も、マイクロサービスだと途端に複雑に。

マイクロサービス導入前には目的を明確に

❌ こんな理由はちょっと危険

• 「最新技術を使ってみたいから」
• 「他の会社もやってるから」

✅ こんな目的なら良さそう

• 機能ごとに独立してスケールしたい
• チーム間の開発サイクルを独立させたい
• 特定の技術要件に対応したい

マイクロサービスが向かない場面もある

こんな状況だと、マイクロサービス導入は慎重に考えた方が良さそうです。

スタートアップの初期段階

• システムがまだシンプルな時期は、マイクロサービスの運用コストの方が重い
• 要件がコロコロ変わる時期には、サービス境界の設計が難しい

ドメインがまだ曖昧な時

• サービスの境界が不明確だと、頻繁に境界を変更することになる
• ネットワーク通信でパフォーマンスが悪くなるだけになりがち

モジュラーモノリス：いいとこ取りのアプローチ

モジュラーモノリスは、マイクロサービスとモノリスの「いいとこ取り」を目指したアプローチです。

こんな特徴があります:

• 同じアプリケーションの中でモジュールとして分割
• サービス間の通信はネットワークを使わない
• 各モジュールの独立性は保ちつつ、分散システムの複雑さは避けられる

基本的な考え方:

• DDD（ドメイン駆動設計）と相性が良い
• サービス・ドメインをきちんと分離
• 高凝集・疎結合を目指す

モジュラーモノリスの良いところ・気になるところ

良いところ

✅ 開発の独立性が保てる

• モジュール境界がはっきりしていれば、独立した開発ができる
• 将来マイクロサービスにしたくなった時の土台にもなる

✅ 運用がシンプル

• ネットワーク通信のエラー処理で悩まなくて済む
• 単一DBなので、データの整合性確保が楽

✅ 段階的に進められる

• 必要に応じて個別モジュールをマイクロサービス化できる

気になるところ

❌ スケーリングに制約がある

• リソースを共有するので、個別モジュールだけスケールするのは難しい
• 全体のスケーラビリティには限界がある

❌ 技術スタックが統一される

• モジュール間で同じ技術を使う必要がある

実際にやってみるとしたら？移行戦略を考える（例）

段階的に進めるのがポイント

フェーズ1: まずは大きく分ける

フェーズ2: ドメインで分ける

フェーズ3: データベースも分けるかどうか検討

分割の順序：コードから？DBから？

おすすめは「コードから」のアプローチ

なぜコードからが良いの？

• 実際の利用状況を見てからDB分割を判断できる
• 失敗した時に元に戻しやすい
• リスクを段階的に管理できる

進め方のイメージ:

DB先行はちょっとリスキー

適用できそうなケース:

• 単一テーブルだけ参照する場合
• 明確にパフォーマンスが改善しそうな場合

注意したいこと:

• 短期的なメリットは少ない
• 複雑性が増すリスクがある

どこから手をつける？優先順位の考え方

効果的に進めるには、こんな優先順位で考えてみると良さそうです。

やっぱり「簡単で効果の高いところ」から始めるのが鉄則ですね。

モジュラーモノリスを学んでのまとめと今後の展望

データベース分割への新しい視点

従来、マイクロサービス化における最大の懸念はデータベース分割でした。しかし、モジュラーモノリスアプローチにより、この課題を段階的に解決できる選択肢があることを学びました。

アーキテクチャ選択の判断基準

学びを通じて各アプローチの適用場面が明確になりました。

マイクロサービス: 大量リクエスト処理、水平スケーリングが主目的の場合

モジュラーモノリス: 開発の独立性確保、段階的移行を検討する場合

モノリス: シンプルなシステム、明確な分割メリットがない場合

次のステップとして考えられること

実際に導入するとなったら以下のことから始めてみようと思いました。

1. 今のシステムを整理してみる
   • ドメイン境界の候補を洗い出してみる
   • 今困っていることを整理する
2. 小さく試してみる
   • 影響の少ない部分から実験的に導入
   • 効果を測る指標を決めておく
3. チームのスキルアップ
   • DDD（ドメイン駆動設計）について学んでみる
   • モジュール設計のパターンを勉強してみる

参考資料

• CloudNative Days 2024: モジュラーモノリス関連講演
• Modular Monoliths (Simon Brown)
• MonolithFirst (Martin Fowler)
• Microservice Premium (Martin Fowler)
• StranglerFigApplication Pattern
• Monolith vs Microservices (InfoQ)

---

この記事は実際の勉強会や自身の学びを基に、モジュラーモノリスという選択肢について整理したものです。実際の導入検討時には、各プロジェクトの特性や制約を十分に考慮することが大切です。