マイクロサービス

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

従来の モノリス（一枚岩） は、画面・業務ロジック・データアクセスを 1つのアプリ にまとめ、1つの単位としてビルド・デプロイします。シンプルで、小規模なら最も生産的です。

マイクロサービス は、これを 業務の単位（ドメイン）ごとの独立したサービス に分割します。各サービスは、

• 自分のプロセスで動き、独立してデプロイ・スケール できる
• 自分専用のデータストア を持つ（他サービスの DB を直接見ない）
• ネットワーク（API・メッセージ）越しに連携する

観点	モノリス	マイクロサービス
デプロイ単位	アプリ全体を一括	サービスごとに個別
スケール	全体を増やす	必要なサービスだけ増やす
技術選択	基本は統一	サービスごとに選べる
データ	共有 DB が基本	サービスごとに DB
障害範囲	不具合が全体に波及しやすい	影響を 1 サービスに閉じ込めやすい
難易度	低い（最初は速い）	高い（分散システムの複雑さ）

何がうれしいのか

• 独立デプロイ：小さな変更を、そのサービスだけ素早く本番へ。全体の再デプロイが要らない（デプロイ戦略）。
• 個別スケール：負荷の高いサービスだけを増やせる。リソース効率がよい。
• チームの自律：サービス＝担当チームに分け、並行して開発できる（コンウェイの法則）。
• 技術の多様性：サービスごとに言語や DB を最適化できる。
• 障害の分離：1 サービスの不具合を全体に波及させにくい（設計次第）。

代償：分散システムの難しさ

プロセス内の関数呼び出しが ネットワーク呼び出し に変わると、それまで考えなくてよかった問題が一気に表面化します。

• 通信の信頼性：相手が落ちている・遅い。再試行・タイムアウト・サーキットブレーカーが要る。
• 可観測性：1 リクエストが多数のサービスを横断する。横断的なログ・指標・分散トレーシングが必須になる（可観測性）。
• データ整合性：DB がサービスごとに分かれるため、複数サービスにまたがる更新を 1 つの分散トランザクションにはできない。結果整合性や Saga で設計する。
• 運用の複雑さ：デプロイ対象・監視対象・ネットワーク経路が一気に増える。

どう分けるか（サービス境界）

分割の良し悪しは 境界の引き方 でほぼ決まります。技術レイヤー（画面 / ロジック / DB）で横に切るのではなく、業務の能力（ビジネスケイパビリティ） で縦に切るのが基本です。ドメイン駆動設計（DDD）の 境界づけられたコンテキスト が指針になります。

• 1 サービス＝1 つの責務。頻繁に一緒に変わるものは同じサービス にまとめる。
• サービス間は API かイベント だけで連携し、相手の DB を直接触らない。
• 最初から細かく割りすぎない。モノリスから始め、痛む境界から切り出す（モノリス・ファースト）。

データと通信

• データ：サービスごとに DB を持つ（Database per Service）。共有 DB は密結合を生むので避け、横断的な集計はイベントで複製した読み取り用データやデータ基盤側で行う。
• 同期通信：REST / gRPC。即時応答が要る場面。呼び出し連鎖が深いと遅延と障害が伝播する。
• 非同期通信：メッセージキュー / イベント。疎結合で耐障害性が高く、結果整合性を受け入れる。

通信の共通機能（再試行・mTLS・可視化・トラフィック制御）をアプリの外へ寄せたい規模になったら、サービスメッシュが選択肢になります。各サービスを Twelve-Factor App に沿わせると、コンテナ化やデプロイが素直になります。

いつ採用すべきか

• 向く：大規模・多チーム、機能ごとにスケール特性が大きく異なる、頻繁な独立リリースが要る。
• 向かない：小規模、少人数、ドメインがまだ固まっていない段階。

まとめ

• マイクロサービスは、アプリを 独立してデプロイ・スケールできる小さなサービス群 に分け、各サービスが 自分のデータ を持つ設計。
• 利点は 独立性（デプロイ・スケール・チーム・技術） と障害分離。代償は 分散システムの複雑さ（通信・整合性・可観測性・運用）。
• 成否は サービス境界 で決まる。技術レイヤーではなく業務単位で切る。分散モノリスは避ける。
• モノリスから始め、痛む境界から切り出す。規模と組織が大きくなってからが本番。