Skip to main content

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

サービス指向アーキテクチャー（SOA）は、分散システム内の異なるコンポーネントの疎結合および再利用をサポートする、アーキテクチャーパターンおよび一連の設計原則です。

サービス指向アーキテクチャー（SOA）の概念は2000年代初頭に普及しましたが、現在でも妥当な方法であり続けています。SOA市場のグローバルでの総収益は、2008年の1,100万ドルから、2020年までに約1億ドルにまで増加すると予測されています。この理由の1つには、SOAが黎明期のWebアプリケーションから、オンプレミスやクラウド、そしてマイクロサービスのようなその他の実装を含む、幅広いユースケースへと進化したことが挙げられます。

この記事では、SOAの特徴と、SOAが技術およびビジネスに与える影響について詳しく説明します。

知っておくべきSOAの構成要素

ソフトウェアシステムは当初、管理が困難なモノリスアプリケーションとして設計されていました。クライアントサーバーアーキテクチャーの出現と、ユーザーインターフェイス、ビジネスロジック、データベースの分離により、そのモジュール性を活かした最初の即興的なアプローチが生まれました。SOAではそれをさらに一歩進めて、「アプリケーションとは、共通のネットワークプロトコルを通じて相互に通信するサービスの集合である」と認識するフレームワークを提供しました。

SOAは、サービスプロバイダーとサービスコンシューマーという2つの重要な役割で構成されています。プロバイダーは、技術上またはビジネス上の特定の目標を実現するものです。コンシューマーは、プロバイダーの機能を使用するためにプロバイダーを呼び出します。コンシューマーがリクエストを送信し、プロバイダーがレスポンスを返します。このリクエストとレスポンスの枠組みは、双方が理解できる標準的なメッセージングまたは通信プロトコルに従います。

この通信を実現するために一般的に利用される技術としては、WSDL（Web Services Description Language）、SOAP（Simple Object Access Protocol）、REST（Representational State Transfer）などがあります。

SOAアーキテクチャーを定義する原則を説明する前に、サービスとは何かを確認しましょう。以下はサービスを定義づける4つの特性です。

  1. ビジネス活動を論理的に表し、特定の出力を持つ：サービスは通常、特定の狭い範囲の目的を持つ論理的単位として識別されます。たとえば、Loggerというサービスはアプリケーションのログ記録機能のすべてを管理するとします。ログ記録を目的としていれば、その用途がUIか、サーバーか、データベースかにかかわらずLoggerサービスを再利用できます。
  2. 自己完結型：サービス内のロジックは、他のどのサービスやプロセスからも独立しています。そのため、Loggerサービス内のアルゴリズムを変更したとしても、インターフェイスが壊れていない限り他のサービスには全く影響しません。この特性によって、さまざまなサービスを疎結合することが可能となり、他のプロセスに影響を与えることなく使用する技術を変更したり、コードを最適化したりできます。
  3. コンシューマーにとってブラックボックス：サービスのコンシューマーは、呼び出したサービスの内部で何が起きているのかを全く知りません。たとえば、CustomerInformationというサービスがあるとします。このサービスは最初、データベーステーブルから情報を取得していたかもしれませんが、後にソーシャルメディアのチャンネルからデータを抽出するようになるかもしれません。コンシューマーはこの変更に気付くことはありません。
  4. 基盤となる他のサービスで構成される：サービスは、ビジネス目標を実現するために別のサービスを使用できます。たとえば、Loggerサービスは次に、ファイル内に所定のフォーマットでテキストを書き込むことのできるReadWriteサービスを使用しているかもしれません。

SOAを定義づける8つの特徴

