マイクロサービスとSOA：の違い 適したユースケースとは

アプリケーションを開発して展開する最善の方法を理解することは、今日のあらゆるデータ駆動型企業が考慮すべき重要な事柄です。 サービス指向アーキテクチャー(SOA)やマイクロサービスのようなオプションは、アプリケーションのビルドと実行に柔軟性をもたらすという、従来のモノリシックなアプローチにはない価値を実現します。 しかし、両者の差異を理解して、どちらがビジネスに最適なのかを判断しようとすると、難しいかもしれません。

マイクロサービス(アーキテクチャー)は、単一用途の独立した一連のサービスでアプリケーションを構成します。一方SOAは、互いに「対話」することでアプリケーションとその展開をサポートする、モジュール型サービスのグループです。 この2つのアプローチの間には、アーキテクチャーやコンポーネントの共有、データガバナンス、通信などの要素に関する重大な違いが存在しており、それぞれの手法がどんな状況に最適で、ビジネス全体にどんな影響を与えるのかを決定づけています。

サービス指向アーキテクチャー(SOA)とは何か？

サービス指向アーキテクチャー(Service Oriented Architecture)とはは、主として従来のモノリシックなアプローチによるアプリケーションのビルドに対応するものとして作成されました。 SOAでは、アプリケーションに必要なコンポーネントを、互いに通信することで特定のビジネス目標を達成する個別のサービスモジュールに分解します。 各モジュールはモノリシックなアプリケーションよりもかなり小さく、企業のさまざまな目的に応じて展開できます。 さらに、SOAはクラウドを介して提供され、インフラストラクチャーやプラットフォーム、アプリケーション用のサービスを含めることができます。

SOAの2つの主な役割は、サービスプロバイダーとサービスコンシューマーです。 サービスプロバイダーの層には、SOAに関連する各種サービスが含まれ、サービスコンシューマーの層はユーザーインターフェイスとして動作します。

SOAは4種類の異なるサービスを提供します。

1. 機能サービスは業務に使用されます
2. エンタープライズサービスは機能を実装します
3. アプリケーションサービスは、アプリケーションの開発と展開のための専用サービスです
4. インフラストラクチャーサービスは、セキュリティや認証などの非機能プロセスのためのサービスです

従来SOAでは、こうしたサービスを連携させて制御するための手段としてエンタープライズサービスバス（ESB）が使用されてきました。

マイクロサービス(アーキテクチャー)とは何か？

マイクロサービスアーキテクチャーは、サービスがさらに細かく分割されていて、互いに独立して機能することから、一般的にSOAの進化形と考えられています。 したがって、アプリケーション内のいずれかのサービスに障害が発生したとしても、各サービスは独立した目的を持つため、アプリケーションは引き続き機能します。 マイクロサービスアーキテクチャーを採用したサービスはアプリケーションプログラミングインターフェイス（API）を介して通信し、特定のビジネス領域を中心として組織化されています。 これらのサービスが1つに組み合わされ、複雑なアプリケーションを構成しています。

マイクロサービスアーキテクチャーでは各サービスが独立しているため、アプリケーションのビルドと展開に利用される他のアプローチよりもスケーラビリティに優れています。 この特性により、マイクロサービスアプリケーションでは、他の手法で開発されたアプリケーションよりも高い耐障害性を得ることもできます。 マイクロサービスはよくクラウドでビルドおよび展開され、多くのインスタンスではコンテナで動作します。

マイクロサービスとSOAの比較：違いの明確化

SOAとマイクロサービスの主な特徴の多くは似ています。 両方ともアプリケーションの開発と実行にクラウド環境やハイブリッドクラウド環境を必要とし、アプリケーションの作成と使用に必要な複数のサービスを組み合わせるように設計されており、どちらも大規模で複雑なアプリケーションを効果的に細分化して、より柔軟に配置して展開できるようにします。 マイクロサービスとSOAはどちらもクラウド環境で動作するため、両方とも最新のビッグデータの量とスピードの要求を満たすようにスケーリングできます。

それでもなお、SOAとマイクロサービスの間には多くの違いがあり、それぞれに適したユースケースが定まります。

アーキテクチャーの違い

マイクロサービスアーキテクチャーは、単一の目的に焦点を当てた、比較的小規模な細分化されたサービスに基づいています。サービスは互いに独立して動作できますが、互いに通信を行って同じアプリケーションをサポートします。 そのため、マイクロサービスはサービスリソースの共有が最小限となるように設計されています。 SOAは比較的大規模な、互いに独立していないモジュール型のサービスであるため、リソースを最大限に共有するように設計されています。

コンポーネントの共有

マイクロサービスは独立しているため、コンポーネントは最小限の共有しか必要とせず、サービスの耐障害性が向上します。 さらに、コンポーネントの共有が比較的少ないことで、開発者は新しいバージョンを簡単に展開でき、マイクロサービスはSOAを使用するよりもはるかに速く個々のサービスをスケーリングできます。

一方、SOAではコンポーネントの共有はかなり一般的です。 具体的には、サービスはESBへのアクセスを共有します。 そのため、あるESBに関連するサービスで問題が発生すると、同じESBに接続された他のサービスの有効性が損なわれる可能性があります。

サービスの粒度

SOAのサービスは大規模で、一部のモジュール型サービスはモノリシックなアプリケーションに似ています。 各サービスのスケーリング能力が高いため、SOAは通常、幅広い対象に対応できます。

