SOA とマイクロサービスの違いは何ですか?
サービス指向アーキテクチャ (SOA) は、サービスと呼ばれるソフトウェアコンポーネントを使用してビジネスアプリケーションを作成するソフトウェア開発の方法です。各サービスはビジネス機能を提供します。また、プラットフォームや言語を超えて相互に通信することもできます。デベロッパーは SOA を使用して、さまざまなシステムでサービスを再利用したり、複数の独立したサービスを組み合わせて複雑なタスクを実行したりします。マイクロサービスアーキテクチャは、SOA アーキテクチャスタイルが進化したものです。各 SOA サービスは完全なビジネス機能である一方、各マイクロサービスは 1 つのタスクのみに特化したはるかに小さなソフトウェアコンポーネントです。マイクロサービスは、SOA の欠点に対処して、最新のクラウドベースのエンタープライズ環境とのソフトウェアの互換性を高めます。
SOA アーキテクチャはモノリシックアーキテクチャのどのような制限を解消しますか?
モノリシックアーキテクチャでは、デベロッパーはすべてのサービス機能のコードを単一のコードベースで記述します。サービス指向アーキテクチャ (SOA) を使用すると、デベロッパーは次のようなモノリシックアーキテクチャの課題に対処できます。
- 特定のコンポーネントのみに追加のリソースが必要な場合でも、アプリケーション全体をスケールする必要があるスケーリングの課題。
- 機能がコードベース全体に分散されているため、機能を柔軟に追加または変更できない。
- さまざまなアプリケーション間でコンポーネントを再利用できない。
- 限られた耐障害性。1 つのコンポーネントに障害が発生すると、システム全体がダウンする可能性がある。
- 新しいテクノロジーを採用したり、異なるテクノロジーを使用する外部システムと統合したりするうえでの課題。
モノリシックアーキテクチャでは、アプリケーション全体を担当するオーナーシップチームと開発チームも一元化されます。アーキテクチャの規模と複雑さゆえに、継続的デリバリーや DevOps プラクティスに関する課題に直面しています。
SOA では、デベロッパーはソフトウェア機能をサービスプロバイダーレイヤーとサービスコンシューマーレイヤーに分解します。これらのレイヤーは、エンタープライズサービスバス (ESB) を介してデータを通信および交換します。デベロッパーは SOA を使用して、複雑なアプリケーションを複数の再利用可能なサービスに単純化します。
マイクロサービスアーキテクチャは SOA アーキテクチャのどのような制限を解消しますか?
サービス指向アーキテクチャ (SOA) は大規模なエンタープライズアプリケーションの構築には適しているかもしれませんが、小規模でビジネス固有のアプリケーションをスケールするにはもっと柔軟性が必要です。SOA には次のような制限があります。
- エンタープライズサービスバス (ESB) は複数のサービスを接続するため、単一障害点になります。
- すべてのサービスは共通のデータリポジトリを共有します。これにより、サービスを個別に管理することが困難になります。
- すべてのサービスには幅広い範囲があります。そのため、いずれかのサービスに障害が発生すると、ビジネスワークフロー全体が影響を受けます。
そのため、デベロッパーはアプリケーションを構築するためのよりきめ細かなアプローチを求めて、マイクロサービスアーキテクチャに目を向けています。
マイクロサービスモデルは、SOA サービスをより小さなサービスに分割します。各マイクロサービスは制限されたコンテキスト内で動作し、他のサービスとは独立して実行されます。つまり、マイクロサービスアーキテクチャは個々のサービス間の相互依存性が限られているか、まったくないため、システム全体で障害が発生するリスクが軽減されます。
アーキテクチャの違い: SOA とマイクロサービス
サービス指向アーキテクチャ (SOA) は、より広い企業範囲を網羅しています。さまざまなビジネスユニットが共通のデータ共有プラットフォームで効率的に連携します。これとは対照的に、マイクロサービスは適用範囲が狭くなります。
例えば、在庫管理は e コマースシステムの SOA サービスになります。しかし、マイクロサービスのアプローチでは、在庫管理を在庫状況チェック、フルフィルメント、会計などの小規模なサービスに分割することになります。
実装
SOA の実装には、さまざまなタイプのサービスをアプリケーションに統合することが含まれます。エンタープライズサービスバスを使用して、次のようなサービスタイプを接続します。
- 特定の事業運営をサポートする機能的サービス
- 特定のビジネス機能をその他のサービスに公開するエンタープライズサービス
- デベロッパーがアプリケーションの構築とデプロイに使用するアプリケーションサービス
- 認証やセキュリティなどの非機能的特徴を管理するインフラストラクチャサービス
これとは対照的に、マイクロサービスアーキテクチャは SOA をより細かく独立的に実装したものです。マイクロサービスは、SOA サービスのようにリソースを共有しません。各マイクロサービスは独立して動作し、非常に特殊な機能を提供します。
通信
リモートサービスにアクセスするために、SOA アーキテクチャは一元化されたエンタープライズサービスバス (ESB) を使用して、さまざまなサービスを複数のメッセージングプロトコルで接続します。これらのプロトコルには、SOAP、Advanced Messaging Queuing Protocol (AMQP)、Microsoft Message Queuing (MSMQ) などがあります。ESB に障害が発生すると、すべての SOA サービスが影響を受けます。
一方、マイクロサービスアーキテクチャでは、RESTful API、Java Message Service (JMS)、パブリッシュ/サブスクライブ (pub/sub) イベントストリーミングなど、より単純なメッセージングシステムを使用します。これらの方法では、マイクロサービスがデータを交換する際にアクティブな接続を維持する必要はありません。
API はマイクロサービスアーキテクチャの一般的なツールです。API を使用すると、2 つ以上のマイクロサービスが、一元化されたチャネルを経由せずに直接データを交換できます。ただし、デベロッパーがモニタリングおよび管理する多数のマイクロサービス間で複雑なデータ経路を作成する可能性があります。
データストレージ
SOA 環境は、他の接続サービスが共有する単一のデータストレージレイヤーで構成されています。さまざまなエンタープライズアプリケーションが SOA 実装で同じデータにアクセスして再利用するため、データリポジトリの価値が最適化されます。
対照的に、各マイクロサービスには独自のデータストレージがあります。マイクロサービスアーキテクチャでは、再利用性よりもデータの独立性が重要です。
デプロイ
SOA サービスはある程度結びついているため、デプロイが難しい場合があります。例えば、デベロッパーが新しいサービスを変更または追加する場合、アプリケーション全体を再構築する必要があります。その上、SOA アプリケーションでは、アプリケーションをオペレーティングシステムやハードウェアから切り離すコンテナ化を最大限に活用することができません。
一方、マイクロサービスはクラウド環境でスケールできるように設計されているため、デプロイが簡単です。各マイクロサービスは、デベロッパーがコンテナ化してクラウドにデプロイできる独立したアプリケーションです。
主なメリット: マイクロサービスとSOA
サービス指向アーキテクチャ (SOA) とマイクロサービスの両方により、開発チームはクラウド環境向けに最新のアプリケーションを効率的に構築、デプロイ、管理できます。とはいえ、マイクロサービスには SOA デプロイに比べていくつかの利点があります。
再利用性
SOA 設計の原則の 1 つは、再利用性とコンポーネント共有に重点を置くことです。このアーキテクチャでは、複数の前面アプリケーションが同じ SOA サービスを使用します。例えば、請求書発行と注文追跡ダッシュボードは同じサービスにアクセスして顧客の詳細を取得できます。
一方、マイクロサービスは別のアプローチを取ります。共通のリソースを共有する代わりにデータを複製します。これにより、マイクロサービスベースのアプリケーションはより効率的に動作し、他のサービスのデータ操作に限定されません。
速度
SOA は単純な実装ではそれなりの速度を提供しますが、デベロッパーがシステムにサービスを追加するにつれてデータレイテンシーは増加します。すべてのサービスは、同じ通信リソースとデータ機能を求めて競合します。
これとは対照的に、マイクロサービスアーキテクチャは重複するリソースを共有しないため、システムがスケールしても俊敏性と応答性が維持されます。デベロッパーは、トラフィック需要が高まった場合に、特定のマイクロサービスにコンピューティングリソースを割り当てて増やすことができます。これにより、マイクロサービスベースのアプリケーションを常に許容可能な速度で実行できます。
ガバナンスの柔軟性
SOA ベースのアプリケーションは、さまざまなサービスが使用する共通のリポジトリ全体で一貫したデータガバナンスを提供します。
ただし、マイクロサービスを扱うデベロッパーは、独立したデータストレージユニットごとに異なるガバナンスポリシーを決定できます。開発チームはより効率的に連携し、データガバナンスの仕組みを自由に決定できます。
使用する場面: SOA とマイクロサービス
サービス指向アーキテクチャ (SOA) とマイクロサービスは、組織がモノリシックアーキテクチャからクラウド環境に移行するためのさまざまな方法を提供します。要因次第で、実際のユースケースにおいて一方が他方より適している場合があります。
SOA
レガシーまたはスタンドアロンのエンタープライズアプリケーションを使用する組織は、SOA アーキテクチャの恩恵を受けます。SOA は、従来のソフトウェアプログラムをより小さなモジュール部品に簡略化します。また、共有リソースをプールしてビジネス機能を効率化します。デベロッパーは重複する冗長なサービスを構築するのではなく、既存の SOA サービスを再利用してより多くのビジネスソリューションを実装できます。
マイクロサービス
アジャイル開発チームをサポートするには、マイクロサービスアーキテクチャの方が適しています。デベロッパーは、継続的統合と継続的デリバリー (CI/CD) ツールを使用することで、アプリケーションの安定性に影響を与えることなく、迅速かつ段階的なコード変更を行うことができます。マイクロサービスは、デベロッパーが次の目標を持っているとより効果的です。
- さまざまなプログラミング言語、ライブラリ、またはフレームワークを使用して 1 つのアプリケーションを構築する
- さまざまなソフトウェアフレームワークで構築された個々のサービスを組み合わせる
- コンピューティングリソースをプロビジョニングし、個々のサービスをリアルタイムでスケールする
マイクロサービスを使用すると、企業は最新のクラウド機能の恩恵を受け、何百ものマイクロサービスを簡単にデプロイできます。
相違点の要約: SOA とマイクロサービス
| SOA |
マイクロサービス |
|
| 実装 |
リソースを共有するさまざまなサービス。 |
独立した目的別の小規模サービス。 |
| 通信 |
ESB は、SOAP、AMQP、MSMQ などの複数のメッセージングプロトコルを使用します。 |
API、Java Message Service、Pub/Sub |
| データストレージ |
共有データストレージ。 |
独立したデータストレージ。 |
| デプロイ |
難易度が高い。小さな変更に全体の再構築が必要です。 |
簡単にデプロイ。各マイクロサービスはコンテナ化できます。 |
| 再利用性 |
共有の共通リソースによる再利用可能なサービス。 |
すべてのサービスには独自の独立したリソースがあります。マイクロサービスは API を通じて再利用できます。 |
| スピード |
サービスが追加されるにつれて速度が低下します。 |
トラフィックが増えても速度は安定しています。 |
| ガバナンスの柔軟性 |
すべてのサービスにわたる一貫したデータガバナンス。 |
ストレージごとに異なるデータガバナンスポリシー。 |
AWS はお客様のマイクロサービス要件でどのように役立ちますか?
モジュラーアーキテクチャパターン、サーバーレス運用モデル、アジャイル開発プロセスを使用して、Amazon Web Services (AWS) で最新のアプリケーションを構築します。私たちは、高可用性マイクロサービスを構築して、あらゆる範囲と規模の最新のアプリケーションを強化するための最も完全なプラットフォームを提供します。
AWS でマイクロサービスを操作する方法は次のとおりです。
- マネージドコンテナで安全なマイクロサービスを構築、分離、実行して、オペレーションを簡素化し、管理オーバーヘッドを削減します。詳細については、AWS でのコンテナをご覧ください。
- AWS Lambda は、サーバーをプロビジョニングおよび管理せずにマイクロサービスを実行します。
- マイクロサービスアーキテクチャをサポートするために、15 のリレーショナルおよび非リレーショナルの専用の AWS クラウドデータベースから選択します。
- AWS App Mesh を利用して、AWS で実行されているマイクロサービスを簡単にモニタリングおよび制御します。
- AWS X-Ray とマイクロサービスの複雑なインタラクションをモニタリングおよびトラブルシューティングします。
AWS のマイクロサービスは、イノベーションを加速し、リスクを軽減し、市場投入までの時間を短縮し、総保有コストを削減するのに役立ちます。今すぐ アカウントを作成して、AWS でマイクロサービスを使用開始しましょう。
