サービス指向アーキテクチャとは何ですか?

サービス指向アーキテクチャ (SOA) は、サービスと呼ばれるソフトウェアコンポーネントを使用してビジネスアプリケーションを作成するソフトウェア開発の方法です。各サービスはビジネス機能を提供します。また、サービスはプラットフォームや言語を超えて相互に通信することもできます。デベロッパーは SOA を使用して、さまざまなシステムでサービスを再利用したり、複数の独立したサービスを組み合わせて複雑なタスクを実行したりします。

例えば、組織内の複数のビジネスプロセスには、ユーザー認証機能が必要です。すべてのビジネスプロセス用に認証コードを書き直す代わりに、単一の認証サービスを作成して、それをすべてのアプリケーションのために再利用できます。同様に、患者管理システムや電子健康記録 (EHR) システムなど、医療機関全体のほぼすべてのシステムで患者を登録する必要があります。これらのシステムは、単一の共通サービスを呼び出して、患者登録タスクを実行できます。

サービス指向アーキテクチャにはどのようなメリットがありますか?

サービス指向アーキテクチャ (SOA) には、すべてのプロセスが単一のユニットとして実行される従来のモノリシックアーキテクチャに比べていくつかのメリットがあります。SOA の主なメリットには、次のものが含まれます。

市場投入までの時間を短縮

デベロッパーは、時間とコストを節約するために、さまざまなビジネスプロセスでサービスを再利用します。SOA を使用することで、コードを記述して最初から統合を実行するよりもはるかに高速にアプリケーションをアセンブルできます。

効率的なメンテナンス

モノリシックアプリケーションでは、大きなコードブロックよりも小さなサービスを作成、更新、デバッグする方が簡単です。SOA でサービスを変更しても、ビジネスプロセスの全体的な機能には影響しません。

適応性の向上

SOA は、テクノロジーの進歩に対して、より高い適応性があります。アプリケーションを効率的かつコスト効率よくモダナイズできます。例えば、医療機関は、新しいクラウドベースのアプリケーションで、古い電子健康記録システムの機能を利用できます。

 

サービス指向アーキテクチャの基本原則はどのようなものですか?

サービス指向アーキテクチャ (SOA) を実装するための明確に定義された標準ガイドラインはありません。ただし、いくつかの基本原則は、あらゆる SOA 実装に共通しています。

相互運用性

SOA の各サービスには、サービスの機能と関連する諸条件を指定する説明ドキュメントが含まれています。基盤となるプラットフォームやプログラミング言語にかかわらず、どのクライアントシステムでもサービスを実行できます。例えば、ビジネスプロセスでは、C# と Python の両方で記述されたサービスを利用できます。直接のインタラクションがないため、あるサービスを変更しても、そのサービスを利用する他のコンポーネントには影響しません。

疎結合

SOA のサービスは、データモデルや情報システムなどの外部リソースへの依存が可能な限り少ない状態で、疎結合されている必要があります。また、過去のセッションやトランザクションからの情報を保持することなく、ステートレスである必要があります。これにより、サービスを変更しても、そのサービスを利用するクライアントアプリケーションや他のサービスに大きな影響を与えることはありません。

抽象化

SOA のクライアントまたはサービスユーザーは、サービスのコードロジックや実装の詳細を知る必要はありません。これらのクライアントやユーザーにとって、サービスはブラックボックスのように見えるはずです。クライアントは、サービス契約や他のサービスの説明ドキュメントを通じて、サービスの機能や利用方法に関する必要な情報を入手します。

詳細度

SOA のサービスは、適切なサイズとスコープを備えている必要があります。
1 つのサービスにつき、1 つの個別のビジネス機能がパッキングされているのが望ましいと言えます。その後、デベロッパーは複数のサービスを利用して、複雑なオペレーションを実行するための複合サービスを作成できます。

サービス指向アーキテクチャのコンポーネントには、どのようなものがありますか?

サービス指向アーキテクチャ (SOA) には 4 つの主要なコンポーネントがあります。

サービス

