ESBの威力と可能性──分散システムを統合する基盤を構築

システムの拡張性と可用性実現のカギを握る「メッセージング」
デビッド・A・チャペル氏／米ソニック ソフトウエア CTE

前編で は、SOA（サービス指向アーキテクチャ）をベースにアプリケーションの統合を実現する「ESB（Enterprise Service Bus）」について、ハブ＆スポーク型の構成をとるEAI（Enterprise Application Integration）やアプリケーションサーバーによる統合との違いなどについて語ってもらった。Webサービスなどの標準技術をベースにしているた め、特定のベンダーに縛られる危険性もなく、既存システムを生かしながらビジネスの変化に柔軟に対応できるシステムを構築できるという。

ESBを提唱する米ソニック ソフトウエア社の「Sonic ESB」のほか、様々なITベンダーがこぞってESB対応をうたい始めており、注目のコンセプトであることは間違いない。しかしESBに対する各社の定義はまちまちな状況で混乱が生じていることも確かだ。

そこで、ESBを導入するためにはどのような軸で製品を評価すべきなのか、ESBを用いて企業システムの統合を成功に導くためにはどのようにすれば いいのか。ESBはどのようにして拡張性や可用性を実現するのかなどについて、前回に引き続き、米ソニック ソフトウエアの副社長兼チーフ・テクノロジ・エバンジェリスト（CTE）であるデビッド・A・チャペル氏のインタビューをお送りする。

各ベンダーの定義が異なる現状では
設計段階から標準技術を採用しているかが評価の軸

──ベンダー各社がESB製品を次々に発表していますが、そのコンセプトはベンダーごとに異なります。ESBの定義がベンダーごとに違うことで、ESBとは何かが理解しにくいと思うのですが、これについてはどうお考えですか。

チャペル　ベンダーによってESBの定義が異なっていることは、確かに市場を混乱させている原因だと思います。

ESBはSOAを実現するアーキテクチャとして、ソニック ソフトウエアが中心となって打ち出しているコンセプトです。特にW3C（World Wide Web Consortium：Web技術の標準化を行う団体）などで標準化されているものではありません。現在我々はESBの標準規格を策定し、それに準拠したものだけESBと呼べるようにしようと取り組んでいるところです。

──各社のコンセプトが異なる現状で企業がESBを導入する場合には、どのように製品を評価すればいいのでしょうか。

チャペル　製品を選択するに当たっては、ESBが本来備えなければならない機能要件 を満たしているのかどうかを冷静に見極めてほしいと考えています。ESBはWebサービスなどのオープンな技術を採用し、分散したシステムをメッセージン グによって接続することで拡張性や可用性を実現するものです。

一口にESB製品といっても、従来のEAIと変わらない製品もあります。中身は従来のままなのに、インタフェースを後付けでWebサービスに対応しただけで、ESBやSOAをうたっている場合もあります。

ESBはハードウエアもOSも選びませんし、特にシステム同士をつなぐインタフェースに関してはWebサービスやJCA（J2EEコネクタ・アーキ テクチャ）など様々な標準技術に対応します。標準技術をベースにしていれば後で別の製品に入れ替えることもできますが、ベンダー独自の技術を利用している のであれば、そのようなこともできなくなってしまいます。その点に注意してください。

※JCA（J2EE Connector Architecture）：J2EE 1.3の仕様の一つ。J2EE上のアプリケーションが業務パッケージやRDBMSなどと接続するためのインタフェースを共通化し、かつ接続用モジュールを APサーバー間で共通に利用しやすくするためのもの（日経システム構築より引用）。

ESBの中核技術はシステム同士をつなぐメッセージング

──ESBの中核となる技術は何でしょうか。

チャペル　ESBのポイントはMOM（Message Oriented Middleware：メッセージ指向ミドルウエア）です。メッセージング機能が基本となります。メッセージング機能によって、異なる環境下などで稼働し ている遠隔地のサーバー間を接続し、拡張性や可用性、相互接続性を実現するのです。

