Windows Azure：キューとService Busキュー-類似点と相違点

この記事では、最新のWindows Azureプラットフォームで使用可能な2種類のキュー（Windows AzureキューとWindows Azureサービスバスキュー）の類似点と相違点を分析します。 この情報に基づいて、それぞれのテクノロジーの類似点と相違点を強調し、ニーズに最適なソリューションを選択できます。

はじめに

Windows Azureは、 Windows Azure キューとサービスバスキューの 2種類のキューメカニズムをサポートしています 。

Windows Azureストレージインフラストラクチャの一部であるWindows Azureキューは 、Get / Put / Peek機能を備えたシンプルなRESTインターフェイスをサポートし、サービス間およびサービス内で信頼性と復元力のあるメッセージングシステムを作成します。

Service Busキューは、より広範なWindows Azureメッセージングインフラストラクチャの一部であり、キューイング、発行、サブスクライブ、リモートWebサービス、および統合パターンをサポートします。

両方のキューテクノロジが並行して存在しますが、Windows Azureキューは以前に登場しました。 Windows Azureストレージサービス用のこのアドインは、キューを使用してデータウェアハウスを操作するための特別なメカニズムです。 サービスバスキューは、最新のサービスバスリリースで取り上げられています。 これらは、より広範な中間メッセージングインフラストラクチャへのアドオンです。 このインフラストラクチャは、複数の異なるメッセージングプロトコル、データコントラクト、信頼できるドメイン、およびネットワーク環境を使用できるアプリケーションまたはアプリケーションコンポーネントを統合するように設計されています。

この記事では、Windows Azureに実装されている2つのキューイングテクノロジーの比較分析を提供します。 両方のテクノロジーの動作モードと機能について説明します。 この記事では、アプリケーション開発に関連するタスクを解決するのに最適な機能を選択するための推奨事項も提供しています。

技術の選択

Windows AzureキューとService Busキューは、Windows Azureで現在利用可能なメッセージキューサービスの実装です。 これらのテクノロジーにはさまざまな機能セットがあります。 ニーズまたは解決する問題（技術的または商業的）に応じて、どちらかまたは両方を一度に選択できます。

特定のソリューションにキューイングテクノロジーを選択する場合、そのアーキテクトと開発者は次の推奨事項を考慮する必要があります。 詳細については、次のセクションを参照してください。

アーキテクトまたはソリューション開発者は 、次の場合にWindows Azureキューの使用を検討する必要があります。

• アプリケーションは、5 GBを超えるメッセージをキューに保存する必要があり、これらのメッセージの有効期間は7日間を超えません。
• アプリケーションには、メッセージ処理のための柔軟なレンタル機能が必要です。 これにより、非常に短いレンタル期間をメッセージに割り当てることができます。 その後、ワークフローに重大な障害が発生した場合、メッセージをすばやく再処理できます。 また、メッセージの処理に余分な時間がかかる場合、ワークフローでメッセージのリースを延長できます。 この機能は、非決定的なメッセージ処理時間に役立ちます。
• アプリケーションには、他のメッセージに添付されたメッセージの処理を追跡する機能が必要です。 これは、メッセージを処理するワークフローに重大な障害が発生した場合に役立ちます。 その後、次のワークフローはこの情報を使用して、前のワークフローを終了した場所からメッセージの処理を続行できます。
• サーバーのログは、キューで実行されるすべてのトランザクションに必要です。

アーキテクトまたはソリューション開発者は 、次の場合にWindows Azureサービスバスキューの使用を検討する必要があります。

