マイクロサービスではどんな単位でサービスを分割すればいいか

最近、マイクロサービスアーキテクチャについて耳にすることが増えていますが、サーバレスのコンテンツと共に語られているケースもあり、「そのサービス単位では分割しすぎなのでは？」とたまに思います。
もちろん、何が正しいかはその現場のコンテキストによるとは思いますが、書籍「マイクロサービスアーキテクチャ」の第3章にサービスの分割についての考え方が記載されており、しっくりくるとても良い内容だったので、それをまとめてみました。
サービス単位を適度に適切に分割することでマイクロサービスの利点をより享受できるようになると思います。まずは、サービス分割のために重要になる概念を説明し、その後、サービス単位をどのように定めるのか記載していきます。

マイクロサービスアーキテクチャ

2つの重要な概念

マイクロサービスで優れたサービスを作っていくためには、「疎結合」と「高凝集性」という2つの概念を意識する必要があります。この二つの概念によって関連する振る舞いは一箇所にまとめ、他のサービスとの境界は通信ができる限り「疎」になるよう適切にサービスを分割していきます。「疎結合」ばかりに注目し、「高凝集性」を蔑ろにすると、必要以上にバラバラになったサービス群ができてしまって変化に対するスピードが遅くなってしまうのではと思います。

疎結合

マイクロサービスでは、あるサービスを変更しても他のサービスに影響や変更がなくデプロイできることが重要になります。
サービスはお互いが疎結合であることが求められます。疎結合のサービスは、連携する他のサービスに関して必要最低限のことだけしか把握しません。

高凝集性

機能を変更する際、その変更をできるだけ早くリリースするために、関連する振る舞いは一緒にまとめておく必要があります。
機能変更のために様々な箇所で修正が必要になると、その分多くのサービスをリリースする必要が出てくるのでリスクや変更にかかる時間が大きくなってしまいます。

サービス分割の考え方

例えば経理部門と倉庫を管理している部門があったときに、それぞれの仕事内容は全く異なります。経理部門に所属する人は倉庫の内部作業の知識は必要ありませんし、逆もまた然りです。
他の部署とのやりとりは、在庫報告書や給与明細など、決まったインターフェースを持ちます。

経理部門は倉庫の詳細な内部作業の知識は必要ありませんが、例えば下の図のように在庫状況を把握して企業評価の帳簿を最新に保つという業務があったときは「在庫品目」の情報が必要になります。
この「在庫品目」が経理部門と倉庫の2つのコンテキスト間の共有モデルになります。ここで注意が必要なのが、他の不要な項目は公開する必要はないということです。内部の情報を共有しないことで、結合が密になるのを防ぎます。

マイクロサービスでは、「倉庫」と「経理部門」のような、それぞれのコンテキストが分割される箇所と一致するようにサービスを分割していきます。（境界づけられたコンテキスト。）初めは粒度の荒いサービスになるでしょう。そして、そのうち、倉庫のサービスの中を、注文、在庫管理、入荷などの機能に分解できることに気づくと思います。
マイクロサービスの境界を検討する際には、まず大きく粒度の荒いコンテキストの観点で考えて、それからさらに分割する利点を考えていきます。時期尚早にサービス分割してしまうと、サービスリリースの際に多くのサービスの変更が必要になってしまい、結果として変更に関するコストが上がるので注意してください。

機能ごとにサービスを分割した方が効果的であると判断した場合は、それぞれのサービスを他の連携先のマイクロサービスから隠し、入れ子の状態にしておくと、結合も密になりにくく、テストもしやすくなるので効果的です。
ただ、サービスを入れ子にしておくのとトップレベルに切り出すか、入れ子にするかの選択に厳格な規則はありません。
判断する上で優先する事項として、組織構造に合わせてサービスを分割した方が管理がしやすいです。「倉庫」の仕組みを1チームで管理している場合は入れ子に、それぞれのサービス単位でチームがある場合はトップレベルに切り出しましょう。

最後に、「入れ子の方がテストもしやすくなる」を少しだけ深堀りします。
サービスを入れ子にしておくと、テストのときに各サービスをスタブ化する必要がなくなります。他のサービスと連携するような粗い粒度のAPIだけをスタブ化しておけば十分になるので、テストが簡単になります。
例えば「在庫管理」のサービスをテストしたい場合、データ連携しているサービスが多いと、以下のようにスタブ化しなければならない範囲が増えてしまいます。

まとめ

もちろん組織やサービスの状況などによって、どのようにサービスを分割するかという選択は様々だと思います。
ただ、「疎結合」ばかりに着目するのではなく、「疎結合」と「高凝集性」という2つの概念をバランスよく考え、組織構造と連携させるようにサービス分割するのが変更速度の高い状態を維持できるマイクロサービスになるのではと思います。
最初に記載しましたが、この内容は書籍「マイクロサービスアーキテクチャ」の第3章により詳細が載っています。マイクロサービスの利点や考慮すべきことが書籍を通して書かれており、とても面白い本なのでオススメです！

マイクロサービスアーキテクチャ