※MOM（Message Oriented Middleware）：個々のアプリケーション間で情報を双方向にやり取りするためのミドルウエアのこと。非同期かつ蓄積型の通信形態であることが特 徴。相手のサーバーなどがビジー状態で利用できない場合はメッセージ・キューにメッセージを一時的に保管し、利用できる状態になったときに通信する。異 なった環境下における複数のアプリケーションを組み合わせて、より柔軟なシステムを構築するための一つの方法。

──Sonic ESBの強みもメッセージング機能にあるのでしょうか。

チャペル　そうです。メッセージングを行う「SonicMQ」は、クライアント側にサーバーへのメッセージを保持しておき、サーバーからの応答がない場合にメッセージを再送信するという仕組みで、通信の高い信頼性と安全性を実現しています。

分かりやすく説明しましょう。クライアントとサーバー間のメッセージを保持するためには、通常は管理サーバーなどにログを保存しておき、管理者レベ ルで監視を行うといった方法をとります。SonicMQの場合はクライアント側に簡単なデータベースを持つことでメッセージを保持し、サーバーとの接続が 再開した際に再送信することで、メッセージが無くならないことを保証しているのです。

さらにSonicMQでは、ソフトウエアによって可用性と信頼性を実現する「Sonic CAA（Continuous Availability Architecture）」という仕組みを採用しています。

──そのSonic CAAという仕組みを利用すると、具体的に何がどう変わるのですか？

チャペル　もっとも大きいのは、システムのフェールオーバー（システムを復旧するこ と）が数秒で可能になることです。この点が大きく評価され、具体的には英国空港公団（BAA：British Airport Authority）が英ヒースロー空港に建設中の第5ターミナル（2008年春に竣工予定）にSonic ESBが導入されることになりました。年間3500万人もの乗降客の流れをリアルタイムに管理し、全機能を自動化するための基盤として採用されたのです。

これだけの大規模ですから、少しでもシステムがダウンすると大問題になります。例えばシステムが1時間ダウンしてしまうと、欧州全体のフライトが混乱しますし、それ以上になると世界中にも影響を与えてしまいます。

ダウンタイム（サーバーがダウンしている時間）が5分でも大打撃を受けますが、Sonic ESBならほぼリアルタイムに回復するのです。言い換えれば、いかにフォールトトレラント（耐障害性）が重要な要件かが分かります。

──専用システムによるフェールオーバーに比べて、どのような利点があるのでしょうか。

チャペル　クラスタリングなどのハードウエアや専用ソフトでフェールオーバーを行う 場合、システムダウンの際に現用系から待機系へ切り替えるために分単位の時間を要してしまいます。現実的には15分程度ですね。Sonic CAAの場合は、メッセージサーバーを切り替えるだけですので、数秒で障害から復旧することができます。

また、高価なハードウエアが不要というのも大きなメリットでしょう。クラスター構成では現用系と待機系という複数のシステムのほかに、共有ストレー ジに高価なRAIDアーキテクチャを利用する必要があります。クラスター構成は高価なだけでなく、管理や設定が複雑で、共有ストレージがSPOF （Single Point Of Failure：単一障害点）になることも問題です。

Sonic CAAの場合は、ソフトウエアを用いてフェールオーバーを行うため、高価なハードウエアが不要です。現用系と待機系サーバーの間でリアルタイムにデータをレプリケーション（複製）するので、共有ストレージのようなSPOFになることもありません。

──ESBのインタフェースとなる技術はWebサービスが中心になるのでしょうか。

チャペル　もちろんほかにもありますが、例えば.NETとJ2EEをつなぐ共通のインタフェースはSOAP、つまりWebサービスです。ヘテロジーニアス（異機種混在）環境をつなぐという観点から考えると、Webサービスが重要な選択肢になることは間違いありません。

