サービスバス

サービスバスとは?

サービスバスは、異なるアプリケーション間でメッセージを安全に送受信するためのインフラストラクチャです。 送信者と受信者が直接つながる必要がなく、サービスバスが仲介し、確実なメッセージ配信を保証します。これにより、各アプリケーションは独立して動作しながら、疎結合で通信できます。

ひとことで言うと： システム間の手紙を確実に届ける郵便局のようなものです。

ポイントまとめ：

• 何をするものか： メッセージを受け取り、ルーティングして、正確に配信する
• なぜ必要か： システム間の独立性を保ちながら、信頼性の高い通信を実現するため
• 誰が使うか： マイクロサービスアーキテクチャ、エンタープライズシステム統合

なぜ重要か

複数のシステムが連携するとき、直接つながると問題が生じます。送信側がダウンしたら受信側も影響を受けますし、変更が波及します。サービスバスを間に挟むと、各システムが独立して動作できます。

また、メッセージが失われる心配もなくなります。注文システムが「新規注文」メッセージを送信しても、在庫システムが一時的にダウンしていたら、メッセージはキューで待機し、システムが復旧したら自動的に配信されます。

仕組みをわかりやすく解説

サービスバスにはいくつかのコア要素があります。

メッセージキュー： メッセージを一時保存し、受信側が取得するまで待ちます。FIFO(先入れ先出し)順序を保証します。

トピックとサブスクリプション： 1つのメッセージを複数の購読者が受け取るパブリッシュ・サブスクライブモデルです。例えば、「注文作成」というイベントを、在庫システム、配送システム、請求システムが全て受け取ります。

デッドレターキュー： 配信に失敗したメッセージを格納し、後で調査・再処理できます。

実行フロー：アプリケーションAがメッセージを送信 → サービスバスが受け取る → ルーティングルールに基づいて転送 → アプリケーションBが取得 → 確認応答 → メッセージ削除

実際の活用シーン

Eコマース注文処理 ユーザーが注文すると「OrderCreated」メッセージがトピックに送信され、在庫、配送、請求が全てそのメッセージを受け取ります。

IoTセンサーデータ処理 大量のセンサーデータがサービスバスに流れ、複数の分析システムがそれぞれ自分に必要なデータを取得します。

システム間の統合 古いメインフレームと新しいクラウドシステムをAzure Service Busで接続します。

メリットと注意点

メリット： システムの独立性、信頼性の向上、スケーラビリティ、障害の局所化が実現できます。

注意点： 複雑性が増し、デバッグが難しくなります。また、メッセージの重複配信に対応する必要があり、べき等性設計が求められます。

関連用語

• マイクロサービス — サービスバスで通信する分散システム
• 非同期処理 — サービスバスの基本動作
• イベント駆動型アーキテクチャ — サービスバスを活用する設計パターン
• メッセージキュー — サービスバスの基本コンポーネント
• Azure Service Bus — マネージドサービスバス

よくある質問

Q: メッセージが紛失することはありますか? A: 通常はありません。メッセージは確認応答を受けるまで保持され、永続ストレージに保存されます。

Q: メッセージの順序は保証されますか? A: キューであればFIFO順序が保証されます。ただしトピックでは順序保証が弱い場合があります。