• .NET Frameworkに実装されているWindows Communication Foundation（WCF）通信スタックとの完全な統合が必要です。
• 重複メッセージを自動的に検出するにはサポートが必要です。
• 関連するメッセージを個別の論理グループとして処理する機能が必要です。
• キューから複数のメッセージを送受信する場合、トランザクションとアトミック性のサポートが必要です。
• 特定のアプリケーションワークロードのライフタイム（有効期間、TTL）は、7日間を超えることがあります。
• アプリケーションは、長さが64 KBを超えるメッセージを処理しますが、ほとんどの場合、256 KBの制限に達しません。
• 先入れ先出し（FIFO）メッセージの配信を保証するキューサポートが必要です。
• キューをポーリングせずにメッセージを受信する機能が必要です。 サービスバスを使用する場合、このオプションは、ポーリング時間の長い取得操作によって提供されます。
• 役割ベースのアクセスモデルをキューに実装し、送信者と受信者にさまざまな権利と権限のサポートを提供する必要があります。
• 使用されるキューのサイズは5 GBを超えません。
• キューに基づくポイントツーポイント交換からメッセージングテンプレートの使用への移行の見通しがあります。 このテンプレートは、追加の受信者（サブスクライバー）の包括的な統合を提供します。各受信者は、キューに送信されたメッセージの一部またはすべての独立したコピーを受信します。 これは、サービスバスに統合されたパブリッシュおよびサブスクライブ機能のおかげで可能です。
• メッセージングソリューションは、追加のインフラストラクチャコンポーネントを必要とせずにAt-Most-Once配信保証をサポートする必要があります。
• メッセージパッケージを公開および処理する機能が必要です。

Windows AzureキューとService Busキューの比較

次のセクションの表には、論理的にグループ化されたキュー機能が含まれています。 これらの表は、Windows Azureキューとサービスバスキューの機能の違いを示しています。

基本機能

このセクションでは、Windows Azureキューとサービスバスキューのコア機能の比較分析を提供します。

比較基準	Windows Azureキュー	サービスバスキュー
注文保証	いや	はい-先入れ先出し（FIFO） （メッセージングセッションを使用）
配送保証	少なくとも1回（少なくとも1回）	少なくとも1回（少なくとも1回） 一度限り（最大1回）
トランザクションサポート	いや	はい （ローカルトランザクションを使用）
受け取る反応	ノンブロッキング （新しいメッセージが見つからない場合はすぐに終了します）	ブロッキング（待ち時間の有無にかかわらず） （長いポーリング間隔または長寿命のHTTP接続に基づくメソッドのサポート） ノンブロッキング （.NETプラットフォームで管理されるAPIのみを使用）
受信モード	読書とレンタル	読み取りとロック 受信して削除
排他的アクセスモード	レンタルベース	ロックベース
レンタル期間とブロック期間	30秒（デフォルト） 7日間（最大）	60秒（デフォルト） 5分（最大）
レンタル/ロックの詳細	メッセージレベル （各メッセージは独自のタイムアウト値を持つことができます）	キューレベル （各キューには独自のブロック単位があり、すべてのメッセージに対して有効であり、キューの存続期間全体にわたって固定されています）
バッチ領収書	はい （受信時のメッセージ数の明示的な表示、最大32メッセージ）	はい （プリフェッチを暗黙的に（パラメーターを使用して）または明示的に（トランザクションを使用して）有効にします）
バッチ送信	いや	はい （トランザクションまたはクライアントからのバッチ送信経由）

追加情報

• サービスバスキューで使用されるFIFO保証付き配信テンプレートを使用するには、メッセージングセッションを使用する必要があります。 ピーク＆ロックモードで受信したメッセージの処理中に重大なアプリケーションがクラッシュした場合、次のメッセージングセッションが開始されると、タイムアウト後にエラーメッセージが表示されます。
• サービスバスキューは、 最低1回の配信保証をサポートします。 さらに、 At-Most-Onceモードのセマンティクスは、アプリケーション状態が保存されるセッション状態、およびアトミックにメッセージを受信し、セッション状態を更新するトランザクションを通じてサポートされます。 Windows Azureワークフローサービスは、この手法を使用して、 At-Most-Onceモードで配信を保証します。
• サービスバスキューは、単一のキューのコンテキストでローカルトランザクションをサポートします。
• サービスバスでサポートされている受信および削除モードは、配信保証を減らし、制御メッセージの数を減らし、関連コストを削減します。
• Windows Azureキューは、メッセージのリースを延長するオプションを備えたリースをサポートしています。 これにより、ワークフローは短いメッセージのレンタル時間を提供できます。 このため、ワークフローに重大な障害が発生した場合、別のワークフローがメッセージをすばやく処理できます。 さらに、処理期間が現在のリース時間を超えた場合、ワークフローはメッセージのリースを延長できます。
• Windows Azureキューは、メッセージがキューに入れられたとき、またはキューから削除されたときに設定できる可視性タイムアウトをサポートします。 さらに、ランタイム環境で新しいリースパラメータ値を設定してメッセージを更新したり、同じキューのメッセージのさまざまなパラメータを更新したりできます。 対照的に、サービスバスはキューメタデータで指定された遅延パラメーターをブロックします。 これらの設定は、キューを再作成せずに変更できません。
• サービスバスで利用可能なブロッキング受信操作の最大待機時間は24日です。
• サービスバスによってサポートされるクライアント側のバッチ処理により、キュークライアントは単一の送信操作で複数のメッセージをバッチ処理できます。 バッチ処理は、非同期送信操作でのみ使用できます。