SOAアーキテクチャーのスタイルは技術にとらわれない、ビジネスを中心とするものであり、サービス間のシームレスな相互運用を実現します。以下の8つの原則が、この目標の達成へと導くガイドとなります。

  1. 標準的なサービスコントラクト：コントラクトとは通常、サービスのインターフェイスの定義方法、渡す必要のあるパラメーター、使用されているデータモデル、必要となるメッセージングフォーマット（例：XML）に関するドキュメントを指します。
  2. 疎結合：サービスのインターフェイスは、内部の実装が変更された場合でもインターフェイスポイントが壊れないように定義されている必要があります。
  3. 抽象化：サービスは、ビジネスロジックや使用されている技術のような内部の詳細をすべてカプセル化する必要があります。たとえば、Javaのサービスが.NETのサービスに変更されたとしても、コンシューマーへの影響は全くありません。
  4. 再利用可能：システムをまたいだサービスの再利用は、SOAが目指すゴールの1つです。たとえば、開発者がLoginサービスを構築する場合、複数のシステムやプラットフォームでサービスを利用できるように、機能を汎用化してその範囲を広くすることを考慮すべきです。
  5. 自律性：サービスは、自分自身のロジックに対する制御を最大化し、その設計の外部システムへの依存度合いを少なくするか、ほとんどゼロにすべきです。
  6. ステートレス性：サービスは、以前の状態を記憶しておく必要はありません。サービスを呼び出すアプリケーション側で状態の遷移を記録し、それに応じてビジネスロジックを書き込む必要があります。
  7. 検索性：クライアントが、共通のサービスレジストリを確認することにより利用可能なサービスを見つけられるようにする必要があります。
  8. コンポーザビリティ：管理や再利用が困難になるため、サービスは大きくなり過ぎてはなりません。多くの小さなサービスに分割することにより、リライトも簡単になります。また、サービスをビジネスアプリケーション全体にプラグアンドプレイで組み込める必要もあります。

SOAコンポーネントのフレームワーク

8つの原則によって体系化されたガイドラインが提供されますが、SOAに基づいてアプリケーションをビルドするには、複数のサービスが互いにやり取りしたり、ビジネスアプリケーションで一部のサービスを再利用したりできるようにする、統一されたモデルやフレームワークが必要です。以下で説明するさまざまなSOAのコンポーネントによってそのような実装フレームワークが提供され、異なる可動部品を1つにまとめることができます。

サービスレジストリまたはブローカー

サービスレジストリは、サービスに関連するすべての情報やメタデータを含んでいるカタログまたはディレクトリのことです。これにより、使用範囲が外部のチームや組織にまで広がります。たとえば公開レジストリにアクセスすると、特定のサービスプロバイダーによってどんなインターフェイスが公開されているかを把握できます。

エンタープライズサービスバス（ESB）

ESBは、サービスとの間の通信を管理するメッセージルーティング層のことを指します。共通のプロトコルによって、複数の技術が相互に対話できるようになります。ESBによってポイントツーポイントのやり取りがなくなり、サービスのメンテナンスとスケーリングが容易になります。

サービスオーケストレーション

セントラルサービスマネージャーは、サービスのコンポジションを一定の順序で呼び出しまたはオーケストレーションしたり、独自のロジックでそれに追加したり、特定のビジネス目標を達成したりします。

ビジネスプロセスモデリング（BPM）

SOAの目的は単に一連のサービスを実装するだけでなく、ビジネス目標を達成することです。BPMは、サービスオーケストレーションの表現方法の1つです。ユーザーが現在のワークフローを理解し、分析して改善するのに役立ちます。

統一されたデータモデリング

SOAが疎結合を維持して自律的であるためには、サービスが共通のデータモデルを共有し、データを集約して単一の真実のバージョンを構築するマスターデータストアにアクセスすることが重要です。

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

SOAはよく、同じ原則に基づいているマイクロサービスと比較されます。マイクロサービスはSOAよりも最近になって開発されたもので、SOAの一種であるとさえ考えられています。どちらのスタイルもプラグアンドプレイサービスを使用し、サービスを集めてアプリケーションを形成するという点で、旧来のモノリシックアーキテクチャーとは対立する方式を提唱しています。どちらも独立した技術であり、サービス間の疎結合を奨励しています。

