Azure Service Bus メッセージのプリフェッチ

  • [アーティクル]

公式の Service Bus クライアントのいずれかに対して "プリフェッチ" 機能を有効にすると、受信側は、アプリケーションが最初に要求したものよりも多くのメッセージを取得します (最大で指定したプリフェッチ数)。 メッセージがアプリケーションに返されると、クライアントはさらにメッセージをバックグラウンドで取得し、プリフェッチ バッファーに格納します。

プリフェッチを有効にする

プリフェッチ機能を有効にするには、キューまたはサブスクリプション クライアントのプリフェッチ数を 0 より大きい数値に設定します。 値を 0 に設定すると、プリフェッチが解除されます。

ServiceBusReceiver および ServiceBusProcessor のオブジェクトでプリフェッチ数プロパティを設定します。

注意

JavaScript SDK は、プリフェッチ機能をサポートしていません。

メッセージがプリフェッチ バッファーに格納されると、後続の受信呼び出しは、バッファーから直ちに実行されます。 領域が使用可能になると、バッファーがバックグラウンドで補充されます。 配信するメッセージがない場合は、受信操作によってバッファーが空になり、想定どおり、ブロックを待機します。

プリフェッチが既定のオプションではない理由

プリフェッチを使用すると、アプリケーションが要求する前にメッセージをローカルで取得できるよう用意することで、メッセージ フローを高速化できます。 このスループットの向上は、メリットとデメリットを比較したうえで、アプリケーションの作成者がその使用を明示的に決定した結果として得られるものです。

receive-and-delete モードでは、プリフェッチ バッファーに取得されたすべてのメッセージはキューで使用できなくなります。 メッセージは、アプリケーションに受信されるまで、メモリ内のプリフェッチ バッファーにのみ存在します。 アプリケーションがメッセージを受信する前に終了すると、それらのメッセージは失われ、復元できなくなります。

peek lock 受信モードでは、プリフェッチ バッファーにフェッチされたメッセージが、ロック状態のバッファーに取得されます。 ロックの有効期限のためにタイムアウト クロックが設定されます。 プリフェッチ バッファーのサイズが大きく、処理に時間がかかり、その結果、メッセージがプリフェッチ バッファー内にある間、あるいはアプリケーションがメッセージを処理している間にメッセージのロックの有効期限が切れると、アプリケーションでの処理において混乱を招くイベントが発生する場合があります。 アプリケーションは、期限が切れた、またはロックの有効期限がもうすぐ切れるメッセージを取得する場合があります。 この場合、アプリケーションはメッセージを処理することもありますが、ロックの有効期限のためにメッセージを完了できないことを検出します。 アプリケーションは LockedUntilUtc プロパティ (ブローカーとローカル コンピューターのクロックのずれによって規定されます) をチェックします。

メッセージのロックの有効期限が切れている場合、アプリケーションではメッセージを無視する必要があり、メッセージに対して API 呼び出しを行わないようにする必要があります。 メッセージの有効期限が切れていない一方で有効期限が近づいている場合、ロックを更新して、別の既定のロック期間まで延長できます。 プリフェッチ バッファーでロックの有効期限が自動的に切れると、メッセージは破棄済みとして扱われ、もう一度キューから取得できるようになります。 それにより、メッセージはプリフェッチ バッファーにフェッチされ、末尾に配置される場合があります。 メッセージの有効期限中、プリフェッチ バッファーが通常通り処理されない場合は、メッセージのプリフェッチが繰り返されますが、メッセージは使用可能な (ロックが有効) 状態で効果的に配信されることはなく、最終的には、最大配信回数を超えて配信不能キューに入れられます。

アプリケーションがメッセージを明示的に破棄した場合、メッセージをキューから再度取得できる可能性があります。 プリフェッチが有効になると、メッセージは再びプリフェッチ バッファーにフェッチされ、最後に配置されます。 プリフェッチ バッファーからのメッセージが先入れ先出し (FIFO) の順序でドレインされるため、アプリケーションはメッセージを順不同で受信する場合があります。 たとえば、アプリケーションはバッファーから ID 2 のメッセージを受信してから、(以前に破棄された) ID 1 のメッセージを受信する場合があります。

メッセージの処理に高い信頼性が必要で、処理にかなりの作業量と時間が必要な場合、プリフェッチ機能をまったく使用しないか、慎重に使用することをお勧めします。 高いスループットを必要としており、メッセージ処理が一般に安価である場合は、プリフェッチによって大きなスループットの利点がもたらされます。

最大プリフェッチ数とキューまたはサブスクリプションに構成されているロック期間は、ロックのタイムアウトが、プリフェッチ バッファーの最大サイズに 1 メッセージ分を足した累計予想メッセージ処理時間以上になるようにバランスを調整する必要があります。 同時に、ロック タイムアウトは、メッセージの最大存続時間を超えるような長さにしてはなりません。これは、メッセージが誤って破棄された場合、再配信前にロックの有効期限が切れるようにする必要があるためです。

次のステップ

Azure Service Bus の機能については、使用する言語のサンプルを試してみてください。

以前の .NET および Java クライアント ライブラリのサンプルは次のとおりです。

2026 年 9 月 30 日に、Azure SDK ガイドラインに準拠していない Azure Service Bus SDK ライブラリ WindowsAzure.ServiceBus、Microsoft.Azure.ServiceBus、および com.microsoft.azure.servicebus は廃止される予定です。 SBMP プロトコルのサポートも終了するため、2026 年 9 月 30 日以降、このプロトコルを使用できなくなります。 この日付より前に、重要なセキュリティ更新プログラムと強化された機能が提供される、最新の Azure SDK ライブラリに移行してください。

以前のライブラリは 2026 年 9 月 30 日以降も引き続き使用できますが、Microsoft から公式のサポートと更新プログラムは提供されなくなります。 詳細については、サポート廃止のお知らせに関するページを参照してください。