しかし現在は多くの場合、WebサービスをRPC（Remote Procedure Call：遠隔操作呼び出し）として使っているだけで、単なるピアツーピアの接続です。2つのアプリケーションサーバー間で通信するというのは容易です が、システム統合で展開しようとすると大きな負担になってしまいます。

※SOAP（Simple Object Access Protocol）：ネットワーク経由で他のコンピュータにあるデータやサービスを呼び出すために規定されたプロトコルの一種。XMLとHTTPなどを ベースにして開発された。SOAPを利用すると、企業のITシステムをインターネット経由で比較的簡単に連携させることが可能になる。

──Webサービスをシステム統合に利用した場合、具体的にはどのような負担が生じるのでしょうか。

チャペル　Webサービスは標準技術をベースにしたサービス・インタフェースですが、すべての問題を解決するわけではありません。

ビジネスプロセスをどう変更するか、自動化はどのように行うのか。信頼性やセキュリティの確保、構築、管理、システムの監視などをどのように図るか といった点まで標準化されているわけではありません。Webサービスが普及しないのは、サービスが少ないからではなく、サービスをきちんと運用するインフ ラがないことだと思います。

システムの開発環境や、Webサービスのホストとしてのアプリケーションサーバーの役割を否定するわけではありません。しかしアプリケーションサー バーによってすべてを統合しようとする、EAI的なアプローチは間違いだと言いたいのです。企業内にいくつかのアプリケーションサーバーが混在していれ ば、それらをつなげるためのレイヤー（層）がもう一つ上に必要になります。

我々はそのコンセプトを「リーブ＆レイヤー」と呼んでいます。既存のシステムを残して（リーブ）、その上にシステム統合するための層（レイヤー）を 積み上げるというものです。それこそがESBであり、既存のIT投資を不良資産化しないためにESBでもう1階層上の共通インフラを実現すればいいので す。

ESBによるシステム統合のアプローチ概念図。図中、上部にあるプラットフォームがESBによるシステム基盤であり、これをベースに各既存システムがスムーズかつ低コストでつなげることができる。

ESBによるシステム統合のアプローチ概念図。図中、上部にあるプラットフォームがESBによるシステム基盤であり、これをベースに各既存システムがスムーズかつ低コストでつなげることができる。

「スモールスタート」がESB導入を成功に導く

──ユーザー企業がESBの導入を成功させるには、どのようにすればいいのでしょうか。

チャペル　システムにSOAのコンセプトを導入するということは、企業文化の“シフト”が必要です。

現在は企業内のそれぞれの部門に業務システムがあり、それぞれが縦割りの“サイロ”構造（部門別にIT環境が分断されてしまうこと）になっていま す。これらのデータをいかにオープンにして共有するのか。そのためには、従来とは違う新しい考え方を導入していかなければなりません。当然、ビジネスプロ セスに影響が出ますし、それを見越した上で良い方向へ進めていくための取り組みが必要になるのです。

具体的には、企業内にシステム統合のための「インテグレーション・コンピテンシーセンター」などを設立するなどして、どこかがきちんとコントロールしながら積極的に取り組む姿勢が必要でしょう。

ビ ジネスプロセスが重要とか、BPM（ビジネスプロセス管理）が普及するなどといわれていますが、システム統合で重要なのは、ビジネスをある程度、分かる人 間が最終的に携わることです。どのシステムから何の機能をサービスとしてESBに接続するのかを決めるためには、業務の知識が欠かせません。ですので、情 報システム部門だけでなく、業務担当者が深くかかわることが、ESBの導入とその効果を最大限にする上でカギとなるでしょう。

──ほかにはどのような課題がありますか。

チャペル　重要なのは、どのように統合プロジェクトを始めるかということです。一番 取り組みやすい方法は、ESBが提唱する初期投資の負担が軽い「スモールスタート」だと思います。まずは小さな部門やシステムから導入し、成功モデルを 作っていくのです。その成功事例を再現することで、企業全体にまで広げていくということです。

──どうもありがとうございました。

■インタビュー全文については、こちら「bp special グリッド・コンピューティング」でもご覧になれます。