ESB(エンタープライズ・サービス・バス)

menu icon

ESB(エンタープライズ・サービス・バス)

このガイドでは、ESB(SOAの必須コンポーネント)、ESBが提供するメリット、およびESBがマイクロサービス・アーキテクチャーにどのように関連しているかについて詳しくご説明します。

ESB(エンタープライズ・サービス・バス)とは

ESB(エンタープライズ・サービス・バス)は、一元化されたソフトウェア・コンポーネントがバックエンド・システムへの統合(ならびにデータ・モデルの変換、優れた接続、ルーティング、リクエスト)を実行し、それらの統合と変換を新しいアプリケーションで再利用するためのサービス・インターフェースとして利用できるようにするパターンです。 ESBパターンは、通常、可能な限り最高の生産性を保証するよう特別に設計された統合ランタイムとツールセットを使用して実装されます。

ESBとSOA

ESBは、1990年代後半に登場したアーキテクチャーであるSOA(サービス指向アーキテクチャー)の重要なコンポーネントです。 SOAは、ソフトウェア・コンポーネントをサービス・インターフェースを介して再利用可能にする方法を定義します。 これらのインターフェースは、大掛かりな統合を毎回実行することなく新しいアプリケーションに迅速に組み込むことができるように、共通の通信標準を利用しています。

SOAの各サービスは、完全な個別のビジネス機能(顧客の与信の確認、毎月のローン支払いの計算、住宅ローン申請の処理など)を実行するために必要なコードとデータの統合を具体化します。 サービス・インターフェースは疎結合を提供します。つまり、統合がどのように実装されているかについての知識がほとんど、またはまったくなくても、サービス・インターフェースを呼び出すことができます。 データの読み取りや変更のリクエストを送信できるように、サービスは、SOAP(Simple Object Access Protocol)/HTTPまたはJSON/HTTPなどの標準ネットワーク・プロトコルを使用して公開されます。 これらのサービスは、開発者がすばやく見つけて再利用し、新しいアプリケーションを組み立てられるように公開されています。

これらのサービスは一から構築することもできますが、多くの場合、従来のSoR(Systems of Record、定型業務処理システム)の機能をサービス・インターフェースとして公開することによって作成されます。 ここでESBの必要性が生じます。 レガシー・システムとSoRは、通常、古いプロトコルと独自のデータ形式を使用しており、SOAネットワーク・プロトコルと連携するためには変換と統合が必要となります。 ESBは、これらの変換と統合を臨機応変に実行します。 ESBなしでSOAを実装することもできますが、アプリケーションの所有者はそれぞれサービス・インターフェースを公開する独自の方法を見つける必要があります。これは多大な労力を要するとともに(インターフェースが最終的に再利用可能になるとしても)、将来的にも重大なメンテナンスの課題を生むこととなります。

SOAとその中でのESBの役割の詳細については、「SOA(サービス指向アーキテクチャー)の概要」を参照してください。

メリット

理論的には、一元化されたESBは、企業全体のサービスの通信と統合を標準化し、劇的に簡素化する可能性をもたらします。 ハードウェアとソフトウェアのコストを共有でき、サーバーのプロビジョニングは1回行うだけで済み、統合の開発と保守はスペシャリストで構成された1つのチームに任せることができます(必要に応じてトレーニングすることもできます)。

開発者は、単一のプロトコルを使用してESBと「対話」し、サービス間の相互作用を指示するコマンドを発行すればよく、そこからESBによってコマンドの変換、メッセージのルーティング、データの変換が適宜行われ、コマンドが実行されます。 これにより、開発者は、アプリケーションの統合に費やす時間を大幅に短縮し、アプリケーションの構成と改善に多くの時間を費やすことができます。 そして、あるプロジェクトから次のプロジェクトにこうした統合を再利用できることによって、下流でさらに大きな生産性の向上と節約が見込まれました。

しかし、ESBは、数多くの組織がその導入に成功した一方で、他の多くの組織では、SOAを展開する上でのボトルネックと見なされるようになりました。 1つの統合に変更や拡張を加えると、他の統合が不安定になることがよくあります。 ESBミドルウェアの更新は、しばしば既存の統合に影響を与えました。 ESBは一元管理されていたため、やがてアプリケーション・チームは、担当する統合のために待機しなければならなくなりました。 統合の量が増えるにつれ、ESBサーバーの高可用性と災害復旧の実装にはさらなるコストがかかるようになりました。 また、企業間のプロジェクトとして、ESBは資金調達しづらいことが判明し、これらの技術的課題の解決がはるかに困難になりました。

最終的に、一元化されたESBの維持、更新、スケーリングの課題があまりに大変で費用がかかるため、ESBとSOAによってもたらされるはずだった生産性の向上をESBが遅らせていることも珍しくないと判明しました。これは、イノベーションのペースが上がることを見込んでいた基幹業務チームの期待に背くものでした。

ESBの盛衰の詳細については、「ESBの運命」をお読みください。

ESBとマイクロサービス

マイクロサービス・アーキテクチャーを使用すると、単一のアプリケーションの内部を小さな断片に分割して、個別に変更、スケーリング、管理することができます。 マイクロサービスは、仮想化クラウド・コンピューティング、アジャイル開発プラクティス、およびDevOpsの台頭とともに出現し、勢いを増しました。 これらのコンテキストでは、マイクロサービスは以下を提供します。

  • 開発者の俊敏性と生産性の向上。開発者は、アプリケーションの他の部分を変更することも「追いつかせる」ことも必要とせずに、アプリケーションの一部に新しいテクノロジーを組み込むことができます。
  • よりシンプルで費用効果の高い拡張性。任意のコンポーネントを他のコンポーネントから独立してスケーリング可能にすることで、ワークロードの要求に可能な限り迅速に対応し、コンピューティング・リソースを最も効率的に使用できるようにします。
  • レジリエンスの向上。1つのコンポーネントで障害が起きても他のコンポーネントには影響しません。また、各マイクロサービスは、他のコンポーネントを「最大公約数的可用性」の要件に拘束することなく、独自の可用性要件を持つことができます。

マイクロサービスがアプリケーション設計にもたらすのと同じ細分性を統合にもたらすことができ、同様のメリットがあります。 これはアジャイル統合の根底にある考え方であり、ESBを、相互依存せず細分化された分散型統合コンポーネントに分割することで、個々のアプリケーション・チームが所有し管理できるようにします。

マイクロサービスの各種詳細については、「マイクロサービス:完全ガイド」、「SOAとマイクロサービス:違いは何ですか?」およびDan Bettingerの動画「マイクロサービスとは?」をご覧ください。”:

ESBとIBM Cloud

企業がITインフラストラクチャーをハイブリッドクラウド・アプローチに移行するにつれて、SOAやESBのパターンに基づくものを含め、さまざまなワークロードを、より軽量で柔軟な展開モデルに変換する可能性が高くなります。 このような変革は、すべての組織のクラウド・ジャーニーにおけるアプリケーションのモダナイゼーションの一部にすぎません。  

詳細情報はこちら:

  • IBM Cloud Pak for Integrationを使用して、ミドルウェアへの投資を活用、拡張、モダナイズする方法をご覧ください。
  • IBM Cloud Integrationにアクセスして、パーソナライズされた顧客体験のために、複数のプライベートクラウドとパブリッククラウドにわたるすべてのアプリケーションとデータを接続する方法を学びます。

今すぐIBM Cloudアカウントを始めましょう。