API インフラストラクチャ: ESB と API ゲートウェイの比較 (その 1)

モダン エンタープライズが顧客との関係をより重視することで、収益の向上と顧客維持が実現できるという調査結果があり、組織のすべてのリソースにわたるコネクティビティが求められています。かつて、エンタープライズ サービス バス (ESB) は、サービス指向アーキテクチャ (SOA) 接続における主要なプロバイダーでした。

しかし今日、分散型組織への移行、モノリス サービスからマイクロサービスへの移行が進み、またアプリケーションのクラウド移行も進んでいます。サイロ化されたデータを解放し、レガシー アプリケーションをモダナイズするための手段として API が活用されています。 

感動的なカスタマー エクスペリエンスを提供するためのコネクティビティは、これまで以上に重要になっています。この記事では、今や旧式のコネクティビティ ソリューションとなった ESB の定義、またそのメリット、デメリットについて解説します。

エンタープライズ サービス バス

コネクティビティはいつの時代も重要ではありましたが、これまで企業では組織の効率性の方が重視されてきました。ESB はもともと、サービス指向アーキテクチャ (SOA) において規格やプロトコルが異なるさまざまなサービスを連携するコネクターとしての活用が想定されていました。ESB は、オンプレミスのアプリケーションやデータベースからなるモノリシックなエンタープライズ アーキテクチャの運用を実現しました。

セントラル コネクターとしての ESB

SOA ベースの IT 環境では、各サービスが ESB との統合を 1 つずつ設定します。ESB はそのサービスを他のサービスから利用できるようにし、フォーマット変換、プロトコル ネゴシエーション、キューイング処理などを行います。場合によっては、さらなるビジネス ロジックを管理することもあります。ESB は、データを消費または公開しようとするあらゆるアプリケーションやサービスの中心的なコネクターとなります。

図 1: エンタープライズ サービス バス

このコネクターとしての役割において、ESB は IT インフラのハブとなり、サービス同士を効果的に切り離すことができます。

ESB を経由するサービスが増えれば増えるほど、すべての新しいサービスをESB 経由で提供しようという動きが強まります。最終的には、ESB はそれ自体がモノリス サービスとなってしまいます。ESB と統合するたびに、少しずつロジックが追加され、やがて、ビジネス ロジックは個々のサービスではなく、ESB に宿るようになります。

当然ながら、ESB の発展に伴ってより注意を払う必要が生じ、専任の IT チームが ESB のメンテナンスを担うようになります。ESB はすべてのサービス間通信の中核ハブとして機能するため、ESB チームも同様に、さまざまなアプリケーション チームと通信、連携する必要があります。

ESB のメリットとデメリット

ESB なくしては、システムにサービスが追加されるたびに、特定のサービス間の統合を構築する必要性が飛躍的に増大します。ESB があれば、新しいサービスが追加されるたびに、ESB との直接統合ポイントを 1 か所追加するだけで済みます。

ESB のメリット

ESB によってサービス ディスカバリが可能となり、組織内におけるすべてのサービスの継続的な最新ディレクトリ機能が実現します。ESB は、各サービスからのデータの消費と利用を調整します。

ESB はメッセージ キューイング機能を備えており、通信するサービス同士が同時にオンライン接続する必要がないため、個々のサービスを切り離すことができます。これにより、サービス間通信の回復力が高まり、いずれかのサービスに障害が発生してもその影響を回避できます。

また、ESB では、ロードバランシング機能を使うことでサービスの可用性が高まり、トランザクション制御機能を使うことでロールバック可能な最小単位として複雑な操作を実行できます。

ESB に起因する組織の失敗

各サービスが独自の方法でデータを生成、消費するため、ESB チームは統合に際してすべての形式に対応する必要が生じます。また、新しい ESB の機能を開発し、維持する必要もあります。IT アーキテクチャ全体を簡素化するという ESB の本来の目的とは逆に、ESB そのものが複雑化し、管理負担が増えてしまったのです。

ESB の一極集中により、チーム間の結合度が高くなり、独立性が低下します。すべてのサービスを ESB と統合する必要があるため、そのサービスを管理するチームは、個々の変更について ESB チームと密接に連携する必要があります。

ESB が統合を促進し、ビジネスロジックを強化すると、単なるモノリス サービスではなく、他のすべてのサービスが連携必須のモノリス サービスになります。

こうしたチームの結合とオーバーヘッド増加の結果、各チームや組織全体の俊敏性が低下してしまいます。

ESB の今後

今日の ITチームにおける分散化は加速しています。俊敏性を追求する組織では、(ESB チームのような) 一元的なチームに束縛されない、自律性を持つ少規模開発チームが重要になります。 

今日の IT 環境は異種混合で、組織によるハイブリッドクラウド化やマルチクラウド化が進んでいます。その結果、多種多様な環境をカバーできる統合基盤が求められています。

マイクロサービス化の進展は、従来のモノリシックな ESB とは真逆の流れです。モノリス構造の ESB を複数の専用サービスに分割することで、柔軟性と俊敏性を向上しつつ、ESB による多くのメリットを維持できます。

これが、統合とコネクティビティの新しいモデルである、API ゲートウェイへとつながっていきます。 

おわりに 

次回のブログ記事では、このコネクティビティに関する最新のソリューションである API ゲートウェイについて見ていきます。また、API ゲートウェイと ESB を比較し、さらに、組織が ESB を継続して使いつつ API ゲートウェイを導入し、レガシー アプリケーションと最新アプリケーションをサポートする方法について考察します。


Kong Enterprise の概要、価格、およびライセンス体系などの詳細は、こちらを参照してください。


記事参照: 2021 年 12 月 22 日
 Brad Drysdale
© Kong Inc. 2021
API Infrastructure: ESB versus API Gateway (Part 1)

タイトルとURLをコピーしました