キューとトピックの比較：Azure Service Bus で適切なメッセージングパターンを選ぶ

By Mirko Peters · 2026-08-27

ポッドキャストのコンパニオンブログへようこそ！最新のエピソードでは、クラウドメッセージングの基礎的な要素を詳しく掘り下げました。まだ聴く機会がなかった方は…

Automatically translated with AI from the original post. Read the English original

ポッドキャスト補足ブログへようこそ。最新のエピソードでは、クラウドメッセージングの基礎となる要素を深く掘り下げました。まだお聴きでない方は、Azure Service Bus - Simply Explained のエピソードもぜひご覧ください。今回は、分散アプリケーションを構築する際に行う最も重要なアーキテクチャ上の判断の一つ、つまり Azure Service Bus のキューとトピックのどちらを選ぶかについて詳しく解説します。この2つのメッセージングパターンの違いを理解することで、より回復力が高く、拡張性があり、保守しやすいシステムを設計できるようになります。

Azure Service Bus の概要とメッセージングパターン

モノリシックなアーキテクチャから、分散されたマイクロサービスベースの設計へと移行するにつれ、信頼性の高い通信の必要性が何よりも重要になります。サービスがすべてを同期的な HTTP 呼び出しに頼ることはできません。そうすると、密結合、連鎖的な障害、パフォーマンスのボトルネックを生んでしまいます。ここで登場するのがクラウドメッセージブローカーです。

Azure Service Bus は、アプリケーションやサービスを疎結合にするフルマネージドのエンタープライズメッセージブローカーです。プロデューサーは、コンシューマーが誰なのか、あるいはコンシューマーが現在オンラインかどうかさえ知る必要なく、メッセージを送信できます。これにより、Azure Service Bus は高可用性とスムーズなワークロードの平準化を実現します。ただし、Azure Service Bus の利用を決めると、すぐに中核的な設計上の問いに直面します。キューが必要か、それともトピックが必要か、という問いです。

Azure Service Bus とは

キューとトピックの違いに入る前に、Azure Service Bus が実際に何をするのかを確認しておきましょう。その中核にあるのは、受信側のアプリケーションが処理を準備できるまで、名前空間内にメッセージを安全に保存するメッセージブローカーです。at-least-once（少なくとも1回）の配信保証、セッション管理、デッドレター、スケジュールされたメッセージ配信といった、堅牢な機能を提供します。

クラウドのエコシステムにおいて、Azure Service Bus はアプリケーションの異なるコンポーネントの間をつなぐ役割を果たします。eコマースの注文処理、IoT（Internet of Things）のテレメトリ処理、ERP（エンタープライズリソースプランニング）との統合など、いずれの場合でも、Service Bus は必要な耐久性と非同期処理能力を提供し、データがスムーズに流れ続けるようにします。

キューとトピック：中核となるアーキテクチャ上の選択

キューとトピックの根本的な違いは、それぞれがサポートするメッセージングパターン、すなわちポイントツーポイント型かパブリッシュ/サブスクライブ型かに帰着します。パターンの選択を誤ると、後になってアーキテクチャの作り直し、データ重複の問題、あるいはスケーラビリティのボトルネックを招きかねません。

キューは一対一の通信モデルを提供します。キューにメッセージを送信すると、ちょうど1つのコンシューマーがそのメッセージを読み取って処理します。一方、トピックは一対多の通信パターンを提供します。トピックにメッセージを発行すると、複数のサブスクリプションに配信され、複数の独立した下流サービスがまったく同じメッセージのコピーをそれぞれ受信して処理できます。

どちらのパターンを選ぶかは、完全にビジネス要件によって決まります。負荷分散のために、1つのワークロードを複数のワーカーインスタンスに分散させる必要がありますか。それとも、1つのビジネスイベントに対して、複数の異なるシステムがそれぞれ反応する必要がありますか。

Service Bus キューの詳細

Service Bus キューは、従来のエンタープライズメッセージングの主力です。1つのタスクをワーカープールによって必ず1回だけ実行する必要があるシナリオfor に設計されています。

メッセージをキューに送信すると、受信側がそれを取り出すまでキュー内に留まります。キューは、デフォルトで先入れ先出し（FIFO）の配信順序を厳守します。そのため、決済トランザクションの処理や順次的なワークフローステップの実行など、順序が重要なコマンド駆動型のアーキテクチャに最適です。

さらに、キューは負荷の平準化に優れています。アプリケーションに大量のトラフィック急増が発生しても、受信したリクエストはバックエンドのコンピューティングリソースを圧迫することなく、キュー内に安全に蓄積できます。ワーカーサービスは、持続可能で安定したペースでキューからメッセージを取り出せます。