しかしながら両者の間には、主にその範囲と目的において大きな違いがあります。SOAは企業レベルで運用されますが、マイクロサービスはアプリケーション内で使用するアーキテクチャーパターンです。SOAの主な目標が再利用性であるのに対し、マイクロサービスはアプリケーションの開発プロセスをより俊敏にすることを目的としています。

本質的に、SOAでは企業全体で多くのアプリケーションに再利用可能なサービスを作り、それによってコスト削減を実現します。マイクロサービスはアジャイルおよびDevOpsの文化から生まれたもので、そこでは継続的インテグレーションとデリバリーが鍵となります。そのため、アプリケーションを独立してテストおよび展開できる小さなサービスに分割することで、開発とデリバリーを加速しています。

両者の間のもう1つの違いは、データの管理方法です。SOAでは、同じアプリケーション内のさまざまなサービスが共通のデータストアにアクセスします。しかしマイクロサービスでは、本当の意味での自己完結を実現するために、アプリケーション内のそれぞれのマイクロサービスが独自のデータリポジトリを持ちます。このデータの重複によって複雑さが増し、通常はデータの整合性を保つために同期メカニズムが必要となります。

SOAのビジネスアプリケーションへの適用

SOAの概念は技術的かつアーキテクチャーに基づくものですが、最終的な目標はビジネスプロセスを管理可能なチャンクへと効率的にモデル化することです。

SOAが持ついくつかの利点について見てみましょう。

  • 社内でサービスを再利用できるため、大幅にコストを削減できます。また、第三者が利用できるように公開することもできます。たとえば、Google Mapサービスは複数の組織によって広く利用されています。
  • サービスはスケーリング可能です。将来データ量が増加した場合でも、サービスのインスタンスをより多く実行することによって簡単に対処できます。
  • 疎結合および技術的に独立しているという特性により、開発者はより多くの機能をシームレスに追加できます。たとえば、決済サービスに新しいゲートウェイやチャネルを簡単に追加できます。
  • モノリシックなアプリケーションは、メンテナンス、デバッグ、品質テストが困難です。しかし、サービスならテストケースを書きやすく、問題点の絞り込みも容易です。
  • 総じて、サービスとビジネスレイヤーの間が明確にマッピングされたSOAを採用することにより、企業はビジネス上および技術的な変化に俊敏に対処できるようになります。

しかし、SOAにも複雑な点がないわけではありません。SOAを扱う上で注意すべき点をいくつか紹介します。

  • あまりに多くのサービスを使用しすぎると扱いづらくなり、アプリケーション内のホップ数が多くなってパフォーマンスが低下します。しかしこの問題は、設計時に各サービスの範囲を評価することによって回避できます。
  • SOAを成功させるには、サービスオーケストレーション層の優れた設計が不可欠です。複数のサービスを管理し、それらの間のメッセージを変換し、帯域幅を制御することは困難になるかもしれません。

SOAの実装を成功させるために

Talendでは、SOAに関連するいくつかの制限を克服するための支援を行っています。Talendはメッセージを交換およびルーティングするための信頼性の高いスケーラブルなメッセージングプラットフォームを提供することにより、SOAPサービスやRESTサービスを作成してアプリケーション全体にわたって接続するとともに、サービスのやり取りを仲介します。

さらにTalendは、単一環境に統合する必要のある多様なデータサイロへの対処という、今日の企業が直面している最大の課題の1つを解決します。Talend Data Fabricは、さまざまなデータソースを簡単に統合して直感的なセルフサービスでのデータアクセスを可能にする、仮想データレイヤーを構築することによってこの課題を解決します。 

これらの基本的な構成要素を導入することで、複雑なエンタープライズサービスアーキテクチャーであっても管理が可能になります。今すぐTalend Data Fabricをお試しになり、迅速かつアジャイルな統合のニーズに応えましょう。

Talendを使う準備はできていますか？

営業に連絡する

追加の関連記事