ブログ

2024年11月06日

モノリシックとマイクロサービスの違い

英語によるオリジナルはこちらでご覧いただけます。

マイクロサービスアーキテクチャは、アプリケーションを小規模なコンポーネントやサービスに細分化することで課題に対処します。

アプリケーションアーキテクチャの進化

その名が生まれてから10年足らずのうちに主流となったマイクロサービスアーキテクチャですが、従来のモノリシック型の設計と何が違うのでしょうか。モノリシックとマイクロサービスのそれぞれのメリットとデメリットは、アプリケーションの規模、特にコードベースの規模が次第に拡大していったときの様子を見るとわかってきます。

モノリシックとマイクロサービスの長所と短所

モノリシックアーキテクチャとは

モノリシックアーキテクチャには稼働部位がほとんどありません。すなわち、ほとんどの機能は同じコードベースのもとで提供され、ステートフルなオブジェクトが単一のデータベースに保存されています。この手法は、小規模なチームが開発するシンプルなアプリケーションの場合にはうまく機能します。アプリケーションの各部分の仕組みをメンバー全員が理解しており、依存関係もほとんどないことから、チームはテストとデプロイを迅速に進められます。新しいプロダクトを市場に素早く投入することを目指しているスタートアップ企業の場合には、モノリシック型の手法を採用することでオーバーヘッドが抑制され、開発サイクルも短くなって、迅速な動きが可能になります。

しかし、そのアプリケーションが次第に複雑化してコードベースが拡大していくと、開発が鈍化し、リリースの間隔も長期化します。なぜなら、新たな機能や処理が加わることでコードベースが大きくなり、コードを常にクリーンに抽象化しておくことや正確なドキュメントの維持が難しくなるからです。変更を加えるときに、実験的な部分を隔離してアプリケーション全体に影響が及ばないようにすることが難しいため、イノベーションが阻害されます。また、システムが大きくなると、開発チームも増員が必要になります。しかし、新メンバーは最初の段階で習得すべきことが非常に多くあります。そのなかでシステム全体を何とか理解し、自分が加える変更が及ぼす影響を予期できるようにならなくてはなりません。こうした要因から開発やリリースサイクルの鈍化が生じ、結果として幹部とエンジニアの双方がフラストレーションを抱え、士気の喪失を招くことになります。チームの創造性と献身性が成功と失敗の分かれ目になる状況において、士気の低下は何より好ましくありません 。

マイクロサービスとは何か、そしてそれがどのように役立つのか

マイクロサービスアーキテクチャは、アプリケーションを小規模なコンポーネントやサービスに細分化することで、こうした課題に対処します。コンポーネントはそれぞれが単一のビジネス機能を提供します（マイクロサービスと呼ばれるのはそのためです）。他のサービスとの通信には、APIとメッセージングプロトコルを使用します。開発チームはそれぞれが1つのサービスを担当します。サービス同士はAPI経由で通信することから、開発者が他のサービスの細部を理解する必要はなく、サービスの公開インターフェースさえ理解すれば済みます。変更の開発やデプロイは各チームが独立して進めることができます。新メンバーが覚えるべきことは大幅に減り、戦力になるまでの期間がかなり短くなります。

モノリシックの手法の長所と短所

アプリケーションのすべてのロジックを1つのプロセスのなかで扱うモノリシックの手法には、いくつかのメリットがあります。これは特に、小規模なチームが開発するシンプルなアプリケーションに関して言えます。

長所

  1. 長年にわたって浸透した慣例により、大半のIDE（統合開発環境）はアプリケーション全体の実行とテストをクリック1つで行えるようになっており、モノリシックアーキテクチャに対応しています。
  2. セキュリティ、流量制限、監視などの共通事項を、アプリケーション全体で一元的に処理できます。
  3. 稼働部位がほとんどないことから、エンドツーエンドのテストが比較的容易です。
  4. コードベースの規模が小さい場合、モノリスの方が扱いやデプロイがシンプルで、ロードバランサのもとでアプリケーションを水平スケールできます。

しかし、アプリケーションが次第に複雑化し、コードベースの規模が大きくなってくると、こうしたメリットのいくつかはデメリットに変わります。既に述べたとおり、大規模なモノリシックシステムでは、適切なコーディング手法を維持することやチームを拡大することが困難です。加えて、次のようなデメリットがあります。

