エンタープライズアプリケーション統合（EAI）とは？

異なるシステムを接続、変換、オーケストレーションし、組織全体でシームレスなデータフローと自動化されたワークフローを実現するエンタープライズアプリケーション統合について解説します。

エンタープライズアプリケーション統合（EAI）とは、統合ソフトウェアを利用して組織全体のビジネスアプリケーション、システム、データを接続し、シームレスなデータフローと統一された業務運用を実現するプロセスです。

硬直したポイント・ツー・ポイントの接続から、アジャイルで分散型のアーキテクチャに移行することで、現代の企業におけるデータ管理方法は一新されました。しかし、急増する需要に合わせてEAIテクノロジーが進化するにつれて、市場は独自の専門用語や矛盾する手法であふれかえっています。

この記事では、まずEAIの歴史を簡単に振り返り、EAIアーキテクチャにおける主要な開発を順に見ていきます。その後、どのようにして従来と変わらない「ハブ＆スポーク」型のブローカーベースのEAIシステムから、現在のアジャイルで分散型のスタンダードベースのESB（Enterprise Service Bus）アーキテクチャに移り変わっていったかについて説明します。

エンタープライズアプリケーション統合の原点

EAIは2000年代初頭から技術用語としてありましたが、解決しなければならない問題は、それよりもずっと以前から存在していました。端的に言うと、EAIはアプローチの1つです。より正確には、一般企業のインフラストラクチャを構成する複数の異なるシステム間の相互運用を可能にするアプローチの1つです。

エンタープライズアーキテクチャ（EA）は性質上、日常業務のために必要なさまざまなサービスを提供する多数のシステムやアプリケーションで構成される傾向があります。 1つの組織内で、SCMやCRM、社員情報管理、ビジネスロジック管理などに、自社開発のシステムまたはサードパーティベンダーからライセンス購入したシステムを、個別に導入して使用している場合もあります。このようなモジュール化は、一般に望ましいとされています。理論的には、業務プロセスを複数の小さな項目に分割することで、最善かつ最新の技術を各分野で取り入れやすくなります。そのため、変化を続けるビジネスニーズへのすばやい対応が可能になります。

しかし、この分散型モジュールシステムのメリットを活かすためには、アーキテクチャによって引き起こされる以下のような課題に対応するテクノロジーを採用しなければなりません。

相互運用性：インフラストラクチャ内のさまざまなコンポーネントにおいて、異なるOSやデータ形式、言語を使用している場合、標準のインタフェースを介した接続ができないことがあります。
データ統合：モジュール化された分散型システムを機能させるためには、標準的な方法でアプリケーションとシステムの間のデータの流れを処理することで、データベース全体の一貫性を確保することが重要です。
堅牢性、安定性および拡張性：統合ソリューションには、モジュール化されたインフラストラクチャをつなぎ合わせる接着剤としての役割を果たすために、高い堅牢性と安定性、拡張性が求められます。

ポイント・ツー・ポイント型のEAI統合の限界

EAIタイプのアプローチが生まれる以前、統合の課題の大半はポイント・ツー・ポイント型の統合によって実装されてきました。ポイント・ツー・ポイント統合モデルでは、通信するアプリケーションやシステムの各ペアに対して、固有のコネクタが実装されます。このコネクタが、データの変換や統合に加え、統合先のペアに実行されるべきメッセージング関連のサービスのすべてを処理します。

2〜3のシステムだけを統合する小規模インフラストラクチャであれば、このポイント・ツー・ポイント型の統合は非常に有効です。インフラストラクチャのニーズに合わせてカスタマイズされた、軽量な統合ソリューションを確保できます。しかし、インフラストラクチャに新しいコンポーネントが追加されるたびに、包括的な統合アーキテクチャを構成するポイント・ツー・ポイント接続の数が急増することになります。

