エンタープライズアプリケーション統合を理解する：EAIにおけるESBのメリット

今日の企業のITインフラストラクチャにおいて、システムとアプリケーションの統合は、必要不可欠な問題として頻繁に議論されています。この問題を解決するためのアプローチや考え方が多数存在していることが、議論の多さや重要性を証明していると言ってよいでしょう。アプリケーションとデータの統合ソリューションについての調査の初期段階では、たくさんの略語や他人の意見、わかりにくいマーケティング用語に惑わされてしまうことも少なくないと思います。

顧客やパートナー、従業員からの高まり続けるインテグレーションの要望に応えることは企業として必須です。そして、EAI（Enterprise Application Integration）が急速に進化し続ける中で、「何がEAIで何がEAIではないのか？」、また「異なるアプローチの少しの差異が、最終的にどれだけ有望な解決につながるか？」といった議論が多くされています。

この記事では、EAIの進化について分かりやすく整理することで、上述のような疑問を解決していきます。

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

I. EAIのはじまり

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

B. EAのIアプローチ

II. 従来型のEAI

A. The broker model B. Advantages C. Disadvantages

III. ESB - The next step in EAI 

A. Bus architecture - A new approach to EAI B. The enterprise service bus is born C. Core features D. Benefits E. When to use an ESB

I. EAIのはじまり

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

B. EAのIアプローチ

II. 従来型のEAI

A. The broker model B. Advantages C. Disadvantages

III. ESB - The next step in EAI 

A. Bus architecture - A new approach to EAI B. The enterprise service bus is born C. Core features D. Benefits E. When to use an ESB

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

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

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

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

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

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

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

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

ポイント・ツー・ポイント型のアプローチを使用した複合的なインフラストラクチャの複雑化や不具合のリスクを避けるため、EAIソリューションはミドルウェアのさまざまなモデルを使用して、インフラストラクチャ全体の統合を集中化・標準化しています。
EAIベースのインフラストラクチャ内のコンポーネントは、各アプリケーションが個別のコネクタ接続を必要としません。統合機能、メッセージブローカー機能および安定機能を、ネットワーク全体に提供する共通システムに最適な方法での接続を実現します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

どんな統合ソリューションにも強みと弱みがあり、多くの場合、導入環境に左右されます。EAIの導入戦略については、十分に情報を集め、分析・検討した上で意思決定を下すことが、統合を成功させるために不可欠です。

EAIとSOAの取り組みを成功させるためには、単純に「最高」の技術を採り入れればよいというものではありません。想定される製品の利用シーンや負荷の高い状態でのパフォーマンス、成熟度について確実な情報を入手し、今後、組織で解決すべき統合の課題を深く理解することが必須となります。

EAIについての意思決定を下す前に、以下のような質問項目と回答を用意しておくべきでしょう。

• 統合する必要のあるアプリケーションの数は？
• 将来、別のアプリケーションを追加する必要はありますか？
• 使用する通信プロトコルは何種類ありますか？
• 組織にとって拡張性を用意しておく必要はありますか？
• 統合のニーズには、ルーティング、フォーキング、集約が含まれるか？
• 統合では、非同期メッセージング、メッセージングモデルの公開／利用、またはその他の複合的なマルチアプリケーション・メッセージングのプロセスが必要ですか？

MuleSoftの創設者であり、『Muleランタイム』の初代開発者であるRoss Masonは、『To ESB or Not To ESB（ESBを選択すべきかどうか）』というブログを公表しており、統合のためにESBアプローチを検討している組織にとって、優れた入門書となっています。このブログ記事では、上記のチェックリストをさらに拡張したものが紹介されており、ESBが自社の統合ニーズに合っているか否かの判断に役立てることが可能です。