エクスポート (0) 印刷
すべて展開

Windows Azure キューと Windows Azure サービス バス キューの比較

更新日: 2014年9月

作成者: Valery Mizonov、Seth Manheim、Abhishek Lal

寄稿者: Brad Calder、Jai Haridas、Jason Hogg、Jeff Irwin、Jaganathan Thangavelu、Kartik Paramasivam、Todd Holmquist-Sutherland、および Ruppert Koch

この記事では、現在 Azure によって提供されている キューと Microsoft Azure の Service Bus キューという 2 種類のキューの相違点と共通点について説明します。この情報を使用すると、それぞれのテクノロジを比較対照して、現在のニーズに最適なのはどちらのソリューションかを十分な情報に基づいて判断できるようになります。

では、 キューService Bus キューという 2 種類のキュー メカニズムがサポートされています。

キューは、Azure ストレージ インフラストラクチャの一部であり、単純な REST ベースの Get/Put/Peek インターフェイスを使用して、サービス内およびサービス間で信頼性の高い永続的なメッセージングを提供します。

Service Bus キューは、より大きな Azure メッセージング インフラストラクチャの一部です。このインフラストラクチャでは、キュー処理だけでなく、パブリッシュ/サブスクライブ、Web サービスのリモート処理、および統合のパターンがサポートされています。Service Bus のキュー、トピック/サブスクリプション、およびリレー詳細情報、「Service Bus メッセージング パターンの概要」を参照してください。

この 2 つのキュー テクノロジは共存していますが、最初に キューが、 ストレージ サービス上に構築された専用のキュー ストレージ メカニズムとして導入されました。Service Bus キューは、より大きな "仲介型メッセージング" インフラストラクチャ上に構築されています。このインフラストラクチャは、複数の通信プロトコル、データ コントラクト、信用ドメイン、ネットワーク環境などにまたがるアプリケーションやアプリケーション コンポーネントの統合を目的としています。

この記事では、 によって提供されるこの 2 つのキュー テクノロジを比較するために、各テクノロジの機能の動作と実装の違いについて説明します。また、アプリケーション開発のニーズに最適な機能を選択するための方法についても説明します。

キューと Service Bus キューは、どちらも、現在 で提供されているメッセージ キュー サービスの実装です。機能に若干の違いがあるため、個々のソリューションの要件や、解決する必要があるビジネス上または技術上の問題に応じて、いずれかまたは両方を使用できます。

特定のソリューションの目的に合うキュー テクノロジを判断する場合、ソリューション設計者および開発者は次の推奨事項を検討する必要があります。詳細については、次のセクションを参照してください。

ソリューション設計者または開発者として、次の場合に キューの使用を検討してください

  • アプリケーションでキューに格納する必要があるメッセージの量が 80 GB を超えており、メッセージの有効期間が 7 日未満の場合。

  • アプリケーションでキュー内のメッセージ処理の進行状況を追跡する必要がある場合。これは、メッセージを処理しているワーカーがクラッシュした場合に役に立ちます。後続のワーカーでその情報を使用して、前のワーカーが中断した時点から処理を再開できます。

  • キューに対して実行されたすべてのトランザクションのサーバー側のログが必要な場合。