マイクロサービスはより細分化されているため、個々のサービスは特定の単一タスクの実行を得意とします。 こうしたタスクを組み合わせることで、1つのアプリケーションとなります。

データストレージ

マイクロサービスでは通常、個々のサービスに専用のデータストレージがあります。 SOAでは、ほぼすべてのサービスで同じデータストレージユニットを共有します。

SOAサービスでは同じデータストレージを共有するため、共有データの再利用が可能です。 この機能は、事業部門間で同じデータやアプリケーションを展開することにより、データの価値を最大化するのに役立ちます。 しかしSOAのこの機能によって、サービス間の結合度と相互依存性も高まります。

ガバナンス

SOAはリソース共有の考え方に基づいているため、すべてのサービス間で共通のデータガバナンスの仕組みや基準が使用されます。

マイクロサービスではサービスが独立しているため、統一されたデータガバナンスの仕組みを実現することができません。 このアプローチでは、各マイクロサービスが従うべきガバナンス対策の内容をサービス展開する個人が自由に選択できるため、ガバナンスは大きく緩和されます。そのため、マイクロサービスではチーム間の連携強化が必要となります。

プロジェクトの大きさと範囲

プロジェクトの大きさと範囲は、マイクロサービスとSOAの顕著な違いの1つです。 マイクロサービスは細分化されていることから、展開対象のプロジェクトの大きさと範囲はかなり縮小されます。 比較的小さいサービスの範囲は、開発者に適しています。 対照的に、規模と範囲が比較的大きいSOAは、多様なサービスの複雑な統合に適しています。 SOAは企業間の連携や、その他の大規模統合活動のためのサービスを接続できます。

通信

SOAの通信は従来より、サービス間の「対話」を媒介するESBによって制御されています。 しかしESBを使用すると、SOAのサービスの通信が遅延する可能性があります。 マイクロサービスは、通信を高速化できて言語にとらわれない、APIのような単純なメッセージングシステムに依存します。

結合と凝集

SOAはコンポーネントの共有に基づいているのに対して、マイクロサービスは「境界付けられたコンテキスト」の考え方に基づいています。 境界付けられたコンテキストは、他に多くの依存関係を伴わないコンポーネントとそのデータの結合であり、コンポーネント共有の必要性を低減します。 マイクロサービスにおける結合には、オペレーティングシステムとメッセージングが含まれる場合もあります。通常これらはすべて1つのコンテナに含まれます。

この種の結合によって高い凝集度が得られるので、あるサービスに障害が発生した場合にはその箇所を速やかに隔離して、アプリケーションのパフォーマンスが低下する前に対処できます。 これがマイクロサービスの利点でもあります。対照的に、SOAは共有に重点を置いているため、システムの速度は遅くなり、障害が発生しやすくなります。

リモートサービス

SOAとマイクロサービスは、リモートサービスへのアクセスに異なるプロトコルを使用します。 SOAの主なリモートアクセスプロトコルには、Simple Object Access Protocol（SOAP）と、Advanced Messaging Queuing Protocol（AMQP）やMicrosoft Messaging Queuing（MSMQ）のようなメッセージングプロトコルが含まれます。

マイクロサービスで最も一般的なプロトコルは、Representational State Transfers（REST）と、Java Messaging Service（JMS）などのシンプルなメッセージングプロトコルです。 RESTプロトコルは、よくAPIとともに使用されます。 異種間の相互運用性を得るために通常使用されるSOAのプロトコルと比較して、マイクロサービスのプロトコルは同種の場合が多いです。

展開の容易さ

マイクロサービスとSOAのもう1つの大きな違いは、展開の容易さです。 マイクロサービスのサービスは比較的小規模で、多くの場合互いに独立しているため、SOAのサービスよりもはるかに素早く簡単に展開できます。 また同じ理由で、マイクロサービスのサービスはビルドも容易です。

SOAの場合、サービスが互いに結合されているため、サービスの追加時にアプリケーション全体の再構築と再展開が必要となるため、展開はマイクロサービスより複雑になります。

マイクロサービスとSOA：自社のビジネスにどちらが適しているか？

特定のビジネスに対して、マイクロサービスとSOAのどちらが適しているかを判断する際には、考慮すべき点がいくつかあります。 モノリシックなアプリケーションをモジュール方式で小さなコンポーネントに分割するSOAに対して、マイクロサービスはさらに小さく細分化するアプローチによって同じ目標を達成します。SOAとマイクロサービス、 どちらのアーキテクチャーも、アプリケーションのビルドと展開の柔軟性を向上させるためにクラウドで実行するのが慣例です。 結局のところ、各ビジネスに固有のニーズとユースケースによって最適なアプローチは異なります。

しかし実際には、同じ企業の異なるユースケースに対して、SOAとマイクロサービスの両方を適用することができます。Talend Data Fabricを使用することで、企業はクラウド環境やハイブリッドクラウド環境の展開を通じて、マイクロサービスとSOAの両方に素早くアクセスできるようになります。 包括的なアプリケーションスイートであるTalend Data Fabricによって、クラウド内のデータリソースの管理と安全なデータ統合が実現できます。今すぐTalend Data Fabricをお試しになり、SOAとマイクロサービスの両方に適応し、アプリケーションのビルドと展開の機能を使いこなしましょう。