MSAを整える。

＝モノリスとマイクロサービスの分割を、機能チップの振り分けで体感

マイクロサービスが初めての方は、先にそもそもマイクロサービスとは・どんな場面で使うかをどうぞ。

⚠️ 本ページは一般的な技術解説であり、個別のアーキテクチャ設計相談ではありません。モノリス・モジュラーモノリス・マイクロサービスの向き不向きや分割の基準は、流派・現場・チームの状況により判断が分かれ、「正解」を保証するものではありません。シミュレーターの機能例・依存関係は説明用に単純化した自作の一般的な例です。

機能をモノリス⇔サービスに振り分ける

下の機能チップをクリックすると、次の箱へ移動します。何度もクリックして、自由な組み合わせを試せます。

プリセット（クリックで一括設定）

機能チップ（クリックで箱を移動）送信ゼロ・この端末内だけで計算

依存関係（どの機能がどの機能を必要とするか）は、説明用に決めた既定の表から自動で決まります。ページ内では編集できません。

分割図 — サービスと通信線

箱＝独立してデプロイできる単位。箱をまたぐ矢印だけが「サービス間の通信線」です（同じ箱の中の依存は、プロセス内の呼び出しなので通信線になりません）。

結果

計算中…

サービス数

—

独立デプロイ可能な単位

—

＝サービス数と常に一致

サービス間の通信線

—

障害の影響範囲（選択中の箱）

—

この箱が落ちたら？

箱を選ぶと、道連れで完全に止まる機能（同じ箱＝同じデプロイ単位）と、呼び出し先を失って一部の処理が失敗する機能（別の箱から直接呼んでいた・1段階のみ）を色分けして図に反映します。実際のシステムでは、さらに先の箱へ連鎖する「カスケード障害」が起きることもありますが、本シミュレーターは単純化のため1段階までしか扱いません。

通信線の内訳

既定の依存表（全7本）のうち、現在の分け方で箱をまたいでいるものだけが「サービス間の通信」として数えられます。

呼び出す機能	呼び出される機能	現在の状態

モノリス／モジュラーモノリス／マイクロサービスの向き不向き

分割の向き不向きは、チームの成熟度・事業のフェーズ・組織構造によっても変わり、一概には言えません。以下は文献でよく紹介される「一般的な傾向」の一例であり、個別のプロジェクトへの当てはめを保証するものではありません（流派・現場により判断は分かれます）。

	モノリス	モジュラーモノリス	マイクロサービス
チーム規模	少人数〜中規模のチームでも始めやすいとされます。	中規模チームで、モジュール単位に担当を分けやすいとされます。	サービス数に応じてチームを分けられる規模で強みが出やすいとされます。
デプロイ頻度	1回のデプロイが全体に及ぶため、高頻度リリースには慎重になりやすいとされます。	依然として1つのデプロイ単位のため、モノリスに近い頻度になりやすいとされます。	サービスごとに独立してデプロイでき、高頻度リリースと相性が良いとされます。
データ整合性	1つのデータベース・1つのトランザクションで完結しやすく、強い整合性を保ちやすいとされます。	モジュールごとにスキーマを分けても、同一DB内に収めやすいとされます。	サービスごとにデータストアが分かれやすく、結果整合性への対応が必要になる場面が増えるとされます。
運用負荷	デプロイ・監視の対象が1つで、運用はシンプルになりやすいとされます。	モノリスに近いシンプルさを保ちながら、内部の境界を保ちやすいとされます。	サービスの数だけ監視・デプロイ・障害対応の対象が増え、運用の複雑さが上がりやすいとされます。

そもそもマイクロサービスとは

大きな1つを、小さな独立した部品の集まりにする。

マイクロサービス（MSA）は Microservices Architecture の略で、1つの大きなアプリケーションを、機能ごとの小さなサービスに分けて作る設計の考え方です。会員、商品、決済といった単位で別々に作り、サービス同士は API などのネットワーク通信でやり取りします。

身近なたとえでは、ひとつの大きな食堂ではなく、ラーメン・カレー・デザートの小さな店が並ぶフードコートのようなものです。1店が休んでも他は営業できますが、店どうしの連絡や運営は増えます。対になる考え方は、全機能を1つにまとめるモノリスです。

どこで・どんな場面で使うか

大規模なWebサービスの開発現場

利用者や機能が増えたサービスで、チームごとに担当サービスを持ち、独立してリリースする形があります。
クラウド・コンテナ環境の設計

AWS などのクラウドやコンテナ（Docker など）上で、サービスごとに動かす構成としてよく話題になります。
システムの作り直し（リプレース）の検討