ソリューション設計者または開発者として、次の場合に Service Bus キューの使用を検討してください

  • キューをポーリングせずにメッセージを受信できる必要がある場合。Service Bus では、Service Bus でサポートする TCP ベースのプロトコルを使用し、長いポーリングの受信操作を使用することによってこれを実現できます。

  • キューによるメッセージの配信が先入れ先出し (FIFO) の順序で行われることが保証される必要がある場合。

  • と Windows Server (プライベート クラウド) 上で対称的なエクスペリエンスが必要な場合。詳細については、TechNet の「 Service Bus for Windows Server (Service Bus 1.1).

  • 自動重複検出をサポートする必要がある場合。

  • アプリケーションでメッセージを実行時間の長い並列ストリームとして処理する必要がある場合 (メッセージは、自身の SessionId プロパティを使用してストリームに関連付けられます)。このモデルでは、処理を行うアプリケーションの各ノードは、メッセージではなくストリームに対して競合します。処理を行うノードにストリームが渡されると、そのノードはトランザクションを使用してアプリケーション ストリームの状態を確認できます。

  • 複数のメッセージをキューに送信したりキューから受信したりする際にトランザクション動作と原子性が必要な場合。

  • アプリケーション固有のワークロードの TTL (time-to-live) が 7 日間を超える場合。

  • アプリケーションで処理するメッセージのサイズが 64 KB を超えることはあっても 256 KB の制限に近づくことはないと考えられる場合。

  • ロールベースのアクセス モデルを提供して、キューの送信側と受信側に異なる権限/アクセス許可を与える必要がある場合。

  • キューのサイズが 80 GB を超えることはない場合。

  • AMQP 1.0 標準ベースのメッセージング ブローカーを使用する必要がある場合。AMQP 詳細情報、「Service Bus AMQP の概要」を参照してください。

  • いずれは、キュー ベースのポイント ツー ポイントの通信から、キューに送信されたメッセージの一部またはすべての独立したコピーを受信する追加の受信側 (サブスクライバー) をシームレスに統合できるメッセージ交換パターンに移行することを考えている場合。後者は、Service Bus によってネイティブで提供されるパブリッシュ/サブスクライブ機能を指します。

  • 追加のインフラストラクチャ コンポーネントを作成しなくても "At-Most-Once" の配信保証をサポートできる必要がある場合。

  • バッチ メッセージのパブリッシュおよび使用が必要な場合。

  • Windows Communication Foundation (WCF) の 通信スタックとの完全な統合が必要な場合。

以下のセクションの表では、キューの機能を論理的にグループ化しており、 キューと Service Bus キューの両方で使用できる機能をひとめで比較することができます。

このセクションでは、 キューと Microsoft Azure の Service Bus キューで提供される基本的なキュー機能の一部を比較します。

 

比較条件 キュー Service Bus キュー

順序の保証

いいえ

○ - 先入れ先出し (FIFO)

(メッセージング セッションを使用)

配信保証

At-Least-Once

At-Least-Once

At-Most-Once

トランザクションのサポート

いいえ

(ローカル トランザクションを使用)

受信動作

非ブロッキング

(新しいメッセージがない場合はすぐに完了します)

ブロッキング (タイムアウトあり/なし)

(長いポーリング ("Comet 手法") を提供)

非ブロッキング

(.NET マネージ API のみを使用)

プッシュ型 API

いいえ

OnMessage および OnMessage セッション管理 (.NET) API

受信モード

Peek & Lease

Peek & Lock

Receive & Delete

排他アクセス モード

リース ベース

ロック ベース

リース/ロックの期間

30 秒 (既定)

7 日間 (最大) (UpdateMessage API を使用して、メッセージ リースを更新または解放できます。)

60 秒 (既定)

RenewLock API を使用して、メッセージのロックを更新できます。

リース/ロックの粒度

メッセージ レベル

(各メッセージには異なるタイムアウト値を設定できます。この値は、UpdateMessage API を使用して、メッセージの処理中に必要に応じて更新できます)

キュー レベル

(各キューのすべてのメッセージに同じロック粒度が適用されますが、RenewLock API を使用してロックを更新できます)

一括受信

(メッセージを取得するときにメッセージ数 (最大 32) を明示的に指定します)

(プレフェッチ プロパティを有効にして暗黙的に行うか、トランザクションを使用して明示的に行います)

一括送信

いいえ

