モノリス

モノリスとは

モノリスは、全機能を 1 つのデプロイ単位にまとめたアーキテクチャである。シンプルで開発が速いが、大規模化するとデプロイの遅延やチーム間の調整コストが増加する。

モノリス vs マイクロサービス

モノリスとマイクロサービスの違いを以下にまとめる。

観点	モノリス	マイクロサービス
デプロイ	全体を一括	サービスごと
スケーリング	全体をスケール	サービスごと
開発速度 (初期)	速い	遅い (インフラ構築)
開発速度 (大規模)	遅い (調整コスト)	速い (独立)
運用の複雑さ	低い	高い
トランザクション	容易	分散トランザクション

モノリスの問題

モノリスの問題を以下にまとめる。

問題	説明
デプロイの遅延	小さな変更でも全体をデプロイ
スケーリングの非効率	注文処理だけスケールしたいのに全体をスケール
チーム間の調整	同じコードベースで衝突
技術スタックの固定	全体が同じ言語・フレームワーク

モノリスの段階的分割

モノリスの段階的分割を図で示す。

Phase 1: モノリス (1 Lambda)
Phase 2: モジュラーモノリス (内部を分離)
Phase 3: マイクロサービス (Lambda を分割)

いつモノリスを選ぶか

分割するかどうかは規模の大小ではなく、境界を間違えたときにやり直せる余地が残っているかで考える。

場面	判断	理由
新規開発でこれから仕様が動く	モノリスで始める	境界の引き直しがコードの移動だけで済み、サービス間の通信やデータの分割をやり直す作業が発生しない
チームが 1〜5 人	モノリス	分割しても並行して開発できる人数が増えるわけではなく、増えるのはデプロイ対象と監視対象の数になる
どこで機能を切れるか見えていない	モノリス	間違った位置で切ると分散トランザクションを抱え込むため、境界が見えるまで 1 つのデプロイ単位に留める
チームが 10 人以上で同じコードの変更が衝突する	分割を検討	リリースの足並みを揃える調整が重くなり、独立してデプロイできる単位に切る利点が運用の複雑さを上回りはじめる

より深く学ぶには関連書籍が役立つ。