モノリスとマイクロサービスの違いは？分割する前の判断基準

ひよこ

モノリスって古い設計なの？

ペンギン先生

一つの単位としてまとめてデプロイするアプリの構成だよ。内部を整理したモジュラーモノリスもあるので、モノリスだからコードが雑という意味ではない。ファイル数やリポジトリ数だけで分類するものでもないんだ。

ひよこ

マイクロサービスは何が違うの？

ペンギン先生

業務のまとまりごとにサービスを分け、独立して変更・デプロイできることを目指す設計だよ。単にプロセスを分けても、毎回すべて同時に更新しないと動かないなら、独立性の利点は得にくいね。

ひよこ

分ければ障害も小さくなる？

ペンギン先生

影響を隔離する設計はできるけれど、自動でそうなるわけではないよ。呼び出し先が遅いと連鎖して詰まることもある。タイムアウト、再試行回数、代替動作などを決め、障害時も観測できるようにするんだ。

ひよこ

検索だけ混んでいたら？

ペンギン先生

独立した検索サービスなら、その部分だけ台数を増やしやすいよ。モノリスでもキャッシュやDB改善で解消することがあるので、まず実際のボトルネックを測ろう。分割しただけでは処理やDBの負荷は消えないんだ。

ひよこ

データベースも全部分けるの？

ペンギン先生

サービスが所有するデータと変更の責任を明確にするのが大事だよ。他サービスのテーブルを直接書き換える構成は、変更の独立性を損ないやすい。複数サービスをまたぐ更新では、一つのDBトランザクションと同じようには扱えない場合があるんだ。

ひよこ

Sagaなら全部元どおりになる？

ペンギン先生

Sagaはローカルな処理をつなぎ、失敗時に補償処理を行う設計だね。ただし一括のロールバックとは違う。送信したメールは取り消せないし、返金も別の業務処理。途中状態、再試行、重複、補償の失敗まで考える必要があるよ。

ひよこ

ESBとマイクロサービスは同じ？

ペンギン先生

ESBは複数システムをつなぐ通信・変換などの統合基盤として使われるもの。マイクロサービスはアプリの分割と運用の設計だよ。中央へ業務ロジックを集めるのか、サービスごとに責任を持つのかも違いになる。どちらも小さく分ける技術、とは整理できないね。

ひよこ

小さいチームならどう始めればいい？

ペンギン先生

運用の負担に見合う理由がなければ、内部の境界を整理したモノリスから考えるとよいね。独立したリリースや負荷対策が本当に必要な部分を、測定と試験をしながら切り出す。人数だけで決める固定ルールはないよ。

分割の利点と、引き受ける仕事

注文サービスを分ける前に考える例

注文・在庫・決済を分けるなら、「在庫確保に成功したが決済に失敗」「決済成功の応答だけ届かなかった」を考えます。決済を無条件で再試行すると二重請求につながるため、処理IDによる重複防止や結果照会、補償の責任を決めます。

まず内部モジュールの責任を整理し、独立して変更したい業務と、強い整合性が必要な範囲を洗い出してください。「有名企業が使っている」だけでは分割の理由になりません。

参考資料

確認日：2026年9月27日。製品の仕様・料金・対応環境は導入時にも確認してください。

• Lewis / Fowler: Microservices：独立デプロイ、業務境界、分散管理、ESBとの設計上の違い。
• Fowler: Monolith First：境界設計と分散化のコスト。
• Microsoft: Saga pattern：ローカルトランザクション、補償、再試行の考え方。