概要
サービス指向アーキテクチャ (SOA) は、ネットワーク上の共通の通信言語を使用するサービスインタフェースを介してソフトウェアコンポーネントを再利用可能にするソフトウェア設計の一種です。
サービスとはソフトウェア機能または機能セットが自己完結する構成単位で、指定された情報の取得や操作の実行といった特定のタスクを完了するように設計されています。それ自体で完結する個別のビジネス機能を実行するために、必要なコードとデータが統合されています。リモートでアクセスでき、個別の対話または更新が可能です。
つまり、SOA は個別にデプロイおよび保守されているソフトウェア・コンポーネントを統合し、コンポーネント同士の通信や連携を可能にして、異なるシステム間でソフトウェア・アプリケーションを形成できるようにします。
サービス指向アーキテクチャの機能
1990 年代後半に SOA が使われるようになるまで、別のシステムに格納されているサービスにアプリケーションを接続するのは、ポイントツーポイントの密接な統合 (接続性、ルーティング、データモデルの変換など) を伴う複雑なプロセスであり、新しいプロジェクトごとに、開発者が再現する必要がありました。アプリケーション全体のコードが 1 つのデプロイに組み込まれたため、このモデルは「モノリシック」と呼ばれました。アプリケーションの一部が正しく機能しない場合は、全体を一時的にオフラインにして修正し、新しいバージョンとして再度デプロイする必要がありました。
SOA では、リクエストを送信したり、データにアクセスしたりするためのサービスが標準のネットワークプロトコル (SOAP、JSON、ActiveMQ、Apache Thrift など) を使用して公開されているため、開発者はゼロから統合を行う必要がありません。代わりに、開発者はエンタープライズ・サービス・バス (ESB) と呼ばれるパターンを使用できます。ESB は、一元化されたコンポーネントとバックエンドシステム間の統合を実行し、それらをサービスインタフェースとして利用できるようにします。これにより、開発者は関数を再作成せずに、既存のものを再利用することもできます。
サービス指向アーキテクチャでは、サービスは「疎結合」のシステムを使用して通信します。これは、システムやネットワーク内のコンポーネント (「エレメント」とも呼ばれる) を相互接続して、コンポーネント間の依存関係を削減しながら、情報を渡したり、ビジネスプロセスを調整したりできるようにする方法です。これにより、事実上、新しいアプリケーションが作成されます。
モノリシックアプローチと比較した場合のメリット
- 市場投入時間の短縮と柔軟性の向上:サービスの再利用が可能なので、モノリシック・アプリケーションのように開発者が毎回ゼロから始める必要がなく、アプリケーションの構築がはるかに容易かつ迅速になります。
- 新しい市場でのレガシー・インフラストラクチャの使用:SOA により、あるプラットフォームまたは環境の機能を利用して、それを新しいものにスケーリングしたり、拡張したりするのが容易になります。
- アジリティの向上と開発の効率化によるコスト削減
- 簡単なメンテナンス:すべてのサービスは自己完結型で独立しているため、他のサービスに影響を与えることなく、必要に応じた変更と更新が可能です。
- スケーラビリティ:SOA は複数のサービス、プラットフォーム、プログラミング言語にわたってサービスを実行できるため、スケーラビリティが大幅に向上します。また、SOA は標準化された通信プロトコルを使用するので、組織はクライアントとサービス間の対話を減らすことができます。この対話の度合いが下がると、アプリケーションをスケーリングする際の難しさや不便さが軽減します。
- 信頼性の向上:大規模なコードよりも小型のサービスをデバッグする方が簡単です。この観点から、SOA はより信頼性の高いアプリケーションを生成します。
- 高度な可用性:SOA 機能は誰でも利用できます。
SOA のロール
サービス指向アーキテクチャを構成する要素は、3 つのロールです。
サービスプロバイダー
サービスプロバイダーは Web サービスを作成し、それらをサービスレジストリに提供します。サービスプロバイダーは、サービスの利用条件に関与しています。
サービスブローカーまたはサービスレジストリ
サービスブローカーまたはサービスレジストリは、サービスに関する情報をリクエスターに提供する役割を担います。ブローカーはパブリックの場合もプライベートの場合もあります。
サービスリクエスターまたはサービスコンシューマー
サービスリクエスターは、サービスブローカーまたはサービスレジストリでサービスを見つけ、サービスプロバイダーに接続してサービスを受信します。
Red Hat とマイクロサービスについてさらに詳しく知る
サービス指向アーキテクチャとマイクロサービス
サービス指向アーキテクチャによって広まったサービスの概念は、ミドルウェアやマイクロサービスなどにおける先進的なクラウド・コンピューティングと仮想化の中心的なコンポーネントになっています。
SOA とマイクロサービス・アーキテクチャは類似しているため、よく混同されます。その違いを示す主な特徴はそれらが及ぶ範囲です。すなわち、SOA は組織規模のアーキテクチャの手法であり、マイクロサービスはアプリケーション開発チーム内の実装戦略です。
また、この 2 つはそれぞれのコンポーネントとの通信方法が異なります。SOA が ESB を使用してコンポーネントと通信する一方、マイクロサービスは言語に依存しない API を介してステートレスに相互に通信できます。API が言語に依存しないことから、開発チームは使用したいツールを選ぶことができます。このような方法で、マイクロサービスの耐性と柔軟性を高めることができます。
また、SOA は SaaS (Software-as-a-Service) と混同されることもあります。SaaS は、クラウド・コンピューティングの 1 つの形態で、クラウドアプリケーションと、その基盤となるすべての IT インフラストラクチャおよびプラットフォームをユーザーに提供します。SOA の Web サービスは、サービスプロバイダーによって SaaS アプリケーションとして提供される場合があります。通常、SaaS アプリケーションがホストされているクラウド環境を管理するのは、AWS、Azure、IBM Cloud などのクラウドサービスプロバイダーです。
ユーザーは、コンピュータやモバイルデバイス上の Web ブラウザーを介してソフトウェアを操作します。ユーザーは REST や SOAP などの API を使用してソフトウェアを他の関数に接続することもできます。
Red Hat とマイクロサービス
コンテナ・テクノロジーの進歩により、マイクロサービスは、クラウドネイティブ・アプリケーションの基盤になりました。疎結合されたマイクロサービスは、Linux コンテナにデプロイされ、メッセージルーティングの API またはメッシュネットワークを介して接続されます。
各エレメントはビジネス機能を実装し、継続的インテグレーションおよび継続的デプロイメント (CI/CD) などのワークフローを使用する小規模な DevOps チームによって独立して開発されます。これは、モノリシックな開発サイクルによる制限のない、ソフトウェア開発の迅速化、自動デプロイ、定期的な更新を意味します。
Red Hat は、Red Hat® Enterprise Linux® や Red OpenShift をはじめとする Red Hat のオープンソース・ポートフォリオを通じて、既存のインフラストラクチャを最大限に活用しながら、急速かつ適応性の高いクラウド・コンピューティング環境に、インフラストラクチャとアプリケーション開発を徐々に移行したいと考えている組織と手を組むことができます。