(トランザクションまたはクライアント側のバッチ処理を使用)

  • Azure ストレージの BLOB またはテーブルを既に使用しており、キューの使用を開始すると、99.9% の可用性が保証されます。BLOB またはテーブルを Service Bus キューと使用する場合は、可用性が低下します。

  • Service Bus キューで FIFO パターンを保証するには、メッセージング セッションを使用する必要があります。Peek & Lock モードで受信したメッセージの処理中にアプリケーションがクラッシュした場合、キューの受信側は、次にメッセージング セッションを受け取ったときに、TTL (time-to-live) 期間が経過した後、失敗したメッセージから開始します。

  • キューは、アプリケーション コンポーネントを分離してスケーラビリティや耐障害性を向上させ、負荷平準化やプロセス ワークフロー構築を容易にするなどの、標準的なキュー シナリオをサポートするように設計されています。

  • Service Bus キューは、At-Least-Once の配信保証をサポートしています。また、セッション状態を使用してアプリケーションの状態を格納し、トランザクションを使用してメッセージの受信とセッション状態の更新の原子性を確保することにより、At-Most-Once セマンティクスをサポートすることもできます。 ワークフロー サービスでは、この方法を使用して At-Most-Once の配信を保証しています。

  • キューでは、開発者とオペレーション チームの双方に対し、キュー、テーブル、および BLOB で一貫性のあるプログラミング モデルが用意されています。

  • Service Bus キューは、1 つのキューのコンテキストでローカル トランザクションをサポートします。

  • Service Bus でサポートされている Receive and Delete モードを使用すると、メッセージング操作の数 (および関連するコスト) を削減できますが、配信の確実性が低下します。

  • キューのリース機能では、メッセージのリースを延長する機能がサポートされています。これにより、メッセージのリースを短くして、ワーカーがクラッシュした場合にすぐに別のワーカーがメッセージを再度処理できるようにしたり、メッセージで現在のリース時間より長い処理時間が必要になった場合にメッセージのリースを延長したりすることができます。

  • キューでは、メッセージをエンキューまたはデキューするときに表示のタイムアウトを設定できます。また、実行時にメッセージを別のリース値で更新したり、同じキューのメッセージを別の値で更新したりすることもできます。Service Busのロックのタイムアウトはキューのメタデータで定義されていますが、RenewLock メソッドを呼び出してロックを更新できます。

  • Service Bus キューのブロッキング受信操作の最大タイムアウトは 24 日です。ただし、REST ベースのタイムアウトの最大値は 55 秒です。

  • Service Bus でサポートされているクライアント側のバッチ処理を使用すると、キュー クライアントで複数のメッセージをバッチ処理して 1 回の送信操作で処理を完了できます。バッチ処理は非同期送信操作でのみ使用できます。

  • 200 TB が上限の キュー (アカウントを仮想化すればさらに確保可能) や無制限キューのような機能により、Azure は SaaS プロバイダーにとって理想的なプラットフォームになります。

  • キューでは、柔軟性が高くパフォーマンスに優れた委任アクセス制御メカニズムがサポートされています。

このセクションでは、 キューと Service Bus キューで提供される高度な機能を比較します。

 

比較条件 キュー Service Bus キュー

スケジュールされた配信

自動的な配信不能レタリング

いいえ

キューの有効期間の増加

(表示のタイムアウトのインプレース更新を使用)

(専用の API 関数を使用)

有害なメッセージのサポート

インプレース更新

サーバー側のトランザクション ログ

いいえ

ストレージのメトリック