短所

  1. モノリスをスケールするにはアプリケーション全体を複製するしかありませんが、これは必ずしも効率的ではありません。
  2. 最初に選んだ言語やフレームワークでの開発に縛られることになります。
  3. 軽微な変更やバグ修正であっても、テストとリリースにはアプリケーション全体のビルドとデプロイが必要になります。コードベースが大きくなると、所要時間はますます長くなります。
  4. アプリケーションのいずれか1つの部分で問題が発生したときに、システム全体がダウンする可能性があります。

マイクロサービスの手法の長所と短所

マイクロサービスアーキテクチャでは、複雑なアプリケーションを個別のコンポーネントに分割し、各コンポーネントは1つのビジネス機能のみを提供します。これにより、モノリシック型の設計にはない次のようなメリットが得られます。

長所

  1. マイクロサービスは疎結合となっており、API経由で通信します。APIは基盤のロジックとの間の抽象化レイヤーとして機能します。したがって、複数のチームが並行して作業を進められます。変更を加える部分の開発やテストを、システムの残りの部分からは独立して進め、反復型のスピーディーな開発サイクルを確立できます。
  2. サービスがそれぞれ独立していることから、各チームは自分たちのニーズを満たす最適な言語とフレームワークを選択できます。あわせて、システムの残りの部分に影響を及ぼすことなく、変革や実験の余地が得られます。
  3. 各チームは明確に定義された特定のマイクロサービスを担当することから、新メンバーが覚えるべきことが少なくなり、戦力になるまでの期間が非常に短くなります。
  4. 各マイクロサービスは独立してデプロイできるため、サービスの負荷に応じて個別にスケーリングが可能です。個々のサービスのインスタンスを追加で起動する方が、システム全体を複製するより効率的で、弾力性のあるクラウドベースのインフラのメリットを活用できます。
  5. マイクロサービスの特定のインスタンスで侵害や障害が発生した場合に、システムの残りの部分に影響を及ぼすことなく、該当するインスタンスを分離して切断できます。個々のマイクロサービスの水平スケールが可能であることに加えて、より堅牢でレジリエンスの高いシステムが得られます。

マイクロサービスアーキテクチャには多くのメリットがある一方で、分散システムに付随する次のような複雑さもあります。

短所

  1. マイクロサービスアーキテクチャはモノリシック型の設計に比べて稼働部位が増えることから、最初の時点での複雑さが高まります。小規模なチームが手がけるシンプルなアプリケーションの場合、マイクロサービスの手法は煩雑すぎることがあります。
  2. クライアントアプリケーションに個々のマイクロサービスを公開する場合、クライアントとシステムの連携が複雑になることがあります。クライアントの開発者が、システムを構成する数十個や数百個のサービスにリクエストをルーティングする方法を理解する必要があるためです。これに対処するには、バックエンドサービスとクライアントアプリケーションの間に、リクエストのルーティングやレスポンスの集約を担う抽象化レイヤーとしてAPIゲートウェイを配置するという方法があります。
  3. セキュリティ、認証、監視など、全体の共通事項を個々のマイクロサービスに適用する必要があります。また、システムで使用する各言語で同じ機能を再現する必要があります。ただし、こうした機能をAPIゲートウェイで一元的に処理するようにすれば、この問題を回避して、一貫した手法を適用できます。
  4. マイクロサービスを基盤とするシステムをテストするためには、依存関係を管理し、各サービスを独立してデプロイ可能にするために、複数のレイヤーにわたるテストの自動化が事実上不可欠となります。そう聞くと大きな負担のように思えるかもしれませんが、モノリシックかマイクロサービスかを問わず、あらゆるシステムの継続的デリバリを可能にするために、テストの自動化への投資には価値があります。

マイクロサービスアーキテクチャには数多くのメリットがあります。特に、高水準のスケーラビリティとレジリエンスが求められる大規模で複雑なシステムにおいて、その恩恵は顕著に現れます。マイクロサービスベースのシステムへの移行について詳しくは、eBook「Blowing Up the Monolith: Adopting a Microservices Based Architecture（モノリスからの脱却：マイクロサービスアーキテクチャの採用）」をお読みください。

製品のお問い合わせやデモのご依頼はこちらから