サービスは SOA の基本的な構成要素です。それらはプライベート (組織の内部ユーザーのみが利用可能) またはパブリック (インターネット経由ですべてのユーザーがアクセス可能) にすることができます。個別に、各サービスには 3 つの主要な機能があります。

サービス実装
サービス実装は、ユーザー認証や請求額の計算など、特定のサービス機能を実行するためのロジックを構築するコードです。

サービス契約
サービス契約は、サービスの性質と、サービスを利用するための前提条件、サービスコスト、提供されるサービスの質など、関連する諸条件を定義します。
 
サービスインターフェイス
SOA では、他のサービスまたはシステムがそのサービスインターフェイスを介してサービスと通信します。インターフェイスは、アクティビティを実行したり、データをやり取りしたりするためにサービスを呼び出す方法を定義します。これにより、サービスとサービスリクエスタ間の依存関係が減少します。例えば、基盤となるコードロジックをほとんどまたはまったく理解していないユーザーでも、そのインターフェイスを介してサービスを利用できます。

サービスプロバイダー

サービスプロバイダーは、他のユーザーが利用できる 1 つ以上のサービスを作成、維持、提供します。組織は、独自のサービスを作成することも、サードパーティーのサービスベンダーから購入することもできます。

サービスコンシューマー

サービスコンシューマーは、サービスプロバイダーに特定のサービスを実行するようにリクエストします。システム全体、アプリケーション、または他のサービスである場合があります。サービス契約は、サービスプロバイダーとコンシューマーが相互にやり取りする際に従わなければならないルールを指定します。サービスプロバイダーとコンシューマーは、異なる部門、組織、業界に属する場合があります。

サービスレジストリ

サービスレジストリまたはサービスリポジトリは、利用可能なサービスのネットワークアクセス可能なディレクトリです。サービスプロバイダーからのサービス説明ドキュメントを保存します。説明ドキュメントには、サービスとその通信方法に関する情報が含まれています。サービスコンシューマーは、サービスレジストリを使用して、必要なサービスを簡単に見つけることができます。

サービス指向アーキテクチャはどのように機能しますか?

サービス指向アーキテクチャ (SOA) では、サービスは独立して機能し、コンシューマーに機能を提供したり、データのやり取りを可能にしたりします。コンシューマーは情報をリクエストし、入力データをサービスに送信します。サービスはデータを処理し、タスクを実行して、レスポンスを返します。例えば、アプリケーションが承認サービスを利用する場合、そのアプリケーションはサービスにユーザー名とパスワードを提供します。このサービスは、それらのユーザー名とパスワードを検証し、適切なレスポンスを返します。

通信プロトコル

サービスは、ネットワークを介したデータ送信を決定する確立されたルールを使用して通信します。これらのルールは通信プロトコルと呼ばれます。SOA を実装するためのいくつかの標準プロトコルには、次のものが含まれます。

• Simple Object Access Protocol (SOAP)
• RESTful HTTP
• Apache Thrift
• Apache ActiveMQ
• Java Message Service (JMS)

SOA 実装で複数のプロトコルを使用することもできます。

サービス指向アーキテクチャの ESB とは何ですか?

エンタープライズサービスバス (ESB) は、複数のサービスを備えたシステムと通信するときに使用できるソフトウェアです。テクノロジーにかかわらず、サービスとサービスコンシューマー間の通信を確立します。 

ESB のメリット

ESB は、再利用可能なサービスインターフェイスを介して通信および変換機能を提供します。ESB は、サービスリクエストを適切なサービスにルーティングする一元化されたサービスと考えることができます。また、リクエストを、サービスの基盤となるプラットフォームおよびプログラミング言語で受け入れられる形式に変換します。

サービス指向アーキテクチャを実装する上で、どのような制限がありますか?

スケーラビリティの制限

サービスが多くのリソースを共有し、自己の機能を実行するために調整する必要がある場合、システムのスケーラビリティは大きく影響を受けます。 

より強い相互依存関係