高度な機能

このセクションでは、Windows Azureキューとサービスバスキューの高度な機能の比較分析を提供します。

比較基準	Windows Azureキュー	サービスバスキュー
予定配送	はい	はい
削除されたメッセージの自動マーキング	いや	はい
遅延メッセージング	はい （可視性タイムアウトのインプレースリフレッシュを使用）	はい （専用のAPI関数を使用）
クラッシュレポートのサポート	はい	はい
一括アップグレード	はい	いや
サーバー側のトランザクションログ	はい	いや
ストレージメトリック	はい	いや
キュークリア機能	はい	いや
メッセージグループ	いや	はい （メッセージングセッションを使用）
重複メッセージの検出	いや	はい （送信側で構成可能）
WCF統合	いや	はい （定義済みのWCFバインディングが含まれます）
WF統合	個別設定 （カスタムWFアクションの作成が必要です）	自分の （既製のWFアクションを含む）

追加情報

• 2012年11月の時点で、Windows Azure SDKリリースに実装された両方のキュー処理テクノロジーにより、遅延メッセージ送信スケジュールを作成できます。
• Windows Azureキューは、メッセージコンテンツの更新を提供します。 この関数を使用すると、ステータス情報を保存し、その処理に関する情報をメッセージに追加して、メッセージを再起動する代わりに、最後の既知のチェックポイントからメッセージの処理を続行できます。
• 削除されたメッセージをマークするメカニズムは、サービスバスキューでのみサポートされます。 受信アプリケーションで正常に処理できなかったメッセージを分離するように設計されています。 このメカニズムは、メッセージの有効期間（TTL）が期限切れになり、メッセージが受信者に届かない場合にも使用されます。 TTL値は、メッセージがキューに残る期間を決定します。 サービスバスを使用する場合、メッセージは、有効期限が切れると$ DeadLetterQueueという特別なキューに移動されます。
• Windows Azureキューのエラーメッセージを検出するために、メッセージがキューから削除されると、アプリケーションはこのメッセージのDequeueCountプロパティを分析します。 DequeueCountが指定されたしきい値より大きい場合、アプリケーションは削除のためにメッセージをメッセージキューに移動します。
• Windows Azureキューを使用すると、すべてのキュー関連のトランザクションの詳細なログと、集計されたメトリックログを保持できます。 これらのログは、Windows Azureキューのアプリケーション使用のデバッグと分析を目的としています。 また、アプリケーションのパフォーマンスを最適化し、キューを使用するコストを削減するのにも役立ちます。
• サービスバスがサポートする「メッセージセッション」メカニズムにより、特定の論理グループに属するメッセージを特定の受信者に関連付けることができます。 次に、これにより、メッセージと受信者の間の接続が作成されます。これは、そのプロパティがセッションに似ています。 この高度なサービスバス機能を有効にするには、メッセージのSessionIDプロパティを設定します。 特定のセッション識別子の送信を待っている受信者は、その識別子を持つメッセージを受信する場合があります。
• 重複メッセージの検出は、サービスバスでサポートされています。 この関数はMessageIDプロパティを使用し、キューまたはトピックに送信された重複メッセージを自動的に削除します。

容量とクォータ

