メッセージング ブリッジ パターン

この記事では、メッセージング ブリッジ パターンについて説明します。これは、さまざまなメッセージング インフラストラクチャ上に構築されたさまざまなシステムを統合するために使用できる手法です。

コンテキストと問題

多くの組織やワークロードでは、Microsoft Message Queueing (MSMQ)、RabbitMQ、Azure Service Bus、Amazon SQS などの複数のメッセージング インフラストラクチャを使用する IT システムが、いつの間にか存在するようになっていることがあります。 この問題は、合併、買収、またはコスト効率とメンテナンスの容易さのための現在のオンプレミス システムからクラウドでホストされたコンポーネントへの拡張などが原因で発生する可能性があります。

開発者は、HTTP ベースの Web サービスを使って通信するように、統合されているシステムを変更することで、この課題に対処することがあります。 ただし、この方法には次のような欠点があります。

• システムを変更するには、一方の側に HTTP クライアントを追加し、もう一方に HTTP 要求ハンドラーを追加する必要があります。 その後、システムを再度テストしてデプロイし直す必要があります。
• HTTP エンドポイントをホストする必要があり、Web サービスをセキュリティで保護して高可用性にする際の複雑さが増します。
• カスタムビルドの再試行メカニズムが必要な、ネットワーク接続の問題が頻繁に発生します。

解決策

統合されるシステムが、メッセージ交換によって通信するコンポーネントで構成されている場合は、メッセージング ブリッジ パターンを使うと、統合が改善され、欠点が軽減されます。

このシナリオでは、各システムは 1 つのメッセージング インフラストラクチャに接続します。 さまざまなメッセージング インフラストラクチャ間で統合するため、2 つ以上のメッセージング インフラストラクチャに同時に接続するブリッジ コンポーネントを導入します。 ブリッジは一方からメッセージをプルし、ペイロードを変更することなくそれを他方にプッシュします。

統合されているシステムが、他のシステムやブリッジを認識する必要はありません。 送信側システムは、ネイティブ メッセージング インフラストラクチャ上の指定されたキューに特定のメッセージを送信するように構成されています。 ブリッジでメッセージが取得され、異なるメッセージング インフラストラクチャ内の別のキューに転送されると、受信側システムによってそこからメッセージが取得されます。

福利厚生

• メッセージング ブリッジを介して統合されるシステムを変更する必要はありません。 メッセージがブリッジされていることをエンドポイントが認識しないのが理想的です。
• この統合は、少なくとも 1 回のメッセージ配信メカニズムの保証により、HTTP の代替手段と比較して信頼性が高くなります。
• 移行シナリオをいっそう柔軟にできます。 たとえば、一度にすべてではなく、許されるスケジュールに応じて、メッセージング インフラストラクチャ間でエンドポイントを移行できます。

デメリット

• 一方または両方のメッセージング テクノロジの高度な機能を、ブリッジされたルートで使用できない場合があります。
• ブリッジされたルートでは、両方のテクノロジの制限を考慮する必要があります。 たとえば、メッセージの最大サイズは、MSMQ では 4 MB ですが、Azure Storage キューでは 64 KB だけです。

問題と考慮事項

メッセージング ブリッジ パターンを実装するときは、以下の点を考慮します。

• 統合されるシステムの 1 つが分散トランザクション (Microsoft 分散トランザクション コーディネーター (DTC) など) に依存している場合は、正確さのため、ブリッジに重複除去メカニズムを実装する必要があります。

• 統合されるシステムの 1 つでメッセージング インフラストラクチャが使われておらず、変更できない場合は、他のシステムで使われているインフラストラクチャと SQL Server のエミュレートされたキューの間に、メッセージング ブリッジを構築できます。 レガシ システムでは、SQL Server の変更データ キャプチャ機能を使ってメッセージを送信し、その変更を専用キュー テーブルにプッシュできます。 ブリッジは、これらのメッセージを実際のメッセージング インフラストラクチャに転送できます。

• 各メッセージング インフラストラクチャでは、ブリッジ キューとして指定された 1 つのキューを使用できます。 このトポロジでは、他のシステムに送信されるメッセージの種類の送信先としてその特定のキューを使うように、送信側システムを構成します。 また、送信側がブリッジを認識しないように、各メッセージング インフラストラクチャで複数のキューのペアを使うこともできます。 送信先システムのメッセージング インフラストラクチャ内の各送信先キューに対して、シャドウ キューが作成されます。 ブリッジは、シャドウ キューとそれに対応するものの間でメッセージを転送します。

• 必要な可用性サービス レベル アグリーメント (SLA) を満たすためには、競合コンシューマー アプローチを使ってメッセージング ブリッジをスケールアウトすることが必要になる場合があります。

