メッセージ キュー ソリューションを選択する
Storage キューと Service Bus キューの機能セットは、多少異なります。 ご自身の特定のソリューションのニーズに応じて、どちらか一方を選択することも、両方を選択することもできます。
特定のソリューションの目的に合うキュー テクノロジを判断する際、ソリューション設計者および開発者はこれらの推奨事項を検討する必要があります。
Service Bus キューの使用を検討する
ソリューション設計者または開発者として、次の場合に Service Bus キューの使用を検討してください。
- ソリューションで、キューをポーリングせずにメッセージを受信できる必要がある場合。 Service Bus では、Service Bus がサポートする TCP ベースのプロトコルを使用し、長いポーリングの受信操作を使用することによってこれを実現できます。
- キューによるメッセージの配信が先入れ先出し (FIFO) の順序で行われることが保証される必要がある場合。
- ソリューションで、自動重複検出をサポートする必要がある場合。
- アプリケーションでメッセージを実行時間の長い並列ストリームとして処理する必要がある場合 (メッセージは、それ自体の [セッション ID] プロパティを使用してストリームに関連付けられます)。 このモデルでは、処理を行うアプリケーションの各ノードは、メッセージではなくストリームに対して競合します。 処理を行うノードにストリームが渡されると、そのノードはトランザクションを使用してアプリケーション ストリームの状態を確認できます。
- 複数のメッセージをキューに送信したりキューから受信したりする際にトランザクション動作と原子性が必要な場合。
- アプリケーションで処理するメッセージのサイズが 64 KB を超えることはあっても、選択されているサービス レベルに応じて 256 KB または 1 MB の制限に達することはないと考えられる場合 (ただし、Service Bus キューは最大 100 MB のメッセージを処理できます)。
- ロールベースのアクセス モデルを提供して、キューの送信側と受信側に異なる権限/アクセス許可を与える必要がある場合。
Storage キューの使用を検討する
ソリューション設計者または開発者として、次の場合に Storage キューの使用を検討してください。
- アプリケーションは 80 ギガバイトを超えるメッセージをキューに格納する必要がある場合。
- アプリケーションでキュー内のメッセージ処理の進行状況を追跡したい場合。 これは、メッセージを処理しているワーカーがクラッシュした場合に役に立ちます。 別のワーカーでその情報を使用して、前のワーカーが中断した時点から処理を再開できます。
- キューに対して実行されたすべてのトランザクションのサーバー側のログが必要な場合。