このセクションでは、Windows Azureキューとサービスバスキューの容量と現在のクォータに関する比較分析を提供します。

比較基準	Windows Azureキュー	サービスバスキュー
最大メッセージサイズ	64 kb （ Base64エンコードを使用する場合は48K）	256 kb （メッセージのタイトルと本文を含む、最大ヘッダーサイズ64 KB）
最大キューサイズ	100 TB （1つのストレージアカウントに制限）	1、2、3、4、または5 GB （キュー作成時に定義）
最大メッセージ有効期間	7日間	制限なし
キューの最大数	制限なし	10,000 （1つのサービス名前空間について、増加する場合があります）
同時クライアントの最大数	制限なし	制限なし （100の同時接続の制限は、TCPを介したデータ交換にのみ適用されます）

追加情報

• Windows Azureキューでは、コンテンツがXMLセーフでない場合、 Base64でエンコードされたメッセージを使用する必要があります。 Base64メッセージの場合、ユーザーペイロードを64 KBから48 KBに減らすことができます。
• サービスバスキューを使用する場合、キューに保存される各メッセージは、ヘッダーとテキストフィールドの2つの部分で構成されます。 合計メッセージ長は256 KBを超えることはできません。
• サービスバスキューとTCPプロトコルを使用してクライアント間でデータを交換する場合、1つのサービスバスキューへの最大100の同時接続を作成できます。 この数量は、送信者と受信者の合計です。 クォータを超過した場合、追加の接続に対する後続の要求は拒否されます。 呼び出しコードとともに例外がスローされます。 このクォータは、RESTベースのAPIを使用してキューに接続するクライアントには適用されません。
• 最大キューサイズは、サービスバスによって強制的に設定されます。 キューの最大サイズは、キューの作成時に指定され、1、2、3、4、または5 GBに設定できます。 最大キューサイズを超えると、以降のすべての着信メッセージは、コールコードによる例外で拒否されます。 サービスバスクォータの詳細については、 Windows Azureサービスバスクォータのドキュメントを参照してください。
• サービスバスに関連付けられた同じサービス名前空間で10,000を超えるキューが必要な場合は、Windows Azureサポートグループに連絡して、この値を増やすよう依頼することができます。 ソリューションを拡張し、10,000を超えるサービスバスキューを使用する必要がある場合は、Windows Azure管理ポータルを使用して追加のサービス名前空間を作成できます。

管理と運用

このセクションでは、Windows Azureのキュー管理機能とサービスバスキューの比較分析を提供します。

比較基準	Windows Azureキュー	サービスバスキュー
制御プロトコル	REST over HTTP / HTTPS	HTTPS経由のREST
ランタイムプロトコル	REST over HTTP / HTTPS	HTTPS経由のREST TLSサポート付きTCP
.NET API	はい （.NETボールトクライアントAPI）	はい （.NET中間メッセージングAPI）
Java API	はい	はい
PHP API	はい	はい
Node.js API	はい	いや
カスタムメタデータのサポート	はい	いや
キューの命名規則	63文字までの長さ （キュー名には小文字のみを使用する必要があります）	260文字までの長さ （キュー名は大文字と小文字が区別されません）
キュー長関数	はい （おおよその値）	はい （特定の時点の正確な値）
読み取り機能	はい	いや

追加情報

• Windows Azureキューは、キューの説明で使用できるカスタム属性をサポートしています。 各属性は名前と値のペアです。
• Windows Azureキューでは、メッセージを最初にブロックせずに読み取ることもできます。 この機能は、キューを表示するためのソフトウェアツールを開発するときに使用されます。
• .NETプラットフォームを使用してサービスバスに実装された中間メッセージングAPIは、全二重TCP接続を使用します。これにより、REST over HTTPを使用する場合と比較してパフォーマンスが向上します。
• Windows Azureキューは、キュー名に特定の制限を課します。 詳細については、「 ネーミングキューとメタデータ 」の記事をご覧ください。
• サービスバスキュー名は260文字を超えることはできません。 これらのキューの命名規則はそれほど厳しくありません。 サービスバスのキュー名には、文字、数字、ピリオド（。）、ダッシュ（-）、およびアンダースコア（_）のみを含めることができます。

