モジュラモノリスについて調べたことをメモ

bmf-san アーキテクチャ
#モジュラモノリス

概要　

モジュラモノリスについて調べたことをメモする。

モジュラモノリスとは

  • モジュール分割をしたモノリス
    • モジュール分割はドメインによる分割が一般的に見えるが、機能分割や技術分割など様々なパターンを検討することができる
  • モノリスと同じく単一のデプロイメントパイプラインを持つ
  • メリット
    • モジュールが分割されているのでモジュール単位で開発を独立して行うことができる
    • マイクロサービスへの移行が容易
      • モジュール単位でマイクロサービス化を進めやすい
        • モノリスからマイクロサービスへ移行する際、ストラングラーパターンとしての位置づけができる（但し楽に移行できるとは限らない）
      • モジュールの境界の見直しがしやすいので、マイクロサービスよりも境界の変化に柔軟に対応できる
  • デメリット
    • モジュール間の境界を超えやすい
      • マイクロサービスはネットワークを介して通信するため、モジュール間の境界を超えることができないが、モジュラモノリスはそうではないため境界違反の扱いに注意する必要がある
    • モノリスと同じだが、デプロイメントのパイプラインは単一なので、肥大化したりモジュール間の依存関係が複雑になったりすると運用が難しくなる
    • 各モジュールが単一のDBを共有している場合、マイクロサービス移行時のコストが高くなる

Service Weaver

モジュラモノリスとして開発し、マイクロサービスとしてデプロイするためのツールとして、GoogleがService Weaverというものをリリースしている。

所感

モジュラモノリスというものに少しの夢を見ていたのだが、所感としてはポエムを書きたくなったので綴った。

組織の拡大に合わせてアーキテクチャも進化が必要になってくるのが筋だと思うが、組織のスケーラビリティに柔軟に対応できる、あるいはコストがかかり過ぎない銀の弾丸のようなアーキテクチャがないかなぁと思ったりした。（ない。）

組織は拡大したり、縮小したり、変化しなかったりするような時もあるとは思うが、会社は成長を前提とするので組織のスケーラビリティには前のり気味で投資していくのが良いのかなぁなどと思った。

このへんの話に関して引用したい文章があったので、そちらを記載して締めとする。

しかし、ここで注目しなければいけないのは、両者のライフサイクルの違いです。 組織やチーム配置は、その気になれば会社の方針次第で翌日から変更できます。 しかしアーキテクチャやシステムは、組織のようにすぐ変更することが困難です。

cf. eh-career.com - モジュラモノリスに移行する理由 ─ マイクロサービスの自律性とモノリスの一貫性を両立させるアソビューの取り組み大規模

参考