サービス指向アーキテクチャ (SOA) システムは、時間の経過とともにより複雑になり、サービス間にいくつかの相互依存関係が生じる可能性があります。複数のサービスがループで相互に呼び出している場合、それらを変更またはデバッグするのは難しい場合があります。一元化されたデータベースなどの共有リソースも、システムの速度を低下させる可能性があります。

単一障害点

ESB を使用する SOA 実装について、ESB は単一障害点を作成します。これは一元化されたサービスであり、SOA が支持する分散化の考え方に反します。ESB がダウンすると、クライアントとサービスはまったく通信できなくなります。

マイクロサービスとは何ですか?

マイクロサービスアーキテクチャは、マイクロサービスと呼ばれる非常に小さく完全に独立したソフトウェアコンポーネントで構成されており、1 つのタスクのみに特化し、焦点を当てるものです。マイクロサービスは API を介して通信します。これは、他のソフトウェアシステムがマイクロサービスと通信できるようにするためにデベロッパーが作成するルールです。

マイクロサービスのアーキテクチャスタイルは、最新のクラウドコンピューティング環境に最適です。多くの場合、コンテナで動作します。これは、コードとそのすべての依存関係をパッケージ化する独立したソフトウェアユニットです。

マイクロサービスのメリット

マイクロサービスは、独立してスケーラブルかつ高速で、移植性があり、プラットフォームに依存しません。これらはクラウドに元々備わっている特性です。また、それらは疎結合されています。つまり、他のマイクロサービスへの依存関係は限定的であるか、またはまったくありません。これを実現するために、マイクロサービスは、他のシステムもアクセスして利用する一元化されたデータへのリモートアクセスではなく、必要なすべてのデータへのローカルアクセスを利用できます。これにより、マイクロサービスがパフォーマンスと俊敏性を補うデータ重複が発生します。

マイクロサービスと比較した SOA

マイクロサービスアーキテクチャは、SOA アーキテクチャスタイルが進化したものです。マイクロサービスは、SOA の欠点に対処して、最新のクラウドベースのエンタープライズ環境とのソフトウェアの互換性を高めます。マイクロサービスは細粒度が高く、データ共有ではなくデータ重複を積極的に用います。これにより、軽量 API を介して公開される独自の通信プロトコルで完全に独立します。API を介してマイクロサービスを利用するのは基本的にコンシューマーの仕事であるため、一元化された ESB は不要となります。

AWS はマイクロサービスの実装をどのようにサポートできますか?

AWS は、モジュラーアーキテクチャパターン、サーバーレス運用モデル、アジャイル開発プロセスを備えたモダンアプリケーションを構築するのに最適な場所です。これは、高可用性マイクロサービスを構築して、あらゆる範囲と規模の最新のアプリケーションを強化するための最も完全なプラットフォームを提供します。例えば、次のことができます。

マネージドコンテナで安全なマイクロサービスを構築、分離、実行して、オペレーションを簡素化し、管理オーバーヘッドを削減します。
AWS Lambda を利用して、サーバーをプロビジョニングおよび管理せずにマイクロサービスを実行します。
• マイクロサービスアーキテクチャをサポートするために、15 のリレーショナルおよび非リレーショナルの専用の AWS データベースから選択します。
AWS App Mesh を利用して、AWS で実行されているマイクロサービスを簡単にモニタリングおよび制御します。
AWS X-Ray とマイクロサービスの複雑なインタラクションをモニタリングおよびトラブルシューティングします。

AWS のマイクロサービスは、イノベーションを加速し、リスクを軽減し、市場投入までの時間を短縮し、総保有コストを削減するのに役立ちます。今すぐ AWS アカウントを作成して、AWS で SOA とマイクロサービスの使用を開始しましょう。

AWS での次のステップ

追加の製品関連リソースをチェックする
サービス指向アーキテクチャの詳細 
無料のアカウントにサインアップ

AWS 無料利用枠にすぐにアクセスできます。 

サインアップ 
コンソールで構築を開始する

AWS マネジメントコンソールで、AWS を使って構築を開始しましょう。

サインイン