モジュラーモノリス
モジュラーモノリスとは
- アプリとしてはモノリス
- 単一のコードベースで構成される
- 内部的なモジュールを機能コンテキストの単位で分割
- 必要に応じて別のアプリケーションに分割（マイクロサービス化）できるようにする
- Webアプリの場合、ルーティンググループ毎にモジュール分割するのが良いかもしれない
モジュラーモノリスの目的
- いきなりマイクロサービスで開発するのはリスクが大きい
- とはいえ、明らかに独立性の高い機能は将来的なマイクロサービス化に備えて独立性を担保しておきたい
- 機能の境界を明確にすることで保守性を高く保ちたい
モジュールを分割するとは
- 機能毎にパッケージとして機能するようモジュール分割する、程度の意味
- PythonならPyPIパッケージ、RubyならGem、node.jsならNPMパッケージ etc...
- パッケージとして独立可能な状態にしておくことで、将来的なマイクロサービスへの移行に備えておく
- また、パッケージが担当する責務を明確にする目的もある
- 実際にパッケージとして独立している必要はなく、必要なタイミングでパッケージ化できる状態になっていればよい
- WEBアプリケーションの場合、あるルーティングのコントローラー以下が独立したパッケージになっているイメージ
DBは分割するべきか
- マイクロサービスへの移行を前提に考えているのであれば分割してもよいかも
- ただし、DBを分割すると否応無しに分散トランザクションの問題が発生するので開発難易度は上昇する
- 最初は共有DBモデルで開始した方がよいかもしれない
前提条件
ひとつのサービスの開発を行う複数のチームが存在する
- ひとつのサービスの開発に対して、複数のチームが協働する必要がある
- それらのチーム間の調整コストが高い
- 関与する開発者の人数が12人を超えている
- 逆に言うと、少数のメンバーだったりチームがひとつしかない場合、あえてモジュラモノリスを導入する必要はない
設計パターン
- 現実的に考慮すべきパターンは(1)(2)となる
- パターン(3)(4)はモジュール同士の依存関係が発生するのでわざわざモジュールを分割する意味が薄れてしまう
- パターン(1)があるべき姿ではあるが、DBの分割は設計難易度が高いのでいきなり挑戦するのはリスクが大きい
- スタート時はパターン(2)で開発し、システムの理解が進んだ段階で(2)に移行させていく方がコストパフォーマンスが良い
用語整理
モジュール
パッケージ
概念整理
概要図
プロダクト
アプリケーション
モジュール
DB
- サービスを稼働させることで発生するデータを保存する場所・仕組み・プログラム
- 一般的にアプリケーションとは別のプログラムになる（ex. MySQL、Redis、etc...）
サンプル実装
ディレクトリ構造
- 機能毎に関連するコードが局所化される
- 機能が増える毎にディレクトリ内のファイルが増えると関連するコードが分かりにくくなる
- 頑張って覚えてもいいが、人間の記憶に頼る運用は属人化に陥りやすい
参考資料