トピックとサブスクリプションの習得

キューがシンプルな1対1の配信を担う一方で、トピックはパブリッシュ/サブスクライブ（pub/sub）アーキテクチャの力を引き出します。トピックはメッセージを送信するためのエンドポイントとして機能しますが、サブスクリプションがなければ単独ではメッセージを保持できません。

サブスクリプションは、トピックに接続された仮想キューと考えるとわかりやすいでしょう。メッセージがトピックに発行されると、そのメッセージのコピーがアクティブな各サブスクリプションに配信されます。各コンシューマーサービスは、トピックに対して自身のサブスクリプションを作成するため、ほかのコンシューマーとは独立してメッセージを処理できます。

例として、Eコマースプラットフォームの注文受付イベントを考えてみます。顧客が注文を行うと、システムは OrderPlaced メッセージをトピックに発行します。在庫サービスは在庫数を更新するサブスクリプションを、請求サービスは支払いを処理するサブスクリプションを、通知サービスは領収メールを送信するサブスクリプションを持っています。3つのシステムはいずれも同時にイベントを受信し、互いに干渉することはありません。

メッセージフィルタリングと柔軟性

Azure Service Bus トピックの最も強力な機能の1つが、メッセージフィルタリングです。多くのpub/subのシナリオでは、サブスクライバーはトピックに発行されたすべてのメッセージを必要とするわけではなく、特定の一部のデータだけに関心があります。

Azure Service Bus では、SQL 風の構文または相関プロパティを使って、サブスクリプションにルールとフィルターを定義できます。たとえば、Region プロパティが NorthAmerica と等しいメッセージ、または OrderAmount が特定のしきい値を超えるメッセージだけを受信するように、サブスクリプションを構成できます。

このフィルタリング機能によりネットワークトラフィックを抑えられ、下流のコンシューマーは自身に関連するデータだけを処理するようになります。その結果、不要なコンピュートのオーバーヘッドを大幅に削減できます。

デッドレターキューによる障害への対処

キューとトピックのどちらを使う場合でも、分散システムは障害が起きやすいものです。メッセージの形式が不正な場合、下流のデータベースがオフラインになった場合、特定のメッセージを処理しようとしてアプリケーションが繰り返しクラッシュした場合はどうなるでしょうか。

Azure Service Bus は、デッドレターキュー（DLQ）によってこの問題をうまく処理します。すべてのキューとトピックサブスクリプションには、デッドレターキューと呼ばれる関連のサブキューがあります。メッセージの処理が何度も失敗した場合（最大配信数を超えた場合）や、有効期限が切れた場合、Service Bus はそのメッセージを自動的に DLQ に移動します。

この仕組みにより「ポイズンメッセージ」を切り離し、メインの処理パイプラインをブロックしないようにできます。エンジニアは DLQ を調べて障害の原因を分析し、根本的なバグを修正したうえで、そのメッセージをメインのワークフローに再送信して正常に処理させることができます。

分散アプリケーション設計のベストプラクティス

Azure Service Bus の実装から最大限の効果を得るには、確立されたアーキテクチャのベストプラクティスに従うことが不可欠です。

• 環境を分離する： 開発、ステージング、本番の各環境には個別の Service Bus 名前空間を使用し、ある環境の障害が別の環境に波及しないようにします。
• Infrastructure as Code を実装する： キュー、トピック、サブスクリプション、フィルターを ARM テンプレート、Bicep、Terraform で定義し、一貫したデプロイを確保します。
• 適切な保持ポリシーを設定する： 既定の最大値に頼るのではなく、実際のビジネス要件に基づいてメッセージの有効期間（TTL）とロック期間を構成します。
• 監視とアラートを設定する： Azure Monitor と Application Insights を活用し、メッセージ数、アクティブなデッドレターメッセージ、サーバーのレイテンシーなどのメトリックを追跡します。

まとめ：アーキテクチャに適したパターンの選択

Azure Service Bus で適切なメッセージングパターンを選ぶことは、回復性とスケーラビリティに優れたクラウドアプリケーションを構築するための基礎となります。負荷を分散し、タスクを順次処理するために、信頼性の高い1対1のポイントツーポイントの仕組みが必要な場合はキューを使用します。複数の独立したシステムにイベントをブロードキャストするパブリッシュ/サブスクライブモデルが必要な場合は、トピックとサブスクリプションを選択します。

クラウドアーキテクチャ、セキュリティ、最新の開発パターンに関するさらなる議論は、ぜひ完全版のエピソードをお聴きください：Azure Service Bus - Simply Explained。これらのメッセージングパターンを正しく統合すれば、クラウドアプリケーションは堅牢で柔軟性が高く、どのような負荷にも対応できる状態を保てます。