古いモノリスを一度に作り直すか、機能ごとに分けて移すかの選択肢として出てきます。
SES・受託での設計レビュー

「全部分ければよい」わけではないため、分割の理由と通信の増え方を説明できるかが問われます。
応用情報・プロジェクトマネージャ

アーキテクチャ設計やシステム構成の話題で、用語として出てくることがあります。

向いている場面・向いていない場面

向いているのは、機能ごとに増え方や変更の頻度が違うサービス。独立して直せる・増やせる単位があると、分ける効果が出ます。
向いていないのは、小さなチームで作り始めたばかりのサービス。通信や運用の手間が先に増え、最初はモノリスのほうが楽なことも多いとされます。
「流行っているから」だけで選ぶと苦労する。分けるほど、障害の追跡や通信のやり取りといった別の難しさが増えます。

上のシミュレーターで機能を動かして、分け方によって通信線や障害の影響がどう変わるか試してみてください。

MSA（マイクロサービスアーキテクチャ）とは

MSA（マイクロサービスアーキテクチャ）は、1つの大きなアプリケーションを、機能ごとに独立してデプロイできる小さなサービスの集合として作る設計の考え方です。各サービスは自分の担当範囲（例：会員・決済など）に責任を持ち、他のサービスとはネットワーク越しの通信（多くはAPI呼び出し）でやり取りします。

対になる考え方がモノリス（モノリシックアーキテクチャ）で、こちらは全機能を1つのプログラム・1つのデプロイ単位としてまとめて作る、より古くからある形です。上のシミュレーターで「① 1つのモノリスにまとめる」を選ぶと、この状態を体感できます。特定の会社や書籍が最初に発明した用語というより、大規模なWebサービスの実務の積み重ねから、一般的な技術文献で整理されるようになった考え方だとされます。

「モジュラーモノリス」という中間形

モジュラーモノリスは、デプロイ単位は1つのまま（＝モノリス）で、内部のコードをモジュールごとにきっちり分け、モジュール間の呼び出しルールを決めておく作り方です。「機能ごとの境界を意識する」というマイクロサービスに近い恩恵の一部を、ネットワーク通信や運用対象の増加といったマイクロサービスの手間を増やさずに得ようとする、中間的な選択肢としてしばしば紹介されます。

注意点：本シミュレーターの「箱」は、あくまでデプロイ単位（本番にどう配る一塊か）の境界を表しています。モジュラーモノリスは内部のコード構造（モジュール境界）の話なので、デプロイ単位で見ると素朴なモノリスと同じ「1箱」になり、このシミュレーター上では区別がつきません。モジュールの境界の良し悪しそのものは、コードの内部構造を見ないと分からない、という限界があります。

「小さく始めて、必要になったら分ける」という考え方

最初からすべてを細かいサービスに分けるのではなく、まず1つのまとまり（モノリスやモジュラーモノリス）として作り始め、チームの人数やサービスの規模が大きくなった段階で、必要な境界だけを見極めて分けていく、という進め方がしばしば紹介されます。上のシミュレーターでいえば、まず「① 1つのモノリス」から出発し、必要に応じて「② 2つのサービス」「③ 全部バラバラ」へと段階的に動かしていくイメージです。

ただし、これも唯一の正解というわけではなく、事業の立ち上げ方やチーム構成によっては、最初から一定の分割を選ぶ現場もあります。分割は通信線・独立デプロイ・障害の影響範囲といったトレードオフを伴う判断であり、流派・現場により重視する軸が異なる、という前提でこのシミュレーターを使ってみてください。

DDDとの関係（通説）

DDD（ドメイン駆動設計）の「境界づけられたコンテキスト」（業務上の意味が閉じたひとまとまりの範囲）が、MSAでサービスを分割する際の単位の候補になりうる、とされます。ただし、これも流派・現場によって判断が分かれる通説であり、境界づけられたコンテキスト＝サービスと機械的に対応させるべきだと断定するものではありません。境界づけられたコンテキストの考え方そのものは「DDDを整える」で扱っています。

BDD・DDD・MSA・TDDの4つは、同じプロダクトで同時に使われることの多い設計手法です。どれか1つを選ぶという「選択問題」ではありません。

DDDを整える → BDDを整える → TDDを整える → 開発プロセスを整える → V字モデルを整える →

🔒 分割シミュレーターの計算・図の描画はすべてこの端末（ブラウザ）の中で完結します。入力（クリック操作）はサーバには送られません（送信ゼロ）。