サービス指向アーキテクチャとマイクロサービスアーキテクチャ：SOAとMSAの比較

コンピューティングにおいて、サービスとは、繰り返し行われる冗長なタスクを実行するソフトウェアの単一または集合的ユニットを指します。クラウドコンピューティングの時代において、アプリケーションは、アプリケーション全体の機能をサポートするためにさまざまな機能を実行するサービスのコレクションで構成されています。この記事では、マイクロサービスアーキテクチャ（MSA）とサービス指向アーキテクチャ（SOA）を、サービスを主要なコンポーネントとして依存する2つの一般的なサービスベースのアーキテクチャとして探り、それらの違いを見ていきます。

サービス指向アーキテクチャ（SOA）とは何ですか？

サービス指向アーキテクチャは、複数の自己完結型、離散的、再利用可能なサービスを使用して、アプリケーションの機能を全体的に形成するサービスメッシュを形成する設計に従います。これにより、アプリケーションコンポーネントのフレームワークが相互に作用し、サービスインターフェース（通信プロトコル）を活用して他のコンポーネントとサービスを提供します。

SOAの設計原則

サービス指向アーキテクチャの原則は、使用ケースに応じて異なる場合があります。ここにSOAを形成するためにサービスを分離する一般的な原則があります：

• 抽象化
• 再利用性
• 粒度
• 標準化された契約
• 自律性
• ステートレス
• 発見

SOAの特徴

SOAの基本的な使用ケースの1つは、複数の異なるサービスを集まってアプリケーションを構築できるようにすることです。各サービスは、独自のビジネスロジックまたはアプリケーションロジックを持っています。それ以外にも、SOAの一般的な特徴には以下があります：

• 「できるだけ多くを共有する」アーキテクチャ
• ビジネス機能の再利用の重要性
• 共通のガバナンスと基準
• 通信のためのエンタープライズサービスバス（ESB）
• 複数のメッセージプロトコル
• すべてのサービスがデプロイされる共通プラットフォーム
• I/Oを処理するためのより多くのオーバーヘッドを持つマルチスレッド
• 最大のアプリケーションサービス再利用性
• 従来のリレーショナルデータベースを使用する可能性が高い
• DevOpsモデルでは好まれない

マイクロサービスアーキテクチャ（MSA）とは何ですか？

マイクロサービスアーキテクチャは、単一のアプリケーションを複数の緩く結合された独立したサービスに分割するSOAパターンに従いながら、互いに連携して機能します。しばしばコンテナ化の理想的な使用ケースと見なされるマイクロサービスは、各マイクロサービスを別々のコンテナでデプロイすることが組織にとって一般的です。これにより、柔軟でポータブルでプラットフォームに依存しない複数のサービスの効率的なフレームワークが実現され、各サービスは異なるオペレーティングシステムとデータベースを持ちながら、自身のプロセスで実行できます。

MSAの特徴

• 「できるだけ少なく共有する」アーキテクチャ
• バウンデッドコンテキストの概念の重要性
• 人にもっと焦点を当てた緩やかなガバナンス
• プラットフォームや技術を選択する自由と効率的なコラボレーション
• シンプルであまり複雑でないメッセージングシステム
• HTTP/RESTやAMQPなどの軽量プロトコル
• 通常はシングルスレッドで、ノンロッキングI/O処理のためのイベントループ機能を使用
• コンテナはMSAで非常によく機能し、DevOpsモデルに最適と見なされる
• デカップリングにもっと焦点を当てる
• 現代の非リレーショナルデータベースを使用

マイクロサービスとSOA：重要な違い

SOAとMSAの主な違いを見てみましょう。

調整

SOAは、ビジネスリクエストを作成するために複数のグループとの調整を必要とします。それに対して、MSAのサービス間ではほとんど調整が行われないか、まったく行われません。サービスオーナー間で調整が必要な場合は、小規模なアプリケーション開発チームを通じて行われ、サービスは迅速に開発、テスト、デプロイできます。

サービスの粒度

マイクロサービスの「マイクロ」という接頭辞は、その内部コンポーネントの粒度を指します。MSA内のサービスコンポーネントは、一般的に1つの目的に特化したサービスで、非常に優れたパフォーマンスを発揮します。SOAのサービスは通常、はるかに多くのビジネス機能を含み、完全なサブシステムとして実装されることがよくあります。

