ハブ＆スポークの問題点 –バス トポロジーとの対比 —

1.EAI 製品の登場

過去、企業の IT インフラは複雑化の一途をたどるスパイラル状態にありました。既存のレガシー システムに数多くのパッケージ アプリケーションを加えていき、メンテナンスの困難な情報サイロを作り出してしまっていたのです。
このような状況では、ビジネス データもまた各アプリケーションに分散され、情報のサイロ化をも生じています。ビジネス データがこのような状況に陥ると、意思決定に必要な情報をタイムリーに得ることが非常に難しくなります。
1990 年代に登場した EAI (エンタープライズ アプリケーション統合) 製品は、上述の状況を改善することを目的としたものでした。この当時の EAI 製品は、中央にブローカーと呼ぶ “ハブ” を配置し、各アプリケーションは中央のハブを経由して連携する、いわゆる “ハブ&スポーク” の形式を採っていました。

2. ハブ＆スポーク形式の欠点

従来の EAI 製品は、すべてのデータ送受信がハブに集中することでボトルネックとなるなど、以下のような欠点がありました。
• ハブにデータが集中するため、ハブを稼動させるハードウェアに多額な投資が必要
• ハブにすべてを集中させるため、大規模インテグレーションや大容量/大量データの交換に不向き
• ハブに障害が発生すると、すべてのアプリケーション間連携が停止する
• ハブに独自のプロトコルを採用していたため、各アプリケーションとの通信にはプロトコルの違いを吸収するアダプターが必要となる (アダプターの価格は、非常に高価でした)。
その後、標準規格に準拠したプロトコルの採用により高価なアダプターの必要性は減少しましたが、データや障害の一極集中の問題は残されたままとなっています。

3. バス形式の ESB

“ハブ&スポーク” の一極集中の問題を解決するために提唱されたのが、バス形式をトポロジーとする ESB (エンタープライズ サービス バス) *1 です。
バス形式では、図に示すように、データやコントロールの流れが一箇所に集中するポイントがありません。ESB は、地理的にも、また、組織 (企業内の部門や拠点、外部の取引業者など) 的にも分散されて稼動しているアプリケーションすべてにまたがって “敷設”されます。アプリケーション間の通信メッセージやビジネス データは、このバスの上を流れていきます。

ESB *1は、ガートナー社が提唱したコンセプトであり、標準規格として定まったものではありません。このため、製品によってその実装形態は異なっています。例えば、アプリケーション サーバーをベースとした ESB 製品は、アプリケーション サーバーを中心とする “ハブ&スポーク” の形態となっています。このような ESB 製品では、データや障害の一極集中の問題を解消できない点に注意してください。

3. ハブ＆スポークから抜けきれない製品

アプリケーション連携を用途としたプラットフォーム (ミドルウェア) が、多くのベンダーから市販されています。これらの製品のネーミングには、データ連携、SOA、ETL、EAI、マスターデータ統合など、ターゲットを表す様々なキーワードが用いられています。
ターゲット、用途あるいはキーワードが異なっていても、その多くの製品のアーキテクチャは中央のサーバー上で稼働させることを前提とした “ハブ&スポーク” のトポロジーとなっています。また、それらの製品のほとんどが ESB を内包しているとしています。
下図は、このような中央サーバーの上で稼働するプラットフォームを図式化したものです。

本来は、バス トポロジーであるべきはずの ESB も中央のハブ サーバー上で稼働しており、バス トポロジーの利点を活かしきれていません。
また、BPM 機能 (ビジネス プロセスを実行する機能) を実現するために、プロセス エンジンを搭載しています。プロセス エンジンは、ユーザーによって定義記述されたビジネス プロセスを解釈し実行するエンジンで、代表的なものに BPEL エンジンがあります。
このプロセス エンジンは、基本的にリクエスト-リプライ方式でサービスを呼び出します。このリクエスト-リプライ方式は、ハブ＆スポークのトポロジーに非常によくマッチします。
見方を変えた言い方をすれば、BPEL などのプロセス記述にしたがった BPM を行うプラットフォームでは、中央のハブサーバーを前提とした形態しかとれない、とも言えるのです。

4. プロセス エンジンとハブ＆スポーク、その問題点

プロセス エンジンによる連携は、プロセス エンジンをハブとした “ハブ＆スポーク” の形式をとらざるを得ません。
また、サービスとの間で交換されるビジネス データもすべてプロセス エンジンが処理します。
このため、ハブとして機能しているサーバーが、処理負荷のボトルネックとなります。 さらに、ハブ サーバーに障害が発生すると、ビジネス プロセスのすべてが停止してしまいます。
ハブ＆スポーク形式を導入する場合、処理負荷に対処するために、ハブとなるサーバーに相応の規模と処理性能が必要となり、導入コストが高くなりがちです。
負荷分散の目的でサーバーのクラスター構成を採用する場合でも、各クラスター サーバーにも相応のパフォーマンスが求められ、メンテナンスも含めてコストの増大は大きなものとなります。
また、障害発生に対処するためにサーバーの二重化も必要となりますが、大型サーバーの二重化はさらにシステム管理とコストの負担増を大きく招いてしまいます。

次回は、バス トポロジーを実現する ESB のアーキテクチャについて考察する予定です。

参考 (資料、文献、Webサイト など)

1. ESB

ESB 登場の背景、SOA やアプリケーション連携における位置づけ、特徴などの詳細については、TninkIT に筆者が連載していた記事『SOA/ESB の真の姿』をご参照ください。
第１回：ESBの「B（バス）」が意味するものとは