3つのコンポーネントで構成されるインフラストラクチャでは、「完全な」統合に必要なポイント・ツー・ポイント接続は3つだけです。これに対して、コンポーネントがたった2つ追加されるだけで、必要なコネクタの数は10に増えます。この時点ですでに管理不可能なほど複雑になりますが、さらに8〜9個のコンポーネントから成るシステムが追加されると接続数は30にまで跳ね上がります。もはや、ポイント・ツー・ポイント統合は現実的な選択肢とはなり得ません。

さらに、これらのコネクタはシステムのバージョンアップなどに応じてそれぞれ個別に開発・保守しなければなりません。場合によっては、ベンダーに高額なアップデート費用を支払うことになるかもしれません。これらの発展性や拡張性を考慮するほど、複合的なエンタープライズシステムにおいては、ポイント・ツー・ポイント統合が適していないことは明確でしょう。

エンタープライズアプリケーション統合アーキテクチャ

ポイント・ツー・ポイント型のアプローチを使用した複合的なインフラストラクチャの複雑化や不具合のリスクを避けるため、EAIソリューションはミドルウェアのさまざまなモデルを使用して、インフラストラクチャ全体の統合を集中化・標準化しています。

つまり、EAIはモジュール化されたシステム統合の課題を解決します。統合を、不安定で複雑に絡み合った接続状態（スパゲッティな状態）ではなく、他のタスクのように、システムに対するタスクとして扱うことが可能になります。実際にEAIシステムは、「接続のためのアダプタ」「利用者がデータを使用できるように適切な形式に変換するデータ変換エンジン」「多数の異なる複合的なルーティングシナリオを同時に処理するモジュラー統合エンジン」など、さまざまなコンポーネントを一体化させた統合ソリューションを提供しています。

言い換えれば、EAIは、統合を脆弱な接続が複雑に絡み合った状態として捉えるのではなく、他のタスクと同様にシステムが処理するタスクとして扱うことで、モジュール化されたシステムの統合を実現します。実際にEAIシステムは、「接続のためのアダプタ」「利用者がデータを使用できるように適切な形式に変換するデータ変換エンジン」「多数の異なる複合的なルーティングシナリオを同時に処理するモジュラー統合エンジン」など、さまざまなコンポーネントを一体化させた統合ソリューションを提供しています。

EAIは、ポイント・ツー・ポイントによる強固な接続を緩和してくれます。そのため、アプリケーションは、ユーザの現在位置やデータ要件、メッセージの用途に関する情報がなくてもメッセージが送信できます。それはこうした情報をEAIがすべて処理してくれるために他なりません。これにより、EAIプロバイダの設定変更をするだけで、新しいパーツの追加・削除ができる柔軟なアーキテクチャや、複数のアプリケーションで単一サービスを再利用できる簡素化されたモジュールの開発が実現できるようになります。

最新のEAIアプローチには、中心となる統合メカニズムを追加するメリットを活用して、メッセージングタスクをさらに集約しているものが多数存在しています。最新のEAIは、データ統合に加え、ネットワーク管理、セキュリティ、高速化、拡張性などの機能も備えています。

エンタープライズアプリケーション統合のブローカーモデル

最初の商用EAIソリューションは、文字通り「統合を統一化する」という考えのもと、『ブローカー』と呼ばれる中央に置かれるハブに必要な全ての機能を組み込んでいました。

以下に、このモデルのメリットとデメリットを紹介します。加えて、なぜ、このモデルがESBアーキテクチャに取って代わろうとしているのかについても説明します。

ブローカーモデルとは？

EAIのブローカーアプローチでは、「ブローカー」と呼ばれる中央統合エンジンがネットワークの中心にあり、メッセージ変換やルーティングなど、アプリケーション間で実行される機能を提供しています。アプリケーション間の通信はすべてハブを経由する必要があり、これによりハブはネットワーク全体に対するデータの同時実行性を維持することができます。

通常、ブローカーモデルの実装によりユーザは、システム内のメッセージフローに関する情報にアクセスできる監視・監査ツールを使えるようになります。同時に、多数のシステムやアプリケーション間のマッピングやルーティングを構成する複雑なタスクを高速化するツールも使用できるようになります。

ブローカーモデルのメリット