コンポーネントの共有

SOAはコンポーネントの共有を強化しますが、MSAは「バウンデッドコンテキスト」を通じて共有を最小限に抑えようとします。バウンデッドコンテキストは、コンポーネントとそのデータを最小限の依存関係で単一ユニットとして結合することを指します。SOAはビジネスリクエストを満たすために複数のサービスに依存するため、SOAに基づいたシステムはMSAよりも遅くなる可能性があります。

ミドルウェアとAPI層

SOAのメッセージングミドルウェアは、MSAにはない追加の機能を多数提供します。これには、以下が含まれます：

• 調停とルーティング
• メッセージの強化
• メッセージおよびプロトコルの変換

MSAには、サービスとサービス消費者の間にAPI層があります。

リモートサービス

SOAアーキテクチャは、主にリモートアクセスプロトコルとしてメッセージング（AMQP、MSMQ）およびSOAPに依存します。ほとんどのMSAは、RESTとシンプルなメッセージング（JMS、MSMQ）の2つのプロトコルに依存し、MSAで見つかるプロトコルは通常均一です。非均一な相互運用性は、SOAがそのメッセージングミドルウェアコンポーネントを通じて複数の異なるプロトコルの伝播を促進します。MSAは、統合の選択肢を減らすことによってアーキテクチャパターンを単純化しようとします。

• 異なるプロトコルを使用して異なるシステムを統合したい場合は、SOAを検討する必要があります。
• すべてのサービスが同じリモートアクセスプロトコルを介して公開され、アクセスできる場合、MSAがより良い選択肢です。

契約のデカップリング

契約のデカップリングは、抽象化の聖杯です。それはサービスと消費者間の最大のデカップリングを提供します。これはSOAの根本的な能力の1つですが、MSAは契約のデカップリングをサポートしません。

どのアーキテクチャを選ぶべきか？

これらのパターンのいずれかを選択する際のいくつかの重要な考慮事項は次のとおりです：

• SOAは、多くの異種アプリケーションとの統合を必要とする大規模で複雑なビジネスアプリケーション環境に適しています。ただし、ワークフローに基づくアプリケーションで、明確に定義された処理フローがある場合、SOAパターンを使用して実装するのは少し難しいです。小さなアプリケーションもSOAには適していません。なぜなら、メッセージングミドルウェアコンポーネントを必要としないからです。
• MSAパターンは、小さくてうまく分割されたWebベースのシステムに適しています。メッセージングミドルウェアがないことは、MSAが複雑な環境に不適である主な要因の1つです。
• 制御対オーケストレーション。アプリケーションをゼロから開発する際、MSAを使用することが開発者としての選択肢として考えられています。一方、ビジネスプロセスをオーケストレーションすることが目標であれば、SOAは理想的と考えられます。
• 初期段階対より成熟した組織。初期段階にある企業は、MSAを理想的な選択肢と見なすかもしれません。ビジネスが成長するにつれて、組織は複雑なリクエスト変換や異種システム統合などの機能を必要とする場合があります。そのような状況では、組織はしばしばMSAを置き換えるためにSOAパターンに移行します。

SOAとMSAは、企業の異なる層でサービスの同一パターンに従います。MSAの存在はSOAパターンの成功に帰着し、したがってしばしばSOAのサブセットとして言及されます。マイクロサービスとサービス指向アーキテクチャは、アプリケーションを複数のサービスに分割するという点で完全に機能しますが、MSAはアプリケーションレベルでサービスを非集約化し、SOAは企業レベルでサービスの再利用性を行います。

関連情報

• BMC DevOpsブログ
• マイクロサービスとナノサービス：フレームワークオプションの比較
• マイクロサービスとサーバーレス：違いは何ですか？
• マイクロサービスの課題と回避すべき場合
• KubernetesとDocker Swarm：コンテナオーケストレーションツールの比較
• 今日のコンテナの状態：報告書の概要

元の参照画像：

これらの投稿は私自身の意見であり、必ずしもBMCの立場、戦略、または意見を表すものではありません。