性能

このセクションでは、パフォーマンスに関するWindows Azureキューとサービスバスキューの比較分析を提供します。

比較基準	Windows Azureキュー	サービスバスキュー
最大スループット	1秒あたり最大2000メッセージ	1秒あたり最大2000メッセージ （1 KBメッセージを使用したパフォーマンステストに基づく）
平均遅延時間	10ミリ秒 （ TCP Nagleが無効の場合）	100ミリ秒
リクエスト調整モード	HTTP 503エラーコードによる拒否のリクエスト （リクエスト数を規制するモードで受信したリクエストは課金されません）	例外とHTTP 503エラーコードでリクエストを拒否する （リクエスト数を規制するモードで受信したリクエストは課金されません）

追加情報

• 単一のWindows Azureキューは、1秒あたり最大2000件のトランザクションを処理できます。 トランザクションは、 Put 、 Get、またはDeleteのいずれかの操作です。 単一のメッセージ（ Put ）をキューに送信することは単一のトランザクションと見なされますが、メッセージの受信は多くの場合、メッセージの受信（ Get ）とそれに続くキューからの削除要求（ Delete ）を含む2段階のプロセスです。 したがって、キューからの正常な削除操作は通常、2つのトランザクションで構成されます。
• アプリケーションがWindows Azureキューの最大スループットに達すると、キューサービスは通常、HTTP 503サーバービジー応答を返します。 この場合、アプリケーションは、遅延時間の指数関数的な増加を伴う再送信ロジックを使用する必要があります。
• 地理的な場所（サブリージョン）がストレージアカウントの場所と一致するホストされたサービスを使用して小さなメッセージ（10 KB未満）を処理する場合、Windows Azureキューの待ち時間は平均10ミリ秒です。
• Windows Azureキューとサービスバスキューは、リクエスト調整モードを使用できます。 この場合、このモードが有効なキューへの要求は拒否されます。 さらに、リクエスト数を規制するモードで受信したリクエストは課金されません。
• サービスバスキューのパフォーマンステストでは、1つのキューが約1 KBのメッセージサイズで最大2000メッセージ/秒のメッセージ処理速度を提供することが示されました。 より高い処理速度を確保するには、複数のキューを使用する必要があります。 サービスバス使用時のパフォーマンスの最適化の詳細については、「サービスバスブローカリングメッセージングを使用したパフォーマンス改善のベストプラクティス」を参照してください 。
• サービスバスキューの最大帯域幅を超えると、 ServerBusyException （.NET中間メッセージングAPIを使用する場合）またはHTTP 503応答（RESTベースのAPIを使用する場合）がキュークライアントに返されます。 これは、キューが調整モードに入ったことを示します。

認証と承認

このセクションでは、Windows Azureキューおよびサービスバスキューの認証および承認機能の比較分析を提供します。

比較基準	Windows Azureキュー	サービスバスキュー
認証	対称キー	ACSアプリケーション
役割ベースのアクセス制御	いや	はい （ACSロールを使用）
IDプロバイダーのフェデレーション	いや	はい

追加情報

• どのキュー技術が使用されていても、各要求には認証が必要です。 パブリックキューへの匿名アクセスはサポートされていません。
• Windows Azureキューに実装されている認証スキームには、 Base64エンコードSHA-256アルゴリズムを使用して計算されたハッシュベースのメッセージ認証コード（HMAC）である対称キーの使用が含まれます。 プロトコルの詳細については、 ストレージアカウントへのアクセスの認証を参照してください。
• サービスバスでサポートされているWindows Azureアクセス制御（ACS）アクセス制御サービスには、Windows Azureキューでは現在サポートされていないAdmin 、 Sender 、およびReceiverの 3つの異なる役割があります。
• サービスバスはACS統合をサポートしているため、Active Directory（ADFSを使用）およびLive ID、Google、Facebook、Yahooなどのインターネットで頻繁に使用されるIDプロバイダーと組み合わせることができます。

費用

