エンタープライズサービスバスとは
エンタープライズサービスバス (ESB) は、異なるアプリケーション間のリアルタイムのデータ交換をサポートするソフトウェアアーキテクチャパターンです。大規模な組織には、さまざまなデータモデル、プロトコル、およびセキュリティ制限を使用してさまざまな機能を実行する複数のアプリケーションがあります。ESB は、データ変換、プロトコル変換、メッセージルーティングなどの操作を実行することにより、アプリケーションの統合を容易にします。アプリケーションは関連データを ESB に渡し、ESB はそのデータを変換して、それを必要とする他のアプリケーションに転送します。
エンタープライズサービスバスのメリット
エンタープライズサービスバス (ESB) の概念により、組織全体の通信、メッセージング、サービス間の統合を標準化および簡素化できます。次に、小規模な ESB アーキテクチャの実装にはいくつかメリットがあります。
アプリケーション統合の向上
ESB は、エンタープライズアプリケーション統合のための中央プラットフォームを提供します。組織は、基盤となるテクノロジーやプロトコルに関係なく、あらゆる種類のシステムとアプリケーションをシームレスに統合できます。これにより、組織はアプリケーションの保守、管理、拡張が容易になります。
開発効率の向上
デベロッパーは、ESB が提供する事前構築済みの通信サービスを使用することで、アプリケーションを迅速に構築できます。インフラストラクチャのコストをチームで分担し、組み合わせて使用できるようにサーバーをプロビジョニングします。全体的な効率を向上させながら、諸経費と運用コストを削減します。ESB は、市場投入までの時間を短縮し、開発コストを削減することにもつながります。
可視性と制御性の向上
ESB により、組織はさまざまなアプリケーションにわたるデータやサービスの流れを監視し、発生する可能性のある問題を迅速に特定して解決できます。これにより、組織はアプリケーションの可用性、信頼性、安全性を確保できます。
エンタープライズサービスバスの仕組み
エンタープライズサービスバス (ESB) は、サービス指向アーキテクチャ (SOA) の原則に基づいて動作します。
SOA は、サービスと呼ばれるソフトウェアコンポーネントを使用してビジネスアプリケーションを作成するソフトウェア開発の方法です。各サービスはビジネス機能を提供します。また、複数のサービスはプラットフォームや言語を超えて相互に通信することもできます。
ESB プラットフォームは、アプリケーションが相互に通信するために使用する通信サービスを提供します。例としては、メッセージ変換、プロトコル変換、ルーティング、認証などがあります。
(AWS での ESB の実装)
次に、ESB アーキテクチャの主要コンポーネントについて説明します。
エンドポイント
ESB アーキテクチャでは、エンドポイントは ESB への入口または出口と考えることができます。
通常、各エンドポイントには固有のアドレスまたは識別子があります。ウェブサービスインターフェイス、メッセージキュー、FTP サーバーなど、さまざまなテクノロジーを使用してエンドポイントを実装できます。エンドポイントは、XML、JSON、バイナリデータなど、さまざまなメッセージタイプを処理することもできます。
エンドポイントアーキテクチャの柔軟性により、ESB は幅広いシステムやアプリケーションと統合できます。
アダプター
ESB ツールのアダプターコンポーネントは、メッセージをさまざまな形式やプロトコルに変換します。つまり、受信側のソフトウェアアプリケーションで適切に使用できるということです。また、メッセージログ記録、監視、認証、エラー処理などの機能をもたらす場合もあります。
バス
バスは、エンドポイント間のメッセージ交換のコア ESB コンポーネントです。メッセージタイプ、内容、送信先などのさまざまな基準に基づく一連のルールまたはポリシーを使用して、メッセージをルーティングします。
複雑なビジネスプロセスの要件を満たすように、ESB 設定でポリシーを定義できます。HTTP、JMS、FTP などのさまざまな通信プロトコルを使用してエンドポイントと通信します。
バスは次のように機能します。
- バスは 1 つのエンドポイントでメッセージを受信します
- ビジネスポリシーのルールをチェックして、送信先エンドポイントのアドレスを決定します
- メッセージを処理し、送信先エンドポイントに送信します
例えば、バスがエンドポイント A に接続されたアプリケーションから XML ファイルを受け取ったとします。その XML ファイルをエンドポイント B と C に送信する必要があると判断したとすると、エンドポイント B は JSON データを必要とし、エンドポイント C は HTTP Put 関数を必要とします。アダプターは XML ファイルを JSON に変換し、バスはそれをエンドポイント B に送信します。バスはエンドポイント C で XML を使用して HTTP リクエストを実行します。
エンタープライズサービスバスの制限
エンタープライズアーキテクチャは、次の制限によりエンタープライズサービスバス (ESB) から移行しました。
複雑さ
ESB の実装と保守には専門的な技術的知識が必要なため、複雑でコストがかかります。ベンダーロックインにより、別の ESB ソリューションへの切り替えが困難になり、データ統合のオプションが制限されます。新しいエンタープライズアプリケーションを統合できるのは ESB の中央管理チームだけなので、チームの待ち時間が長くなります。
スケーラビリティ
ESB ソフトウェアでは、抽象化と処理のレイヤーが増えるため、通信にさらに遅延が生じます。エンドポイントの数と通信サービスマッピングの数が増えると、ESB がボトルネックになり、パフォーマンスに影響します。ESB サーバーの高可用性とディザスタリカバリを実装するコストも増加します。
アップグレードの難易度
ESB 統合を強化すると、接続されている他のコンポーネントが不安定になる可能性があり、更新前にかなりのテストが必要になります。ESB プロジェクトのアップグレードに資金を提供するには、チーム間のコラボレーションが必要ですが、これは難しい場合があります。
エンタープライズサービスバスに代わるテクノロジーとは?
現在、エンタープライズサービスバス (ESB) の使用は、主に複雑な統合を必要とするレガシーシステムに限定されています。ESB アーキテクチャパターンは、他のテクノロジーの中でも特にマイクロサービスアーキテクチャに置き換えられました。
マイクロサービスアーキテクチャは、軽量 API を通じて公開される独自の通信プロトコルを備えた、非常に小さくて完全に独立したソフトウェアコンポーネントで構成されています。API を介してマイクロサービスを利用するのは基本的にコンシューマーの仕事であるため、一元化された ESB は不要となります。
詳細については、マイクロサービスと API について読むことができます。
クラウドコンピューティングとマイクロサービスアーキテクチャの台頭により、新しいテクノロジーが登場しました。これはよく ESB の代替と見なされます。次にそれらのいくつかについて説明します。
API ゲートウェイ
API ゲートウェイは、クライアントが複数のサービスにアクセスするための 1 つのエントリポイントを提供する軽量コンポーネントです。API の管理、セキュリティの強化、トラフィックの処理によく使用されます。
サービスメッシュ
サービスメッシュは、マイクロサービスアーキテクチャ内のサービス間通信を管理するための専用インフラストラクチャレイヤーです。サービス検出、負荷分散、トラフィック管理などの機能を提供します。
イベント駆動型アーキテクチャ
イベント駆動型アーキテクチャでは、サービスは同期要求ではなく非同期イベント処理を通じて通信します。イベントとは、e コマースウェブサイトのショッピングカートに商品が置かれるなど、状態が変化すること (または更新) です。イベントは、状態 (購入したアイテム、その料金、および配送先住所) を持つことができます。また、識別子 (注文が出荷されたという通知) となることができます。
イベントバスとは
多くの組織がエンタープライズサービスバス (ESB) からイベントバスに移行しています。イベントバスは、イベントを受信するパイプラインです。イベントに基づいてアプリケーションコンポーネントを相互に接続するため、スケーラブルなイベント駆動型アプリケーションを簡単に構築できます。
イベントバスに関連するルールは、イベントが到着するとそれを評価します。各ルールは、イベントがルールの条件に一致するかどうかをチェックします。ルールを特定のイベントバスに関連付けると、そのイベントバスが受信したイベントにのみルールが適用されます。
プロデューサーがイベントバスにイベントを公開します。イベントバスは、事前に設定されたルールに基づいて到着したイベントをフィルタリングして評価し、イベントをコンシューマーにプッシュします。プロデューサーサービスとコンシューマーサービスは切り離されているため、それらを個別にスケーリング、更新、デプロイできます。
AWS はお客様のアプリケーション統合要件にどのように応えることができますか?
Amazon Web Services (AWS) は、一連のアプリケーション統合サービスを提供しています。これにより、マイクロサービス、分散システム、サーバーレスアプリケーションにおける、疎結合化されたコンポーネント間のコミュニケーションを行えます。興味があれば、「AWS でのアプリケーション統合」で詳細をご覧ください。
例えば、要件に合わせて次のサービスを利用できます。
- Amazon API Gateway により、サーバーレスワークロードやウェブアプリケーション向けのあらゆる規模に応じて API を作成、発行、維持、モニタリング、セキュリティを確保できます
- Amazon EventBridge により、独自のアプリケーション、Software as a Service (SaaS)、AWS サービスのアプリケーションデータを接続するイベントバスを構築できます
- Amazon Simple Queue Service (Amazon SQS) により、任意のボリュームのアプリケーションコンポーネント間でメッセージを送信、保存、受信するメッセージキューを構築できます
今すぐアカウントを作成して、AWS でアプリケーション統合を始めましょう。