ブローカーモデルは、他のEAIアプローチと同じく、アプリケーション同士の結び付きを緩和します。

つまり、アプリケーションが非同期通信することで、ユーザは受信者からの応答を待たずにメッセージを送信し、作業を続行できるようになります。メッセージがどのようにエンドポイントに届くのか、もっと言えば、メッセージのエンドポイントすら正確に把握する必要はありません。

また、ブローカーアプローチにより、全てのインテグレーションを中央リポジトリ内で完結できるため、繰り返し処理も少なくて済みます。

ブローカーモデルのデメリット

他のあらゆるアーキテクチャモデルと同じように、中央エンジンを使用する「ブローカー」がネットワークの単一障害点となってしまうことがあります。ブローカーは全アプリケーションのデータセットとステータス間の同時処理に関わるため、アプリケーション間のやり取りは必ずブローカーを経由しなければなりません。

そのため、メッセージ数が多くなり、ブローカーに大きな負荷がかかると、ブローカー自体がボトルネックとなります。また、メッセージの宛先が1か所に集中しているため、地理的に離れた場所では、ブローカーモデルを効果的に利用することが難しくなります。

最後に、ブローカーモデルは特定ベンダーが開発したテクノロジー群の利用を許諾するため、非常に重い仕様になりがちです。そのため、一連のインテグレーションプロセスの中に複数のベンダーの製品や自社開発のシステム、ベンダーサポートが終了したレガシー製品などが含まれている場合、対応が難しい問題が起こることがあります。

Enterprise Service Bus（ESB） - 未来型のEAI

EAIのブローカーモデルは、ごく一部の企業では成功しています。しかし、このモデルを導入したプロジェクトの大多数が、最終的には失敗していることも事実です。当初、EAIアーキテクチャの明確な基準が存在せず、ソリューションのほとんどが独自仕様であったため、初期のEAI製品は高価で重いものでした。また、統合させるシステムがほぼ同質でなければ、意図通りに機能しないことも少なくありませんでした。

ブローカーモデルが、EAIシステムをネットワークの単一障害点としていたため、こうした問題の影響はさらに広がることになります。コンポーネントが機能不全を起こすと、ネットワーク全体の障害に発展します。 2003年に実施されたある調査では、初期のブローカーソリューションの欠陥が原因で最終的に失敗した統合プロジェクトは、およそ70%に上ると推計されています。

バスアーキテクチャ - エンタープライズアプリケーション統合の新たなアプローチ

ブローカーを介したハブ＆スポーク型のEAIアプローチの問題点から脱却する試みの中で新たに誕生したのが、バス形式のEAIモデルです。バスアーキテクチャは、中央ルーティングコンポーネントを使用してシステムからシステムへメッセージを伝達することに変わりはありません。しかし、統合タスクの一部をネットワークの他の部分に分散させることで、1つのコンポーネントにかかる機能の負荷を低減することを可能にしました。

その後、これらのコンポーネントは設定ファイルを介して、さまざまな構成でグループ化されます。これにより、あらゆるインテグレーションプロセスを最も効率的な方法で処理できるだけでなく、コンポーネントをインフラ内の任意の場所でホストしたり、複製して広い範囲の地域にわたって拡張性を確保したりできるようになります。

Enterprise Service Bus（ESB）の誕生

バス型EAIの発展にともない、セキュリティトランザクション処理やエラー対応など、数々の機能が必要になることが判明してきました。バスアーキテクチャでは、これらの機能を個別のコンポーネントが提供します。つまり、ブローカーアーキテクチャのように、これらの機能を統合ロジックに集約して処理するという対応とは逆のアプローチを採用しています。

その結果、安定感があり、軽量なオーダーメイドの統合ソリューションがつくり出されました。このソリューションでは、アプリケーションレイヤーから完全に抽象化され、一貫したパターンを持ち、統合させるシステムに変更を加えることなく、最小限のコーディングにより、設計および構築することができます。

このバス型EAIモデルの進化版が、最終的にEnterprise Service Bus（ESB）として知られるようになりました。