このセクションでは、Windows Azureキューとサービスバスキューの使用コストの比較分析を提供します。

比較基準	Windows Azureキュー	サービスバスキュー
キューのトランザクションコスト	0.01ドル （10,000トランザクションの場合）	0.01ドル （10,000件の投稿の場合）
関税オペレーション	全部	送受信のみ （他の操作に手数料はかかりません）
ワークロードのないトランザクション	充電されます （空のキューへのリクエストは有料のトランザクションと見なされます）	充電されます （空のキューからメッセージを受信すると課金されます）
データストレージコスト	0.14ドル （毎月GBあたり）	0.00ドル
アウトバウンドコスト	0.12〜0.19ドル （地理的位置による）	0.12〜0.19ドル （地理的位置による）
Windows Azureアクセス制御（ACS）を使用したトランザクションコスト	0.00ドル （ACSは使用されません）	1.99ドル （トークンリクエスト10,000件につき、以下のコメントを参照）

追加情報

• データ転送は、特定の課金期間中にインターネット経由でWindows Azureデータセンターから転送されたデータの合計量に基づいて課金されます。
• 同じサブリージョンにあるWindows Azureサーバー間のデータ転送は無料です。
• この記事の執筆時点では、着信データに料金はかかりません。
• サービスバスキューを使用したメッセージング操作の場合、ACSトランザクションのコストは考慮されない場合があります。 サービスバスは、メッセージ処理ファクトリオブジェクトの個々のインスタンスごとに1つのACSトークンを受け取ります。 このトークンは、有効期限（約20分）まで再利用されます。 したがって、サービスバスでのメッセージング操作の量は、これらの操作をサポートするために必要なACSトランザクションの量に直接比例しません。
• 長いポーリング間隔を使用する場合、低コストでサービスバスキューを使用して、低遅延でメッセージ配信を必要とするタスクを解決できます。

ご注意 すべての値は変更される可能性があります。 上記の表は、この記事の執筆時点での価格を反映しています。 この記事には、読む時点で利用可能なプロモーションは含まれていません。 最新の価格情報は、 価格の概要ページで提供されます。

おわりに

明らかに、Windows Azureキューまたはサービスバスキューを使用するかどうかは、多数の要因に依存します。 これらの要因は、アプリケーションとそのアーキテクチャの特定の要件に依存します。 アプリケーションが既にWindows Azureのコア機能を使用している場合は、Windows Azureキューを選択できます。 これは、サービス間でデータとメッセージを交換するための基本的な機能が必要な場合、または5 GBを超えるキューが必要な場合に特に当てはまります。

サービスバスキューには、セッション、トランザクション、再試行の検出、削除キューへの自動移動、フォールトトレラントパブリッシングおよびサブスクライブツールなど、多くの高度な機能があります。 ハイブリッドアプリケーションを作成している場合、またはアプリケーションが機能するために上記の機能が必要な場合は、このソリューションを選択できます。

この記事は、ガイドラインと推奨事項の概要から始まります。 次に、Windows Azureで利用可能なキューイングテクノロジーの機能について説明します。 機能を機能別にグループ化すると、視覚的な比較分析を実行して、Windows Azureキューとサービスバスキューの類似点と相違点を特定できます。

これらの問題の詳細な調査は、特定の問題を解決するのに最適なキューイングテクノロジーを選択するのに役立ちます。

こちらもご覧ください

Windows Azure Service Bus Brokered Messaging APIを活用するためのベストプラクティス

Service Busブローカリングメッセージング（Service Busの中間メッセージングシステム）を使用したパフォーマンス改善のベストプラクティス

Service Busキューの使用方法

キューストレージサービスの使用方法

Azure Service Busのキューとトピックの紹介（Azure Service Busに実装されたキューとトピックの紹介）

サービスバス開発者ガイド

Windows Azureのテーブルとキューの詳細（Windows Azureのテーブルとキュー-詳細）

Windows Azureストレージアーキテクチャ

Windows Azureでキューサービスを使用する

Windows Azureストレージの課金について-帯域幅、トランザクション、および容量（Windows Azureストレージの課金システム-帯域幅、トランザクション、および容量）