Skip to content

MS_AzureServiceBus

Jump to bottom
nishi_74322014 edited this page Aug 19, 2026 · 1 revision

Azure Service Bus

概要

従来のエンタープライズ・アプリケーションを対象とした、ブローカー・メッセージング・システム。

補足（「従来のエンタープライズ」という位置付けの意味）: この一文が
Service Bus の性格を的確に表している。
他のメッセージング サービスとの違いは、
**「取りこぼしが許されない業務処理」**に的を絞っている点にある。

Service Bus Event Grid Event Hubs
運ぶもの メッセージ（業務の指示） イベント（起きた事実の通知） イベント ストリーム（大量の記録）
消えるか 受信して完了したら消える 配信したら終わり 保持期間まで残る
順序保証 あり（セッション使用時） 無し パーティション内では有り
トランザクション あり 無し 無し
重複排除 あり 無し（At least once） 無し
デッド レター あり（標準機能） あり（設定要） 無し
想定スループット 中 中 非常に高い
典型的な用途 受注、決済、基幹連携 リソースの変化の通知 テレメトリ、ログ

つまり、**「1 件でも失ったら業務が成立しない」**ものは Service Bus、
**「大量に流れてくる事実の記録」**は Event Hubs、
**「何かが起きたことの通知」**は Event Grid、
という切り分けになる
（クラウド アプリケーション アーキテクチャ ガイドの
「メッセージング サービスの選択」も参照）。

詳細

機能

機能要件的

  • 通信
  • フィルタやエンリッチメントなど。

非機能要件的

  • プライマリ プロトコル
    AMQP 1.0
  • ライブラリ
    • .NET
    • Java、JMS 2.0
    • JavaScript
    • TypeScript
    • Python

補足（AMQP 1.0 を採用していることの意味）: プロトコルが
ISO/IEC 19464 の国際標準である点は、実務上の利点がある。

利点 内容
既存の MQ 資産との親和性 IBM MQ、RabbitMQ、ActiveMQ も AMQP に対応
JMS 2.0 対応 Java の既存アプリをほぼそのまま繋げられる
ベンダ ロックインの緩和 プロトコル層では独自仕様に依存しない
効率 バイナリ、多重化、フロー制御を備える

特に JMS 2.0 対応は、
オンプレの Java 製基幹システムをクラウドに移す際に効く。
移行・コンバージョン方式の観点で、
アプリを書き換えずにメッセージ基盤だけをクラウドへ移すという
選択肢が成立する。

なお、ポート 5671（AMQP over TLS）が必要になるため、
閉域環境ではアウトバウンドの開放が要る
（Azureのアウトバウンド設計）。
開けられない場合は **AMQP over WebSockets（443 番）**に
フォールバックできる。

用語

名前空間

  • エンドポイント
  • メッセージング コンポーネントの
    コンテナ（キューとトピック）。

キュー

  • PTP メッセージングモデル（1：1）
  • 一般的な MQ はコチラのアーキテクチャ

トピック

  • Pub/Sub メッセージングモデル（1：n）
    • メッセージを複数に配布するイメージ（レプリケーション等で使用される）
    • トピックには複数の独立したサブスクリプションを含めることができる。
  • サブスクリプション・ルール
    • フィルター
      • メッセージのフィルタリング
      • どのサブスクリプションにメッセージをコピーするか？
    • アクション
      エンリッチメントなどの用途

補足（キューとトピックの選択は「後から変えられない」）: 2 つの違いは
同じメッセージを何人が受け取るかである。

【キュー】1 対 1（競合コンシューマー）
  送信 → [ キュー ] → 受信者A ┐
                       受信者B ├ どれか 1 つだけが受け取る
                       受信者C ┘   （負荷分散になる）

【トピック】1 対 n（Pub/Sub）
  送信 → [ トピック ] ┬→ サブスクリプション1 → 受信者A
                      ├→ サブスクリプション2 → 受信者B
                      └→ サブスクリプション3 → 受信者C
                         （全員が同じメッセージのコピーを受け取る）

実務上の指針としては、

状況 選択
処理を分散したい（ワーカーを増やしたい） キュー
将来、受信側が増えるかもしれない トピック（サブスクリプション 1 つでも可）
監査ログ用に「もう 1 系統」流したくなる トピック

迷ったらトピックにしておくという考え方もある。
サブスクリプションが 1 つならキューと同じように使え、
後から受信側を増やす際に送信側を変更せずに済むためである
（疎結合。クラウド アプリケーション アーキテクチャ ガイドの
「改良を見込んだ設計」）。

補足（Service Bus の中核機能）: 本文に列挙されていないが、
「エンタープライズ向け」を成立させている機能を挙げておく。
他のメッセージング サービスとの差はここにある。

機能 内容
ピーク ロック 受信してもすぐには消えない。処理が完了して Complete を呼んで初めて消える。失敗すれば自動的に再配信される
デッド レター キュー（DLQ） 規定回数失敗したメッセージを別のキューに退避。黙って消えない
セッション 同じセッション ID のメッセージを 1 つの受信者が順番に処理。順序保証と状態の引き継ぎ
重複検出 一定時間内の同一 MessageId を自動的に破棄
スケジュール配信 指定時刻に配信
トランザクション 複数の送受信をまとめてコミット／ロールバック

このうち、ピーク ロックと DLQ が
「取りこぼさない」ことの実装である。

【ピーク ロックの流れ】
  ① 受信（ロックされるが、キューには残っている）
  ② 業務処理を実行
  ③-a 成功 → Complete()  → メッセージが消える
  ③-b 失敗 → Abandon()   → ロックが外れ、他の受信者が処理できる
  ③-c 無応答 → ロック期限切れ → 自動的に再配信
      （規定回数を超えたら → デッド レター キューへ）

「処理したことにして消えたが、実際は失敗していた」という
メッセージの消失が構造的に起きない点が、
業務システムで採用される理由である。

なお、DLQ を監視していないという運用は非常に多い。
DLQ にメッセージが入ったらアラートを上げる
（Azureの監視と管理）ようにしておかないと、
失敗が誰にも気付かれずに溜まり続けることになる。

参考

Qiita

https://qiita.com/tags/servicebus

microsoft.com

Microsoft Azure

Microsoft Docs

Tags: 移行, クラウド, IoT, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally