モノリスとマイクロサービス — 分けた境界の数だけ、失敗の仕方が増える

What — 分けると、何が変わるか

モノリスは、1つのプロセスとして動き、1回でデプロイするアプリケーションです。マイクロサービスは、機能ごとに別々のプロセスとして動き、別々にデプロイするアプリケーションの集まりです。

分けたとき、コードの中で起きていたことが、ネットワークの上で起きるようになります。

モノリス

1つのプロセスとして動き、1回でデプロイするアプリケーション。

マイクロサービス

機能ごとに別々に動き、別々にデプロイできる、小さなサービスの集まり。

モジュラーモノリス

1回でデプロイするが、内部をモジュールに分け、モジュール間の依存を強制的に制限したモノリス。

分散モノリス

サービスに分かれているのに、一緒に変更・一緒にデプロイしないと動かない状態。両方の短所を持つ。

分けると得られるもの、払うもの

1つのリポジトリ・1つのプロセス・1つの DB

Why — なぜ分けても速くならなかったのか

マイクロサービスで得たいのは、独立して変更し、独立してデプロイできることでした。独立して変えられるのは、変更がそのサービスの中で閉じるときだけです。

冒頭のチームは、境界をデータの名詞（会員、商品、注文、ポイント）で引きました。ところが、機能の追加は名詞に沿って起きません。「注文履歴に獲得ポイントを出す」は、注文とポイントと画面をまたぐ変更です。変更の単位と、サービスの単位がずれていたので、1つの変更が4つのサービスに分かれました。

分ける前:  1つの変更 → 1つのコード → 1回のデプロイ
分けた後:  1つの変更 → 4つのサービス → 4回のデプロイを順番に

分けたことで、待ち合わせは無くならず、形を変えただけでした。同じコードの中での待ち合わせが、サービス間のデプロイの順番待ちになり、さらにネットワークの失敗が加わりました。

組織の形が、境界の形になる

ソフトウェアの構造は、それを作る組織のコミュニケーションの構造に似ると言われます（コンウェイの法則）。

マイクロサービスが本当に速さを生むのは、サービスごとに別のチームがいて、チームどうしの調整を減らしたいときです。チームが独立して決め、独立してデプロイできることが価値になります。

6人の1チームでは、調整のコストはもともと小さく、サービスを分けても減りません。減らすべき調整が無いところに境界を作ると、境界を越える手間だけが増えます。

データを共有すると、分けたことにならない

サービスを分けても、同じ DB の同じテーブルを複数のサービスが読み書きしていると、テーブルの形を変えるたびに全サービスを同時に直す必要があります。見た目は分かれていても、テーブルの形という契約で、全サービスが結合したままです。

独立して変えるには、各サービスが自分のデータを持ち、他のサービスには API やイベントを通してだけ見せる必要があります。これは、データの重複と、サービスをまたぐ整合性という新しい問題を引き受けることでもあります。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。