2025-03-20 モジュラモノリスの限界
最近モジュラモノリスの限界を感じる言及をいくつか見たのメモ。
トランザクション設計
マイクロサービス含むモジュラモノリスのトランザクション設計の辛みについて。
Packwerk導入について
Railsでモジュラモノリスを構築する場合、Shopifyが出しているShopify/packwerkを導入するという選択肢がある。
さんざん手こずりながら厄介なトレードオフを繰り返して得た結果は、たった1個のパッケージのToDoファイルを消し去ったことだけでした（最初に完了できそうなのはこのファイルぐらいしかなかったことが後に判明しました）。その時点のコードはまだ壊れていて単独では動かず、ほろ苦い結果となりました。夢見ていた理想郷はどこにも存在しておらず、そこにいざなってくれると思っていたツールによって迷子になりました。
ref. Rails: モジュール化強制ツール”Packwerk”の導入を振り返る（翻訳）｜TechRacho by BPS株式会社
ありがたい知見だった。モジュラモノリス自体は有効な考え方であるものの、packwerkの導入自体はかなり慎重に検討すべきだと思っている派（ややネガティブ寄り）なので共感できた。» 反省 モジュラモノリス タイミーの試行錯誤と現在地 - Speaker Deck https://t.co/AFyPelelSM
— toshimaru (@toshimaru_e) March 15, 2025
Railsというフレームワークのアドバンテージはレールが整備されていることであり、それを自ら破壊しにいく（あるいは組み替えていく）Packwerkはかなり厳しいアプローチだと感じている僕でした。
分散モノリス
マイクロサービス設計のときは分散モノリスというアンチパターンに陥らないように気をつける必要がある。
モノリスからマイクロサービスへではマイクロサービスの定義として以下のように記述されています。
- 独立してデプロイ可能である
- ネットワークエンドポイントを介して連携
- データベースはサービス境界の内側に隠蔽される
- 特定の技術に依存しない
これらの定義通りのマイクロサービスが構築されていると、所有権の問題も解決され、デプロイや技術選定の自由をモノリス時代より得る事が出来ます。
“最悪のモノリスである、分散モノリス(distributed monolith)”だ。分散モノリスは多数のサービスを持つが、すべてを同時にデプロイしなければならないため、何かを行うにはチーム間の調整が数多く必要となる
What is 分散モノリス(Distributed Monolith)