マイクロサービスは「マイクロ」じゃなくていい

はじめに

こんにちは。 たーとるマークでおなじみ（？）の亀崎です。 今回も個人の見解が内容の中心となっているのであえて記名とさせていただきました。
まずは最初に。『本記事は個人の体験・感想・考えであり組織を代表するものではありません。』

私はこれまであちこちで「Microservicesはどれくらいのサイズにすればいいのか、どれくらいに分割するのか？」といった質問を受けました。これに対する見解を今回はまとめたいと思います。

Microservices

背景

こういった内容を考えるとき、なぜMicroservicesが考えられたか、必要とされてきたかを理解しておくことが重要です。 Microservicesの必要性が認識されてきたのはやはり、AgileやDevOpsといったものが注目されてきたことと関連すると思います。

AgileやDevOpsが注目されてきた点については「なぜチームトポロジーは重要か」でも同じことを記述しています。

従来型の開発スタイルにおける課題を解決するなかで利用されてきたのがAgileであり、DevOpsというムーブメントです。 Microservicesもそうしたムーブメントの中で重要度が増してきたアーキテクチャです。開発スピードをあげるために、 Monolithcなアーキテクチャではなく機能別に分割したサービスを組み合わせ、それぞれのサービスが独立したチームにより開発し、 独立してデプロイ・リリースできるようにする。そうした要求を実現してきたのがMicroservicesです。

実は以前からサービスごとに分割することは試みられてきました。例えばSOAなどがそうしたものの代表です。 しかし、そうした取り組みはなかなか浸透しませんでした。その理由は様々ありますが、仕組みの複雑なことと、 個々のアプリケーションがまだ大きかったということがあると思います。
そうした中で登場したのがMicroservicesです。これまでに比べて個々のサービスを小さく実現しよう、きめ細かい粒度で実現したほうが うまくいくはずだ、そうしたアプローチから「マイクロ（小さい）」サービスと呼ばれたのだと思います。 あくまでもこれまでの方式と比較して「マイクロ」なサービスという位置づけでしょう。

MicroservicesのConcept

それではMicroservicesとはどういったものでしょうか？Sam Newman氏のMicroservicesの 書籍「Building Microservices, 2nd Edition」の最初の章にある 「Key Concept of Microservices」から引用します。

learning.oreilly.com

Key Concept of Microservices

• Independent Dependency
• Model Around a Business Domain
• Owning Their Own State
• Size
• Flexibility
• Align of Architecture and Organization

さきほどの背景でもあげられていて独立性は最初にあげられています。Agilityも実はそれ以外の項目により実現されるものです。

そして、「Size」です。 Sam Newman氏は

サイズについてあまり気にする必要はない。
サイズよりも重要な以下の２つのことにフォーカスすべきである。
（１）「いくつのMicroserviceを扱うのか」
（２）「密結合することなく、最大限に活用するための、Microserviceの境界をどう定義するか」

と述べています。

私個人の理解は、Microservicesの「Size」は、アーキテクチャによって変わって良いと考えています。 小さなチームで、アプリケーションそのものもそれほど大きくなければ、従来どおりのMonolithc Architectureで構わないし、 むしろそのほうが複雑性もなく、Agilityをもってリリースが続けられるため適切なはずです。
ある程度の人数のチームで、複数のアプリケーションから構成されるサービスに関しては、それぞれのアプリケーションの独立性を維持する範囲で 分割して作成したほうがよいでしょう。そうすることで、複数のチームがそれぞれ独立して、スピードをもってリリースを続けられるようになるはずです。 ただし、トランザクション境界が複数のアプリケーションにまたがるような構成は避けなければなりません。

つまり担当する開発者が認識できる範囲のサイズに留めることが重要となります。

• 「いくつのMicroserviceを扱うのか＝認識できる範囲に留める」
• 「密結合することなく、最大限に活用するための、境界を定義する＝独立性を維持する範囲で分割する」

といった内容になると思います。
これがもともとのMicroservicesの期待値にあった「適切な粒度」に該当するのだと考えます。

どうしても「マイクロ」サービスという言葉につられて、「小さくしなければならない」「大きさが問題である」といったイメージが先行してしまっていますが 実際には「マイクロ」なSizeが問題ではないのです。

Microservicesは 大きさにとらわれることなく、本来意識すべき点であるMicroservicesのConceptにフォーカスをあてて適切なアーキテクチャを考えましょう

それでもやっぱり難しいMicroservices

とはいえ、ではMicroservicesのConceptに沿ったアーキテクチャってどういうものになるんだ？　適切な粒度ってなんだ？ という点はやはり難しい問題です。 個人的にはこの点はDDD界隈のデザインパターンや「Bounded Context」といった点をしっかり検討することが重要だな、 と考えていますがこうした内容は別の機会に・・・。
道のりは長いかもしれませんが、とりあえず「サイズ」というものを１つクリアしただけでも一歩前進したと考えましょう。

最後に

私達のチームでは、Azure・AKSを活用したシステムのSIや内製化のお手伝いをさせていただいております。 システム・アーキテクチャどうしたらよいんだろう？といったご相談等ありましたらぜひご連絡ください。