モジュラーモノリスは銀の弾丸ではない

はじめに

みなさんはモジュラーモノリスについてどんな印象を持っていますか？
「モジュラーモノリスはマイクロサービスとモノリスそれぞれの良いとこどりをしたアーキテクチャ」という認識を持った方が結構いるのではないかと思っています。
それは間違ってはいないのですが、じゃあモジュラーモノリスが銀の弾丸になるかというとそんなことはないと考えています。
また、一言でモジュラーモノリスと言っても実現方法によってメリット・デメリットが大きく変わる場合があります。

そこでこの記事では、モジュラーモノリスのパターン、利点、どうアーキテクチャを選定すべきかをご紹介します。モジュラーモノリスは銀の弾丸ではないと理解してもらえたら嬉しいです。

アプリケーションアーキテクチャのおさらい

アプリケーションアーキテクチャには、以下のような代表的なパターンが存在します。

• モノリスアーキテクチャ
• モジュラーモノリスアーキテクチャ
• マイクロサービスアーキテクチャ

モノリスアーキテクチャは、アプリケーション全体が単一のコードベースおよびデプロイ単位として構築されるアーキテクチャパターンです。モノリスアーキテクチャはシンプルで開発が容易ですが、規模が大きくなると保守性やスケーラビリティに課題が生じることがあります。

マイクロサービスアーキテクチャは、アプリケーションを複数の小さな独立したサービスに分割し、それぞれが独自のコードベース、デプロイ単位、およびデータストアを持つアーキテクチャパターンです。マイクロサービスアーキテクチャはスケーラビリティや柔軟性に優れていますが、分散システムの複雑性や運用コストが増大することがあります。

モジュラーモノリスの概要とパターン

モジュラーモノリスはShopifyやGitHubなどの大規模システムで採用されているアーキテクチャパターンで、モノリスアーキテクチャのシンプルさとマイクロサービスアーキテクチャのモジュール性を組み合わせたものです。モジュラーモノリスは、アプリケーションを明確なモジュールに分割し、各モジュールが独立して開発・テストできるように設計されています。
以下のような特徴を持ったアーキテクチャです。

• 単一のデプロイ単位としてアプリケーション全体が配布・実行される
• アプリケーション内部は明確なモジュール境界で分割されており、モジュール間の依存関係が制御されている
• 各モジュールは独立して開発・テストが可能であり、チームごとに担当モジュールを分担できる
• モジュール間の呼び出しは明確なインターフェースを介して行われる

冒頭でも少し触れましたが、これらの特徴を抑えたモジュラーモノリスには大きく以下の2パターンがあります。(厳密にはもう少し細かくパターンを分けることもできる気はしますが、ここでは代表的な2パターンに絞ります。)

• DBを共有せず、DBトランザクション以外の方法で一貫性を管理するパターン(パターン➀)
• DBを共有し、DBトランザクションで一貫性を管理するパターン(パターン➁)

パターン➀は以下のようなイメージです。

パターン➁は以下のようなイメージです。

パターン➁のほうがモノリスにより近い構成で、パターン➀のほうがマイクロサービスにより近い構成になります。

パターン➀とパターン➁の大きな違いはデータの一貫性の担保方法にあります。
パターン➀は補償トランザクションやイベント連携によってデータの一貫性を担保します。一方、パターン➁は同一トランザクション内でデータの一貫性を担保します。

補償トランザクションを実現するためには、Sagaパターンを実装した共通的なライブラリ(難易度が高い)やキャンセル処理などアプリケーションの設計・実装が必要になり、初期開発時のコストが増大する要因になります。これはマイクロサービスアーキテクチャと同様のデメリットです。
一方、DBトランザクションを利用するパターン➁は、アプリケーションの設計・実装がシンプルになる反面、モジュール間でDBスキーマを共有する必要があり、モジュール間の結合度が高くなる可能性があります。

このように一言にモジュラーモノリスと言ってもパターンによって得られる効果は大きく異なります。

各アーキテクチャパターンの比較

上述の通り、パターン➁のほうがモノリスにより近い構成で、パターン➀のほうがマイクロサービスにより近い構成になるのでそれぞれを比較します。

モジュラーモノリス(パターン➁)とモノリスの比較

モジュラーモノリス(パターン➁)は、モノリスアーキテクチャに比べて以下のような利点があります。

• モジュール境界の明確化により、コードの可読性・保守性が向上する
• チームごとの担当モジュール分担が可能になり、開発効率が向上する
• 依存関係の制御により、変更影響範囲が限定される

一方で、以下のような課題も存在します。

• 初期開発コストが増大する可能性がある(例えば、他モジュールのDBを直接操作できないように制御する仕組みの構築、各種ルールの確立、それらの標準化に準拠するための認知負荷など)

モジュラーモノリス(パターン➀)とマイクロサービスの比較

モジュラーモノリス(パターン➀)は、マイクロサービスアーキテクチャに比べて以下のような利点があります。

• 単一デプロイにより、運用・デプロイの複雑性が低減される
• 分散システムの複雑性回避により、開発・運用コストが低減される

一方で、以下のような課題も存在します。

• 単一デプロイになるためスケーラビリティが制限され、特定のモジュールのみを独立してスケールアウトすることができない
• マイクロサービスと異なりサーキットブレーカーなどの仕組みはないため障害の影響範囲が広がる可能性がある

では、どのアーキテクチャを選定すべきか

ここまでで、モジュラーモノリスにはパターンがあること、アーキテクチャによって一長一短あるということを示しました。

では、具体的にどのアーキテクチャを選定すべきでしょうか。
現時点での個人的な感覚ですが、以下のような考え方が良いかなと考えています。

• まずモノリスで始められそうかを考える
• 開発チームが多い(複数の会社が関与するなど)場合、モジュラーモノリスやマイクロサービスを検討してもよい
  • 高い頻度でデプロイすることが求められる場合、マイクロサービスを検討してもよい
  • 高い頻度でデプロイすることが求められない場合、モジュラーモノリスを検討してもよい
    • 将来的にマイクロサービスしていく可能性がある(高い)場合、モジュラーモノリス(パターン➀)を検討してもよい
    • 将来的にマイクロサービスしていく可能性が低い場合、モジュラーモノリス(パターン➁)を検討すると良い

これ以外にも組織の文化、開発体制、予算などによってどこまでチャレンジするかというのは変わってくると思います。

まとめ

結局どのアーキテクチャをどう選定すべきか答えはないのかと言われてしまいそうですが、私が伝えたいのはこの場合は必ずこれというような答えはないということです。

なので、様々なプロジェクト経験・情報収集を続け、どのようなアーキテクチャを選定するのが良いか都度考えられるようにしておくというのが重要だと思います。

とはいえ、1人が参画できるプロジェクトの数には限りがありますし、企業文化の違いによる差異など自身の経験だけでは把握しきれない部分もあります。
また採用したアーキテクチャが良かったかどうかは時間が経たないと分からないですが、その頃にはプロジェクトを抜けていることも少なくないと思います。

なので、皆さんの経験上どのような基準で選んでいくのが良さそうか、もしあればこの記事のコメントで教えていただけると嬉しいです！