ESBの主な機能

今日、さまざまなESB製品が市販されています。このうちの一部は、「WebSphere Message Broker」や「TIBCO BusinessWorks」のように、ESBに似た機能を提供するようにリファクタリングされてはいますが、ブローカーのような構造をもつ従来型のEAI製品もあります。

他にはMuleSoftのESBとしてのMuleのように、ESBモデルの導入のためにオープンなメッセージングおよび統合のスタンダードにもとづいて、ゼロから設計されている製品も存在しています。

それぞれに違いはありますが、ほとんどのESBは、以下の主要な「機能」または「サービス」が組み込まれています。

位置情報の保護：メッセージのためのエンドポイントを一元的に構成する方法。コンシューマーアプリケーションがメッセージ作成者の情報を必要とせず、メッセージを受信できるようになります。
（データ形式の）変換：ESBがメッセージをコンシューマーアプリケーションで使用できる形式に変換する機能。
プロトコル変換：ESBは変換項目と同様、全ての主要なプロトコルで送信されたメッセージを受け取り、エンドユーザが読み取れる形式に変換する機能。
ルーティング：事前に設定された静的ルールと動的に生成されたリクエストの両方に基づいて、適切なエンドユーザを判別できる機能。
拡張機能：既存のメッセージデータに基づいて、受信したメッセージに欠落しているデータを復元し、送信先に配信する前にそのデータをメッセージに追加する機能。
監視/管理：ESBの役割は、統合プロセスをシンプルにすることです。そのため、ESBには、システムのパフォーマンスやESBアーキテクチャ内でのメッセージの流れを容易に監視できる機能に加え、インフラストラクチャに本来の価値を提供するために、システムを簡単に管理できる手段が求められます。
セキュリティ：ESBのセキュリティは、2つの主要な要素からなります。一つはESB自体がメッセージを安全な方法で処理できるようにすること、もう一つは統合される各システムが使用するセキュリティ保証システム間のネゴシエーションを行うことです。この二つの要素は必須です。

ESBを利用するメリット

ESBによるアプリケーション統合のメリットには、以下のようなものがあります。

軽量：ESBは、あらゆるサービスを備えた単一のハブではありません。多くの相互運用サービスで構成されているため、組織のニーズに応じて重くすることも軽くすることもできます。統合ソリューションの中で最も効率的でしょう。
拡張性：将来、アーキテクチャの発展を考えている場合は、ESBを使用することで、新しく接続するシステムが正常に動作するかを懸念する必要がなくなり、新システムをすぐに既存システムに統合することができます。また、新しいアプリケーションが準備でき次第、バスに接続するだけで、他のインフラとのAPI統合が完了します。
拡張性と分散性：ブローカーアーキテクチャとは異なり、ESBは、地理的に散らばったネットワークに、複数の機能を容易に分散させることができます。さらに個々の機能を提供するために個別のコンポーネントが使用されるので、ESBを使用することで、アーキテクチャの主要部分に対して、高い可用性と拡張性を簡単に確保できます。さらに、高いコスト効率も獲得することが可能です。
SOAへの適応：ESBは、サービス指向アーキテクチャ（SOA：Service Oriented Architecture）を考慮して構築されています。これにより、SOAへの移行を検討している組織は、既存システムの利用を続けながら、再利用可能なサービスをプラグインして採用することで、段階的にSOAへ移行することができます。
段階的な導入：最高峰のESBを導入しようとすると、提供している機能の多さに圧倒されるかもしれません。しかし、ESBと最新のiPaaSソリューションはあくまで統合の「プラットフォーム」と位置付け、使用するのは現在の統合ニーズを満たすコンポーネントだけだと考えるのが分かりやすく、導入もスムーズでしょう。多数のモジュール式コンポーネントは、リソースが利用可能になってから導入しても問題ありません。圧倒的な柔軟性により、段階的な統合アーキテクチャの導入を実現できるため、将来的に予想外の統合ニーズが発生したとしても、迅速な対応が可能になるだけでなく、導入費用も低減することができます。