開発チームにはより高い柔軟性、スケーラビリティ、スピードが求められるため、従来のモノリシックなソフトウェア開発モデルはほとんど時代遅れになっています。最新の動向のニーズを満たすために、大規模で複雑なアプリケーションを効果的かつ効率的に構築して実行するための選択肢としてサービス指向アーキテクチャ (SOA) とマイクロサービスの2つが登場しました。
ビジネスに最適なモデルはどちらでしょうか。この2つのアプローチは一見非常によく似ているように見えますが、開発チームがどちらのモデルが自社のビジネスに最適かを判断するのに役立ついくつかの顕著な違いがあります。この投稿では、SOAとマイクロサービスの両方について、主な相違点、およびそれぞれの高レベルのユースケースについて説明します。
SOAとマイクロサービスの比較：概要
SOAとマイクロサービスの違いについて説明する前に、その類似点を少し見てみましょう。SOAとマイクロサービスの共通点：
- 大規模で複雑なアプリケーションを、より小さく、より柔軟性の高いコンポーネントに分割する
- スケーラビリティを高めて、組織がアプリをより迅速に開発および展開できるように支援する
- クラウドまたはハイブリッドクラウド環境に基づくアジャイル開発モデル
では相違点は何でしょうか。実際、SOAとマイクロサービスの間には、スコープ、アーキテクチャ、ガバナンス、コミュニケーションに関していくつかの重要な違いがあります。ここでは、各モデルとその比較について詳しく説明します。
SOAとは
サービス指向アーキテクチャ (SOA) は、必要なアプリケーションコンポーネントを個別のサービスモジュールに分割するクラウドベースのソフトウェア開発モデルです。これらのモジュールは、モノリシックアプリケーションよりも小さく柔軟性が高いため、扱いが容易です。
SOAサービス
SOAは次の4つの主なサービスを提供します。
- 機能サービス（またはビジネスサービス）：ビジネスアプリケーションまたは業務に関連します。
- エンタープライズサービス：機能を実装するために使用します。
- アプリケーションサービス：特にアプリの開発と展開を指します。
- インフラストラクチャサービス：セキュリティ、アクセス、認証などのバックエンドの非機能プロセスに関連します。
SOAコンポーネント
各SOAサービスは次の3つのコンポーネントで構成されています。
- インターフェース：サービスプロバイダーが顧客の要求をどのように管理するかを示します。
- コントラクト：プロバイダーとサービスコンシューマーの間のやり取りの条件を定義します。
- 実装またはサービスコード。
SOAサービスを組み合わせて、より複雑なサービスやアプリケーションを開発することもできます。一般的にSOAは、エンタープライズサービスバス (ESB) と呼ばれる堅牢な通信および制御レイヤーを介してこれらのモジュールを接続します。
SOAの分離
SOA構造は「疎結合」の概念に基づいています。つまり、モノリシックアーキテクチャの場合とは異なり、コンポーネントに複雑なポイントツーポイントの統合は必要ありません。これにより、さまざまなコンポーネントが種類の異なるプラットフォームやプログラミング言語に基づいている場合でも、それらがESBを介して通信できます。そのため、開発チームはモジュールを再利用して企業全体でさまざまな目的を達成することができるので、各Webアプリケーションの個々のコンポーネントの再構築に開発者が費やす時間を減らすことができます。
そうは言っても、SOAの欠点の1つは、コンポーネントに欠陥やバグが含まれている場合に、実装されるすべてのインスタンスにその問題が影響を与えることです。結果として、コード内または各モジュールの別のコンポーネントの問題が、大規模に展開された場合に企業全体に広範な影響を与える可能性があります。
マイクロサービスとは
マイクロサービスアーキテクチャはSOAの副産物と考えられます。これも大規模なアプリケーションを、より小さく、より柔軟性の高いコンポーネントに分割しますが、さらに細かく分割します。また、高度に専門化された特定のビジネス機能を中心に各ユニットを編成します。
境界付けられたコンテキスト
マイクロサービスは、境界付けられたコンテキストと呼ばれる原則に従って動作します。これは、コンポーネントとそのデータをスタンドアロンのユニットとして、または制限された依存関係を持つユニットとして配置する機能です。言い換えれば、サービスは分離され、独立して機能します。そのため、アプリケーション内の1つのWebサービスに障害が発生しても、そのアプリケーションに関連付けられている他のサービスは通常どおり動作し続けます。
API
マイクロサービスモデルでは、サービスはアプリケーションプログラミングインターフェース (API) を利用して、他のサービス、コンポーネント、およびアプリケーションと通信します。APIを介して接続すると、独立したサービスを統合して複雑なアプリケーションを作成できます。
コンテナオーケストレーション
マイクロサービスアーキテクチャではサービスが独立しており、モデル自体は通常コンテナを利用して動作するため、マイクロサービスアプローチは一般に、SOAを含む他のソフトウェア開発モデルと比較して、スケーラビリティ、可搬性、耐障害性に優れています。
マイクロサービスとSOAの比較：相違点の識別
SOAとマイクロサービスの主な違いは、アーキテクチャのスコープに関係しています。SOAモデルでは、サービスやモジュールが企業全体で共有されて再利用されるのに対し、マイクロサービスアーキテクチャは、独立して機能する個々のサービスに基づいて構築されます。言い換えると、SOAにはエンタープライズスコープがあり、これに対しマイクロサービスにはアプリケーションスコープがあります。
この違いにより、2つのモデルの間にいくつかの決定的な違いが生じます。
再利用性とデータの重複
SOAモデルでは、開発者はスケーラビリティと効率を高める手段としてコンポーネントを再利用します。ただし、マイクロサービスモデルでこのアプローチに従う場合、コンポーネントを再利用すると異なるサービス間で依存関係が構築されるため、一般的に俊敏性と耐障害性が低下します。代わりに、マイクロサービスアーキテクチャでは、開発者はコードを再利用したり、データを複製したりして、効率を高め、高いレベルの独立性を維持します。
同期呼び出しと非同期通信
SOAでは、サービスは同期プロトコルを介して企業全体で利用できるようになります。最も一般的には、これはRESTful APIの形式で提供されます。ただし、マイクロサービスアーキテクチャでは、同期呼び出しによってリアルタイムの依存関係が構築され、そのために信頼性とレジリエンスが低下します。これらの問題を回避し、高レベルのパフォーマンスを維持するために、開発者はイベントソーシングやパブリッシュ/サブスクライブモデルなどの手法を使用して非同期通信を可能にします。
ソースデータとローカルデータ
SOAでは、すべてのアプリケーションがソースレベルで同時にデータを受信および更新できる必要があります。そのため、SOAサービスには複雑なデータ同期モデルを含める必要はありません。ただし、このアプローチではサービス間の依存関係も構築されるため、マイクロサービスアーキテクチャには理想的ではありません。すべてのサービスとアプリケーション間の独立性を維持するために、マイクロサービスモデルは、各サービスに必要なすべてのデータへのローカルアクセスを提供します。これにより、データの重複が発生し、ひいては複雑なインスタンスが作成されますが、パフォーマンスに影響を与える可能性のある依存関係は回避されます。
ESBとAPIの比較
SOAでは、サービスは、エンタープライズサービスバス (ESB) と呼ばれる共通通信チャネルを介して編成および調整されます。すべての通信がESB内で一元管理されるため、すべてのサービスに対する単一障害点のリスクが生じます。この問題を回避し、独立した操作を維持するために、マイクロサービスはAPIを介して通信します。
これらの点と、いくつかの追加の相違点を以下の表にまとめます。
| SOA | マイクロサービス | |
|---|---|---|
| アーキテクチャ | サービスはエンタープライズレベルで再利用および共有される | サービスは分離され、独立して機能する |
| 粒度 | 比較的大きい、モジュラーサービス | ビジネスに特定の目的や機能を提供する小規模でより柔軟なサービス |
| 通信 | ESB | API |
| 結合 | リソースの共有/疎結合 | 境界付けられたコンテキスト |
| 相互運用性 | Simple Object Access Protocol (SOAP)、Advanced Messaging Queuing Protocol (AMQP)、Microsoft Messaging Queuing (MMQ) などの複数のメッセージプロトコルをサポート | HTTP、Representational State Transfers (REST)、Java Messaging Service (JMS) などの軽量で言語に依存しないメッセージングプロトコルを使用 |
| データガバナンス | コンポーネント共有の結果としての企業全体にわたる共通のデータガバナンス | サービスの独立性によりチーム間の一貫したデータガバナンスがない |
| ストレージ | 特定のアプリケーション内のすべてのサービスで共有される単一のデータストレージレイヤー | 必要に応じて各サービスのデータストレージ用の独立したデータサーバーまたはデータベースを使用 |
マイクロサービスとSOAの比較：どちらがビジネスに適しているか
SOAとマイクロサービスには、それぞれ明確な利点と欠点があります。ビジネスに適しているアーキテクチャの選択は、多くの場合、ユースケースや、利用可能なリソース、ITの成熟度、ビジネスニーズによって決まります。
SOAが適している状況
より大規模で多様なアプリケーション環境は、ESBによる堅牢な統合を可能にするSOAからメリットを得られる傾向があります。これにより、開発者は、各アプリケーションの独立性を維持しながら、異種アプリケーションやさまざまなメッセージングプロトコルを接続することができます。
そうは言っても、SOAの展開はマイクロサービスよりも時間がかかり、複雑になる傾向があります。これは、複数のサービスが結合されているため、新しいサービスや機能を追加すると、アプリケーション全体に対してある程度の再展開が必要になるためです。
SOAに適した具体的なユースケースには、次のようなものがあります。
- 複数の独立したアプリ間の通信の実現
- 企業全体で複数回再利用するという明確な目的を持つサービスの構築
- 複数のデータソースを使用するアプリのサポート
- 外部クライアントへのデータまたは機能の公開
- サーバーレス機能の構築
マイクロサービスが適している状況
マイクロサービスアーキテクチャは、SOAと比較して、より簡単かつ迅速に構築できる傾向があります。これは、サービス自体が小さいため、簡単に短時間で展開できるためです。
あまり複雑ではない小規模な環境を運用し、堅牢な通信プラットフォームを必要としない組織では、一般に、マイクロサービスアプローチの方が、速度、柔軟性、レジリエンスに優れ、多くの場合、コストと複雑さが軽減されます。
マイクロサービスは、次のシナリオに最適です。
- 簡単に分割できる比較的単純なプロジェクト
- すでに分割されているか、明確な分割方法がある複雑なアプリ
- アジャイル開発と継続的デリバリープロセスを採用したい組織
- クラウドコンピューティングリソース（特にコンテナの使用）の最適化を希望しているか最適化する必要がある企業
- 同じ環境で複数のフレームワーク、言語、テクノロジーを使用するアプリケーション
クラウドストライクのクラウドセキュリティソリューションの詳細を参照し、デモをスケジュールして、どのソリューションがお客様の組織のニーズにより適しているかを確認してください。
