マイクロサービスとモノリス — 天才シェフ1人か、完全分業の厨房か

アプリを1つの大きなかたまりとして作るか、小さなサービスの集まりとして作るか。前者をモノリス、後者をマイクロサービスと呼びます。どちらが正解という話ではなく、何と何を交換しているかを知るのが大事です。

たとえるなら厨房です。モノリスは何でも作れる天才シェフが1人で全部こなす厨房。マイクロサービスは前菜・メイン・デザートが完全に分業され、伝票で注文を受け渡す厨房です。図1で厨房を切り替え、4つの出来事を起こしてみてください。

マイクロサービスが買っているのは「一部だけ」の自由

表を両方埋めると、マイクロサービスが強いのは「一部だけ」の出来事だと分かります。デザートのレシピを変えてもデザート係だけ入れ替えればよい。メインが混んだらメイン係だけ増やせばよい。デザート係が倒れても、ほかの料理は出し続けられる。

モノリスでは、どれも厨房全体の話になります。小さな変更でも全体を作り直して入れ替え、混雑したらシェフを使わない腕前ごと丸ごと複製し、どこか1か所の不具合で全体が止まることがあります。

その代わりに払うのは「受け渡し」と「管理」

一方で、1皿を仕上げるだけならモノリスが圧倒的に速くて確実です。モノリスの中の受け渡しは同じプロセス内の関数呼び出しなので、ほぼ一瞬で、途中で失われることもありません。マイクロサービスでは受け渡しのたびにネットワーク越しの呼び出しになり、遅くなるうえにどこかで失敗する可能性が生まれます。タイムアウトやサーキットブレーカーが必要になるのはこのためです。

管理するものも増えます。サービスごとのデプロイ、監視、ログ、そしてデータベースが分かれることで、複数のサービスにまたがる整合性をどう保つかという新しい悩み。これらはチームが大きく、担当を分けたいときに初めて元が取れるコストです。

そのため「まずはモノリスで作り、分ける理由がはっきりしてから切り出す」のが定石とされます。最初から細かく分けすぎると、分業の手間だけを払うことになりがちです。

まとめ

モノリスとマイクロサービスの違いは分け方です。分けると、一部だけ変える・増やす・壊れることができるようになります。その代わり、受け渡しは遅く不確実になり、管理するものが増えます。天才シェフ1人で回る規模なら1人のほうが速く、厨房が大きくなって初めて分業が効いてくる、と覚えておいてください。