分単位のメトリック: 可用性、TPS、API 呼び出し数、エラー数、その他のメトリックをすべてリアルタイムで提供します (分単位で集計され、運用環境での発生から数分以内にレポートされます。詳細については、TechNet の「「Storage Analytics Metrics について」を参照してください。

(GetQueues の呼び出しによる一括クエリ)

状態管理

いいえ

Microsoft.ServiceBus.Messaging.EntityStatus.Active, Microsoft.ServiceBus.Messaging.EntityStatus.Disabled, Microsoft.ServiceBus.Messaging.EntityStatus.SendDisabled, Microsoft.ServiceBus.Messaging.EntityStatus.ReceiveDisabled

メッセージの自動転送

いいえ

キューのパージ機能

いいえ

メッセージ グループ

いいえ

(メッセージング セッションを使用)

メッセージ グループ単位のアプリケーション状態

いいえ

重複検出

いいえ

(送信側で構成可能)

WCF の統合

いいえ

(すぐに使用できる WCF バインドが用意されています)

WF の統合

カスタム

(カスタム WF アクティビティを作成する必要があります)

ネイティブ

(すぐに使用できる WF アクティビティが用意されています)

メッセージ グループの参照

いいえ

ID によるメッセージ セッションの取得

いいえ

  • 両方のキュー テクノロジに、メッセージを後で配信するようにスケジュールできる機能があります。

  • キューの自動転送を使用すると、数千のキューのメッセージを 1 つのキューに自動転送して、受信側アプリケーションはそのキューからメッセージを処理することができます。このメカニズムを使用して、各メッセージ パブリッシャー間でセキュリティの確保、フロー制御、およびストレージ分離を実現できます。

  • キューでは、メッセージの内容の更新がサポートされています。この機能を使用すると、状態情報と進行状況の増分更新をメッセージに永続化して、メッセージの処理を最初からではなく前回のチェックポイントから開始できるようにすることができます。Service Bus キューでは、メッセージ セッションを使用することで同じ機能を実現できます。セッションでは、アプリケーションの処理状態を保存および取得できます (SetState および GetState を使用)。

  • Service Bus キューでのみサポートされている配信不能レタリングは、受信側のアプリケーションで正しく処理できないメッセージを分離する場合や、TTL (time-to-live) プロパティが期限切れになったためにメッセージが宛先に届かない場合に役立ちます。TTL の値は、メッセージがキューに保持される期間を指定します。Service Bus では、TTL が期限切れになると、メッセージが $DeadLetterQueue という特殊なキューに移動されます。

  • キューで "有害な" メッセージを検出するには、アプリケーションでメッセージをデキューするときにメッセージの DequeueCount プロパティを確認します。DequeueCount が一定のしきい値を超えている場合は、そのメッセージをアプリケーション定義の "配信不能" キューに移動します。

  • キューでは、キューに対して実行されたすべてのトランザクションの詳細なログとメトリックの集計値を取得できます。これらのオプションはいずれも、デバッグや、アプリケーションでの キューの使い方を理解するのに役立ちます。また、アプリケーションのパフォーマンス チューニングやキューの使用コストの削減にも役立ちます。

  • Service Busでサポートされている "メッセージ セッション" の概念を使用すると、特定の論理グループに属するメッセージを特定の受信側に関連付けて、メッセージとその受信側の間にセッションのような関係を作成できます。Service Bus でこの高度な機能を有効にするには、メッセージの SessionID プロパティを設定します。受信側では、特定のセッション ID をリッスンして、指定したセッション ID を共有するメッセージを受信できます。

  • Service Bus キューでサポートされている重複検出機能は、MessageID プロパティの値に基づいて、キューまたはトピックに送信された重複するメッセージを自動的に削除します。

このセクションでは、容量および適用可能なクォータの観点から キューと Service Bus キューを比較します。

 

比較条件 キュー Service Bus キュー

最大キュー サイズ

200 TB

(1 つのストレージ アカウントの容量)

1 GB ~ 80 GB

(キューの作成時とパーティション分割を有効化するときに定義します)

最大メッセージ サイズ

64 KB

(Base64 エンコードを使用する場合は 48 KB)

Azure では、キューと BLOB を組み合わせることでサイズの大きいメッセージをサポートし、1 つのアイテムに対して最大 200 GB までのメッセージをエンキューできます。

256 KB

(ヘッダーと本文の両方を含む。ヘッダーの最大サイズは 64 KB)

メッセージの最大 TTL

7 日

無制限

キューの最大数

無制限

10,000

(サービス名前空間あたり。増やすことができます)

同時クライアントの最大数

無制限

無制限

(最大 100 の同時接続数の制限は TCP プロトコル ベースの通信にのみ適用されます)

  • キューでは、内容が XML セーフでないメッセージに対しては Base64 エンコードを使用する必要があります。Base64 エンコードを使用する場合、ユーザー ペイロードの上限は 64 KB ではなく 48 KB になります。

  • Service Bus キューでは、キューに格納されている各メッセージはヘッダーと本文の 2 つの部分から構成されています。メッセージの合計サイズが 256 KB を超えることはできません。

  • クライアントが TCP プロトコルで Service Bus キューと通信する場合は、1 つの Service Bus キューに対する同時接続の最大数が 100 に制限されます。この数は送信側と受信側で共有されます。このクォータに達すると、その後の接続要求は拒否され、呼び出し元のコードが例外を受け取ります。この制限は、REST ベースの API を使用してキューに接続するクライアントには適用されません。

  • Service Busでは、キューのサイズが制限されます。キューの最大サイズは、キューの作成時に 1 ~ 80 GB の値を指定できます。キューの作成時に設定したキュー サイズの値に達すると、その後の受信メッセージは拒否され、呼び出し元のコードが例外を受け取ります。Service Bus でのクォータ詳細情報、「Windows Azure Service Bus のクォータ」を参照してください。

  • 1 つのService Bus サービスの名前空間で 10,000 を超える数のキューが必要な場合は、 サポート チームに連絡してキューの数を増やすことができます。Service Bus でキューの数を 10,000 より多くするには、 管理ポータルを使用して追加のサービス名前空間を作成することもできます。

このセクションでは、 キューと Service Bus キューで提供される管理機能を比較します。

 

比較条件 キュー Service Bus キュー

管理プロトコル

HTTP/HTTPS 経由の REST

HTTPS 経由の REST

ランタイム プロトコル

HTTP/HTTPS 経由の REST

HTTPS 経由の REST

AMQP 1.0 標準 (TCP と TLS)

.NET マネージ API

(.NET managed Storage Client API)

(.NET の仲介型メッセージング API)

ネイティブ C++

いいえ

Java API

PHP API

Node.js API

任意のメタデータのサポート

いいえ

キューの名前付け規則

最大 63 文字

(キューの名前は小文字で指定する必要があります)

最大 260 文字

(キューの名前では大文字と小文字は区別されません)

キューの長さを取得する機能

(メッセージが TTL を過ぎて期限切れになっても削除されていない場合は、概算値となります)

(特定の時点の正確な値)

Peek 機能

  • キューでは、キューの説明に名前と値のペアの形式で任意の属性を適用できます。

  • 両方のキュー テクノロジには、メッセージをロックせずに表示できる機能も用意されています。この機能は、キューのエクスプローラー/ブラウザー ツールを実装する際に便利です。

  • Service Bus の .NET マネージ仲介型メッセージング API は、全二重 TCP 接続を使用して HTTP 経由の REST より高いパフォーマンスを発揮します。また、AMQP 1.0 標準プロトコルもサポートしています。

  • のキュー名は 3 ~ 63 文字の間で指定でき、小文字、数字、およびハイフンを使用できます。詳細については、TechNet の「「キューおよびメタデータの名前付け」を参照してください。

  • Service Bus のキュー名は最大 260 文字までの長さで指定でき、名前付け規則の制限は厳しくありません。Service Bus のキュー名には、文字、数字、ピリオド (.)、ハイフン (-)、およびアンダースコア (_) を使用できます。

このセクションでは、パフォーマンスの観点から キューと Service Bus キューを比較します。

 

比較条件 キュー Service Bus キュー

最大スループット

2,000 メッセージ/秒

(1 KB のメッセージによるベンチマークに基づく値)

2,000 メッセージ/秒

(1 KB のメッセージによるベンチマークに基づく値)

平均待機時間

10 ms

(TCP Nagle を無効にした場合)

20 ~ 25 ms

調整動作

HTTP 503 コードによる拒否

(調整された要求は課金可能な操作として扱われません)

例外/HTTP 503 による拒否

(調整された要求は課金可能な操作として扱われません)

  • 1 つの キューで 1 秒間に最大 2,000 トランザクションを処理できます。トランザクションとは、PutGetDelete のいずれかの操作です。キューに 1 つのメッセージを送信する操作 (Put) は 1 つのトランザクションとしてカウントされますが、メッセージを受信する操作は、多くの場合、メッセージを取得する操作 (Get) とその後にメッセージをキューから削除する操作 (Delete) から成る 2 段階のプロセスです。そのため、成功したデキュー操作には 2 つのトランザクションが含まれるのが一般的です。複数のメッセージを一括取得すると、この影響を軽減できます。この場合、1 つのトランザクションで最大 32 メッセージの Get 操作を実行し、その後、各メッセージに Delete 操作を実行できます。スループットを改善するために、複数のキューを作成することができます (1 つのストレージ アカウントで作成できるキューの数は無制限です)。

  • アプリケーションが キューの最大スループットに達すると、通常、キュー サービスから HTTP 503 (サーバーがビジー状態) 応答が返されます。この場合、アプリケーションで、指数関数的なバックオフ遅延を使用する再試行ロジックを開始する必要があります。

  • ストレージ アカウントと同じ場所 (領域) にあるホステッド サービスからの小さなメッセージ (10 KB 未満) を処理する場合、 キューの待機時間は平均 10 ミリ秒です。

  • キューと Service Bus キューの両方で、調整されているキューに対する要求を拒否すると調整動作が適用されます。ただし、どちらのキューでも、調整された要求は課金可能な操作として扱われません。

  • Service Bus キューに対するベンチマークによると、1 つのキューのメッセージ スループットは、約 1 KB のメッセージで最大 2,000 メッセージ/秒です。より高いスループットを達成するには複数のキューを使用します。Service Bus によるパフォーマンスの最適化の詳細については、「Service Bus で仲介型メッセージングを使用したパフォーマンス向上のヒント集」を参照してください。

  • Service Bus キューが最大スループットに達すると、キューが調整されていることを示す ServerBusyException (.NET マネージ仲介型メッセージング API を使用している場合) または HTTP 503 (REST ベースの API を使用している場合) の応答がキュー クライアントに返されます。

このセクションでは、 キューと Service Bus キューでサポートされる認証および承認機能について説明します。

 

比較条件 キュー Service Bus キュー

認証

対称キー

対称キー

アクセス制御モデル

SAS トークンを介した委任アクセス。

ACS を介した RBAC

ID プロバイダー フェデレーション

いいえ

  • どちらのキュー テクノロジでも、すべての要求を認証する必要があります。匿名アクセスを使用するパブリック キューはサポートされていません。SAS を使用すると、書き込み専用 SAS、読み取り専用 SAS、またはフルアクセス SAS をパブリッシュすることで、このシナリオに対応できます。

  • キューによって提供される認証方式では対称キーが使用されます。対称キーとは、SHA-256 アルゴリズムを使用して計算され、Base64 文字列としてエンコードされるハッシュ ベースのメッセージ認証コード (HMAC) です。各プロトコル詳細情報、「ストレージ アカウントへのアクセスの認証」を参照してください。Service Bus キューでは、対称キーを使用する類似のモデルがサポートされています。詳細については、TechNet の「 Service Bus での共有アクセス署名認証.

  • Service Bus でサポートされている Microsoft Azure Active Directory アクセス制御 (アクセス制御サービスまたは ACS) には、AdminSenderReceiver という 3 種類のロールがあります。これは、現時点では キューではサポートされていません。

  • Service Bus では ACS の統合がサポートされているため、Active Directory (ADFS を使用) および一般的な Web ID プロバイダー (Live ID、Google、Facebook、および Yahoo など) とのフェデレーションが可能です。

このセクションでは、コストの観点から キューと Service Bus キューを比較します。

 

比較条件 キュー Service Bus キュー

キュー トランザクションのコスト

$0.0005

(10,000 トランザクションあたり)

$0.01

(10,000 メッセージあたり)

課金可能な操作

すべて

送信/受信のみ

(他の操作には料金はかかりません)

アイドル状態のトランザクション

課金対象

(空のキューに対するクエリは課金可能なトランザクションと見なされます)

課金対象

(空のキューに対する受信は課金可能なメッセージと見なされます)

ストレージ コスト

$0.07

(GB/月あたり)

$0.00

送信データ転送のコスト

$0.12 - $0.19

(地理的条件による)

$0.12 - $0.19

(地理的条件による)

  • データ転送の料金は、特定の課金期間に データ センターからインターネット経由で送信されたデータの総量に基づいて決まります。

  • 同じ領域にある サービス間のデータ転送には料金はかかりません。

  • このドキュメントの作成時点では、受信データ転送には料金はかかりません。

  • Service Bus キューに対してメッセージング操作を実行するときの ACS トランザクションのコストはわずかです。Service Bus は、メッセージング ファクトリ オブジェクトのインスタンス 1 つにつき 1 つの ACS トークンを取得します。取得したトークンは、約 20 分後に有効期限が切れるまで再利用されます。したがって、Service Busのメッセージング操作の量と、それらの操作をサポートするために必要な ACS トランザクションの量は比例しません。

  • Service Bus キューでは長いポーリングがサポートされているため、待機時間の短い配信が必要な状況でこのキューを使用すると、コスト効率が向上する可能性があります。

noteメモ
すべてのコストは変更されることがあります。上記の表は、このドキュメントの作成時点の価格を反映しています。ここには、現在利用できるキャンペーン プランは含まれていません。最新の料金情報については、「価格の概要」を参照してください。

キューと Service Bus キューを使用する状況についての判断は、明らかにさまざまな要因に依存します。それらの要因がアプリケーションとそのアーキテクチャの個々のニーズに大きく依存している場合もあります。アプリケーションで既に のコア機能を使用している場合 (特に、サービス間の基本的な通信およびメッセージングや、80 GB を超えるサイズのキューが必要な場合) は、 キューを選択することができます。

Service Bus キューには高度な機能が数多く用意されているため (セッション、トランザクション、重複検出、自動的な配信不能レタリング、持続性のあるパブリッシュ/サブスクライブの機能など)、ハイブリッド アプリケーションを作成する場合や、アプリケーションでこれらの機能が必要な場合は、サービス バス キューを選択できます。

この記事では、まず規範的な推奨事項の概要を説明し、次に、現在 で提供されている各キュー テクノロジの機能を列挙して比較しました。機能が機能グループ別にまとめられているため、 キューとService Bus キューの共通点と相違点をひとめで把握できます。2 つのテクノロジをより深く理解することにより、使用するキュー テクノロジとその状況について、より多くの十分な情報を得たうえでの決定を行うことができます。

関連項目

表示:
© 2014 Microsoft