• 通常のメッセージ処理コンポーネントでは、再試行パターンを使って一時的なエラーが処理されます。 再試行カウンターの制限により、コンポーネントは有害メッセージを検出し、キューからそれを削除して処理のブロックを解除できます。 ブリッジでは、インフラストラクチャで障害が発生した場合にメッセージが誤って有害と識別されるのを防ぐため、別の再試行ポリシーが必要になる場合があります。 サーキット ブレーカー パターンを使って、転送を一時停止することもできます。

このパターンを使用する状況

次のことが必要な場合は、メッセージング ブリッジ パターンを使います。

• 必要な変更を最小限にして、既存のシステムを統合します。
• 他のメッセージング テクノロジを使用できないレガシ アプリケーションを統合します。
• 既存のオンプレミス アプリケーションを、クラウドでホストされたコンポーネントを使って拡張します。
• インターネット接続が安定しないときに、geo 分散システムを接続します。
• システム全体を 1 回の作業で移行する必要なしに、1 つの分散システムをメッセージング インフラストラクチャ間で段階的に移行します。

このパターンは、次の場合には適さないことがあります。

• 関係するシステムの少なくとも 1 つが、他方に存在しないメッセージング インフラストラクチャの機能に依存しています。
• 統合が本質的に同期的であり、開始側のシステムですぐに応答が必要です。
• 統合に、セキュリティやプライバシーに関する考慮など、機能的または非機能的な特定の要件があります。
• 統合のデータ量が、メッセージング システムの容量を超えているか、メッセージングを問題に対して高価なソリューションにしています。

ワークロード設計

設計者は、Azure Well-Architected Framework の柱で説明されている目標と原則に対処するために、ワークロードの設計でどのようにメッセージング ブリッジ パターンを使用できるかを評価する必要があります。 次に例を示します。

設計決定と同様に、このパターンで導入される可能性のある他の柱の目標とのトレードオフを考慮してください。

例

オンプレミスでホストされている従業員スケジュールの管理用に、.NET フレームワークで記述されたアプリケーションがあります。 そのアプリケーションは、MSMQ を介して通信する個別のコンポーネントで適切に構造化されています。 アプリケーションは動作しており、ワークロード チームはそれを書き直すつもりはありません。 ビジネス ニーズを満たすために、スケジュール データの新しいコンシューマーを構築する必要があり、IT 戦略では、コストと提供時間を最適にするため、クラウドネイティブ アプリケーションとして新しいソフトウェアを構築することが求められています。

以前、非同期キュー ベースのアーキテクチャを使ってうまくいったことのあるワークロード チームは、同じアーキテクチャアプローチにする予定ですが、今度は最新のテクノロジである Service Bus を使うつもりです。 ワークロード チームは、一方が他方に与える待ち時間や利用不可の影響を軽減するため、クラウドとオンプレミスのデプロイの間に同期通信を導入することを望んでいません。

チームは、メッセージング ブリッジ パターンを使って 2 つのシステムを接続することにします。 このパターンは 2 つの部分で構成されます。 1 つの部分は、既存の MSMQ キューからメッセージを受信して、Service Bus に転送します。 もう 1 つの部分は、Service Bus からメッセージを取得して、既存の MSMQ キューに転送します。

実装チームは、このアプローチを使うとき、既存のアプリケーションの既存のインフラストラクチャを利用して、新しいコンポーネントと統合します。 既存のアプリケーションは、新しいコンポーネントが Azure でホストされていることを認識しません。 同様に、新しいコンポーネントは、Service Bus メッセージを送信することでコンポーネント間の通信を行いますが、それと同じ方法でレガシ アプリケーションと通信します。 ブリッジは、2 つのシステム間でメッセージを転送します。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

• Rob Bagby | プリンシパル アーキテクチャ コンテンツ リーダー
• Kyle Baley | ソフトウェア エンジニア
• Udi Dahan | Particular Software の創設者兼 CEO
• Chad Kittel | プリンシパル ソフトウェア エンジニア
• Bryan Lamos | 開発者リレーション
• Szymon Pobiega | エンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

• エンタープライズ統合パターン コミュニティによるメッセージング ブリッジ パターンの説明。
• Spring Java フレームワークでのメッセージング ブリッジの実装方法を確認してください。
• QPid ブリッジを使って、AMQP 対応のメッセージング テクノロジをブリッジできます。
• NServiceBus メッセージング ブリッジは、MSMQ、Service Bus、Azure Queue Storage などのさまざまなメッセージング インフラストラクチャをサポートするキュー間ブリッジの .NET 実装です。
• NServiceBus.Router は、メッセージング ブリッジ パターンを実装するオープンソース プロジェクトです。 また、1 つのインスタンスで 3 つ以上のテクノロジをブリッジでき、高度なメッセージ ルーティング機能を備えています。

関連リソース

• 競合コンシューマー パターンを使うと、メッセージング ブリッジの実装で負荷を確実に処理できます。
• 再試行パターンを使うと、メッセージング ブリッジで一時的な障害に対処できます。
• サーキット ブレーカー パターンは、ブリッジのどちらかの側でダウンタイムが発生した場合にリソースを保護します。