- アプリケーションの全機能（UI・ビジネスロジック・データアクセス）を1つのコードベース・デプロイ単位にまとめたシステムアーキテクチャのこと。ギリシャ語の「単一の石」が語源だ
- マイクロサービスと対比される概念で小規模なシステムでは開発・デプロイ・運用がシンプルなメリットがある反面、規模が大きくなるほど変更・スケールの難易度が高くなる
- 多くのシステムは最初モノリシックアーキテクチャで開発されて、規模が大きくなるにつれてマイクロサービスへ分割移行するという進化パターンを辿ることが多い
【深掘り】これだけ知ってればOK！
モノリシックとマイクロサービスの比較を整理しよう。モノリシック：全機能が1つのプロセス・デプロイ単位が1つ・サービス間通信なし・小〜中規模に向く。マイクロサービス：機能ごとに独立したサービス・個別デプロイ可能・REST/gRPCでサービス間通信・大規模に向くが運用複雑性が高い。正解はなくシステムの規模・チームの人数・成長速度に応じた選択が重要だ。
モノリシックファーストという考え方を理解しよう。Martinファウラーは「最初はモノリシックで作って、境界が明確になってからマイクロサービスに分割する」という「モノリシックファースト」アプローチを推奨している。最初からマイクロサービスで始めると過剰な複雑性（分散モノリス）になるリスクが高い。
モノリシックシステムの代表例として、初期のAmazon・Netflixは全てモノリシックで始まった。その後トラフィック増加・チームの拡大に伴いマイクロサービスへと移行した。現在もShopify・Stack Overflowなど大規模なモノリシックシステムが高いパフォーマンスで稼働している例がある。
よくある誤解
モノリシックは古いアーキテクチャで必ずマイクロサービスに移行すべきだと思っている
マイクロサービスは全てのシステムに適しているわけではなく、チームが小さい・規模が中程度・デプロイ頻度が低いシステムではモノリシックの方がシンプルで管理しやすい。適切なアーキテクチャはシステムの要件によって異なる。
モノリシックはスケールできないと思っている
モノリシックでも垂直スケール（サーバーのスペックアップ）・水平スケール（ロードバランサーで複数台に分散）で対応できる。マイクロサービスの「特定機能だけをスケール」という細粒度のスケールができないだけで、全体のスケールは可能だ。
会話での使われ方
今のシステム規模なら5人のチームでモノリシックのままで十分です。マイクロサービスにすると運用コストが跳ね上がります。
アーキテクトが小規模チームにモノリシック維持を推奨している場面。
モノリシックのコードベースが50万行を超えて、1つの変更が別の機能に影響するようになってきました。モジュール化を検討する時期です。
シニアエンジニアがモノリシックの限界を感じてモジュール化を提案している場面。
最初はモノリシックファーストで始めましょう。マイクロサービスの境界は、実際に運用してみないと正しく引けません。
テックリードが新プロダクトの初期アーキテクチャ選択の方針を説明している場面。
【まとめ】3つのポイント
- 全機能を1つのコードベース・デプロイ単位にまとめた最もシンプルなアーキテクチャ：小〜中規模のシステムではモノリシックの開発・デプロイのシンプルさがマイクロサービスの複雑さより有利なケースが多くまず機能を実現してから分割を検討するモノリシックファーストが推奨される
- 規模拡大に伴いモジュラーモノリスを経てマイクロサービスへ移行するのが自然な進化：モノリシック→モジュラーモノリス（内部モジュール化）→マイクロサービス（独立デプロイ）という段階的な分割移行がリスクを抑えながらシステムを成長させる現実的なアプローチだ
- マイクロサービスが万能ではなくシステム規模・チームサイズに応じたアーキテクチャ選択が重要：Shopify・Stack Overflowなど大規模なモノリシックシステムが高いパフォーマンスで稼働している実例があるようにモノリシックの適切な維持と内部整理が必ずしもマイクロサービスへの移行より劣るわけではない
よくある質問
-
Qモノリシックとマイクロサービスはどちらを選べばいいですか？
-
A
チームが小さい・規模が中程度・デプロイ頻度が低い段階ではモノリシックが向いています。チームが大きく（10人以上）・機能ごとに独立したスケーリングが必要・複数の技術スタックを使いたい場合はマイクロサービスを検討します。
-
Qモジュラーモノリスとは何ですか？
-
A
1つのデプロイ単位を維持しながら内部をモジュール（境界のある機能単位）に明確に分割したアーキテクチャです。モノリシックのシンプルさとマイクロサービスの内部整理の両立を目指します。
-
Q分散モノリスとは何ですか？
-
A
マイクロサービスに分割したのに各サービスが密結合していて独立してデプロイできない状態です。マイクロサービスのデメリット（複雑性・通信オーバーヘッド）だけを引き受けてメリットを享受できない最悪のパターンです。
-
Qモノリシックからマイクロサービスへの移行はどうやりますか？
-
A
ストランラーフィグパターン（少しずつ外側から機能を切り出す）・アンチコラプションレイヤー（旧システムと新システムの橋渡し）などの段階的移行手法が推奨されます。
【出典】参考URL
https://martinfowler.com/bliki/MonolithFirst.html ：Martin FowlerのMonolithFirst
https://microservices.io/patterns/monolithic.html ：microservices.ioのモノリシックパターンの解説
コメント