【図解で比較】モノリス vs マイクロサービス — アーキテクチャの違いを徹底解説

モノリスは、アプリケーション全体がひとつの大きなかたまりになっている構造のことだよ。UI、ビジネスロジック、データベースアクセスが全部ひとつのプロジェクトに入っていて、まとめてビルド・デプロイするんだ。一方マイクロサービスは、機能ごとに小さなサービスに分割して、それぞれが独立して動く設計だよ。

モノリスはたしかにシンプルで開発を始めやすいんだけど、アプリが大きくなると問題が出てくるんだ。たとえばデプロイのとき、ちょっとした修正でもアプリ全体をまるごとデプロイし直す必要がある。マイクロサービスなら、変更したサービスだけをデプロイできるから、リスクが小さくて済むんだよ。

モノリスだと、たとえば「検索機能だけアクセスが集中してる」としても、アプリ全体をスケールアウトするしかないんだ。サーバーを増やすとき全機能がセットでコピーされるから、リソースがもったいないよね。マイクロサービスなら、検索サービスだけを5台に増やして、他はそのままにできる。必要なところに必要なだけリソースを割り当てられるんだよ。

そうなんだ。「コンウェイの法則」って聞いたことあるかな？ソフトウェアの構造は、それを作る組織のコミュニケーション構造に似てくるという法則だよ。マイクロサービスでは、各サービスを担当する小さなチーム（2ピザチーム）が独立して開発・デプロイできる。大きな組織で多くのチームが並行して開発するときに特に有効なんだ。

主に2つの方法があるよ。ひとつはREST APIやgRPCを使った同期通信。もうひとつはメッセージキュー（KafkaやRabbitMQなど）を使った非同期通信だね。同期通信はシンプルだけどサービス間の依存が強くなる。非同期通信は疎結合になるけど、設計が複雑になるというトレードオフがあるんだ。

まさにそこが大事なポイントだよ。マイクロサービスは「分散システムの複雑さ」を引き受けることになるんだ。ネットワーク障害、データの整合性、サービス間のデバッグ、運用コスト…。スタートアップや小規模チームなら、モノリスから始めて、本当に必要になったタイミングで分割するのが定石だよ。

いい質問だね。どちらも最初はモノリスだったんだ。Netflixは2008年頃にデータベース障害でサービスが3日間止まったことをきっかけに、マイクロサービスへの移行を始めた。Amazonも巨大なモノリスの限界にぶつかって、サービス分割に踏み切ったんだよ。つまり、成長の過程で必要に迫られて移行したケースがほとんどなんだ。

そこで登場するのが「分散トレーシング」だよ。JaegerやZipkinといったツールを使って、リクエストが複数のサービスをまたいで処理される様子を一本の線として可視化するんだ。また、複数サービスにまたがるトランザクション管理には「Sagaパターン」という設計手法が使われる。各サービスがローカルトランザクションを実行して、失敗したら補償トランザクションで巻き戻す仕組みだよ。

あるよ。「モジュラーモノリス」という考え方だね。ひとつのアプリケーション内でモジュールを明確に分離して、将来マイクロサービスに分割しやすい構造にしておくんだ。Shopifyがこのアプローチで成功している例として有名だよ。最近は「You don't need microservices（マイクロサービスは不要）」という議論も活発で、分散システムの複雑さに見合うメリットがあるか慎重に見極めることが大切だね。

その通りだよ。「モノリスファースト」という言葉もあるくらいでね。最初からきれいにモジュール分割しておけば、後からマイクロサービスに移行するハードルもぐっと下がる。技術選定は銀の弾丸じゃなくて、チームの規模・プロダクトのフェーズ・運用体制に合わせて判断するのが一番大事だよ。