マイクロサービス vs モノリシックサービス　〜組織はどちらを選択すべきか〜

背景

ソフトウェアアーキテクチャを考える際に、必ず当たる壁の１つが

マイクロサービス vs モノリシックサービス

かと思います。

本議題については、AWS Summit Japan 2024でセッションが設けられるなど、今なお議論される１つのテーマだと思います。

そこで、本記事ではマイクロサービスの特徴とモノリシックサービスの特徴をまとめ、その特性を踏まえて、どのタイミングで・どのように移行・意思決定するべきなのかについて紹介と思います。

マーティン・ファウラーが2014年にマイクロサービスアーキテクチャという概念を発表した、歴史的に新しいアーキテクチャ思想です。

マイクロサービスの持つ特徴は、以下の表にまとめることができます。

マイクロサービスの特徴	詳細
サービスによるコンポーネント化	独立的で交換可能なサービスとして、コンポーネントを分ける。個別にアップグレード可能な設計にする
分散ガバナンス	言語選定やデータベース選定などをチームに権限を与えて、最適な選択肢を選べるようにする
スマートエンドポイント	HTTPによる軽量メッセージシステムによるエンドポイントの提供
分散データ管理	ドメイン駆動設計におけるコンテキスト境界となるよにデータの管理を分解する
プロジェクトではなく、プロダクト	プロジェクトのように終わりある開発ではなく、継続的に改善するプロダクトとして提供する
インフラ自動化	自動テストや自動デプロイ、サービスモニタリングといったインフラの自動化を組み込んでいること
進化的設計	サービスの追加、変更、廃止が他のサービスに影響がないようにそれぞれ設計されること
ビジネスケイパビリティによるチーム化	ビジネス上の能力とそれを実現できる機能横断チームの単位にサービスを分解すること
失敗のための設計	１つのサービスが落ちても、それに応じた設計がなされ、非同期呼び出しなどによって遅延が全体に影響を与えないこと

これの特徴を踏まえ、モノリシックサービスと比較したときのメリット・デメリットを比較します。

	マイクロサービス	モノリシック
メリット	・シンプルな機能に閉じ込めることができるので、開発が高速になる・サービスごとに適切な言語や環境を選ぶことができる・必要に応じて一部のサービスのみ作り直すことができる	・開発初期にコストがかからない・言語や知識の統一がされるので組織変更後の立ち上がりが早い・全体的なボトルネックを見つけやすい
デメリット	・インフラコストはある程度増大する・サービスをまたがった改修コストがかかる・組織設計の修正コストが高くなる・障害点が追いづらくなる	・技術的負債がたまりやすく、作り直しが困難・チーム間のコミュニケーションコストが増えがち・徐々に開発速度が低下していく

マイクロサービスはモダンな開発手法として、注目を集めているためエンジニアとしては試してみたくなる気持ちがあるでしょう。

一方で、マイクロサービスは先述したその特性によりモノリシックサービスよりも、立ち上がり期における開発速度が低下する可能性が高いです。

そのため、まずはモノリシックサービスを通じてプロダクトを通じた仮説検証を繰り返し、ある程度軌道に乗ってきた段階でマイクロサービス化へ進んでいくことが望ましいと考えられます。

立ち上げ期からどちらかしかやらないのではなく、フェーズによって変えていくという姿勢や考え方が適切であります。

逆に、マイクロサービスへの移行を行わない・遅くなると、

など、ビジネスをスケールための障壁になっていきます。

それでは移行時期について考えてみましょう。

先述の通り、

立ち上げ期は組織の不確実性が高く、モノリスを選択したほうが機動的な開発が可能
一方で、組織の肥大化に伴いモノリスのデメリットが顕在化していくため、不確実性性が低減し、仮説検証が十分に行われた時期でかつ、組織規模が大きくなってきたタイミングでのマイクロサービスへの移行

がキーになります。これを図示すると下記のように表現できます。

不確実性と組織規模が交差する時期が移行検討の時期になると言えます。

ただし、移行期における既存の資産をうまく活用しソフトランディングした形で移行を進めるにために、徐々に移行していく必要があります。

具体的には、

またこれらの移行時にAPIを境界層として定義・活用することで、段階的な移行を進めることができます。

上記をまとめると、

といったことを行うことで、組織はマイクロサービス・モノリスの強み・弱みを上手に使うことができるようになります。

エンジニアリング組織論への招待