マイクロサービス設計とは？サービス境界と独立性の考え方

はじめに
この記事で分かること
マイクロサービス設計とは
サービス境界を決める3つの観点
注文・在庫・決済で考える
DDDとの関係
分散モノリスを避ける
まとめ
関連記事

はじめに

マイクロサービスは、システムを小さく分ける方法だと説明されがちです。しかし、単にプログラムを分割しても、変更のたびに複数のサービスを直し、同時にリリースするなら独立性はありません。

重要なのは、注文や在庫などの業務上の責任を基準に境界を定め、サービスごとに変更・リリースできる状態を作ることです。この記事では、その境界をどう考えるかに範囲を限定します。

この記事で分かること

マイクロサービス設計の目的
サービス境界を決める3つの観点
DDDとの関係と分散モノリスの問題

マイクロサービス設計とは

マイクロサービス設計とは、システムを業務上の責任ごとに分け、それぞれを独立して変更・リリースできるサービスとして設計する考え方です。

モノリシックアーキテクチャでは、システム全体を一つの単位として配備します。マイクロサービスでは、業務上の境界ごとに配備単位を分けます。ただし、分ける必要がなければ、適切にモジュール化されたモノリスの方が単純です。

サービス内部で業務ルールと外部技術の依存関係を整理する考え方は、クリーンアーキテクチャとは？業務ルールを外部技術から分離する設計の考え方で解説しています。

サービス境界を決める3つの観点

業務上の責任

一つのサービスには、まとまりのある業務上の責任を持たせます。同じ目的を持ち、同じ理由で変更される処理は、同じサービスへまとめる候補です。

例えば、注文の受付、明細の変更、注文の確定は、注文を管理するという共通の責任を持ちます。在庫数の管理や商品の引き当ては、異なる責任として分けて考えます。

この判断には、凝集度と結合度の違い｜高凝集・低結合が望ましい理由と判断方法を適用できます。

データの所有

各サービスは、自分の業務判断に必要なデータの変更責任を持ちます。注文サービスは注文状態、在庫サービスは在庫数を管理するという形です。

ほかのサービスが内部テーブルを直接参照・更新すると、データ構造の変更が複数サービスへ波及します。データは、所有するサービスが公開したAPIなどを通じて利用します。物理的に別のデータベースを使うかより、誰がデータを変更するかを明確にすることが重要です。

変更とリリースの独立性

境界が適切かは、サービスを単独で変更・テスト・リリースできるかで確認します。一つの変更で複数サービスを毎回修正するなら、境界が細かすぎるか、責任の分け方が適切でない可能性があります。

担当チームが、ほかのサービスの内部実装を知らずに、自分のサービスを運用できることも判断材料です。

注文・在庫・決済で考える

注文サービスは注文内容と状態、在庫サービスは在庫数と引き当て、決済サービスは支払い結果に責任を持つとします。

注文サービスが在庫を確保するときは、在庫サービスへ「在庫を確保する」と依頼します。在庫テーブルの列や更新手順までは知りません。決済でも同様に、公開された操作と結果だけを利用します。

重要なのは三つに分けることではなく、それぞれの責任とデータを閉じ込め、相手の内部実装へ依存しないことです。

DDDとの関係

DDDの境界づけられたコンテキストは、同じ言葉とモデルを一貫して使える範囲です。業務上のサービス境界を見つける有力な手掛かりになります。

ただし、境界づけられたコンテキストとマイクロサービスは、必ず1対1で対応するわけではありません。業務上の境界が明確でも、独立した配備が不要なら、一つのモノリス内のモジュールとして実装できます。

DDDの全体像は、ドメイン駆動設計（DDD）とは？業務の言葉とルールをモデルに反映する考え方で解説しています。

分散モノリスを避ける

サービスを分けても、次の状態では独立性がありません。

複数サービスが同じ内部テーブルを直接更新する
一つの変更で複数サービスを同時に修正する
複数サービスを常に同じタイミングでリリースする

この状態は、分散モノリスと呼ばれます。モノリスの一体性を残したまま、ネットワーク通信や運用対象だけが増えます。

サービス数ではなく、変更を一つの境界へ閉じ込められるかで設計を評価する必要があります。サービスを分けた後は、通信、データ整合性、監視も別途設計する必要があります。

まとめ

マイクロサービス設計で重要なのは、システムを小さく分けることではありません。

業務上の責任と変更理由から境界を考える
各サービスがデータの変更責任を持つ
サービスを単独で変更・リリースできるか確認する
DDDの境界は手掛かりになるが、必ず1対1ではない
分割後も同時変更が必要なら、分散モノリスを疑う

どの責任をどこへ閉じ込め、何を独立させるのかを明確にすることが、マイクロサービス設計の中心です。

【テーマ一覧】