次の方法で共有

Azure Service Bus - メッセージの有効期限 (Time to Live)

  • [アーティクル]

メッセージが受信者に伝えるメッセージ、コマンド、または問い合わせの中のペイロードには、ほとんどの場合、何らかの形式のアプリケーション レベルの有効期限が適用されます。 有効期限が切れると、コンテンツの配信は停止され、要求された操作は実行されなくなります。

キューおよびトピックがアプリケーションの部分的実行、またはアプリケーションの一部の実行の文脈で使用されることが多い開発およびテスト環境では、次のテストを何もない状態で開始できるよう、保留中のテスト メッセージをガベージ コレクションで自動的に回収する必要もあります。

Note

Service Bus の概念をまだ理解していない場合は、Service Bus の概念に関する記事と「Service Bus のキュー、トピック、サブスクリプション」を参照してください。

各メッセージの有効期限は、相対的な期間を指定する、time-to-live システム プロパティを設定することで制御できます。 メッセージがエンティティにエンキューされると、有効期限は、絶対瞬間になります。 その時点で、expires-at-utc プロパティに enqueued-time-utc + time-to-live の値が設定されます。 ブローカー メッセージの有効期限 (TTL) 設定は、アクティブにリッスンしているクライアントが存在しない場合は適用されません。

expires-at-utc の瞬間を過ぎると、メッセージは取得できなくなります。 有効期限は、現在配信のためにロックされているメッセージには影響しません。 これらのメッセージは、引き続き正常に処理されます。 ロックの有効期限が切れた、またはメッセージが破棄されると、有効期限切れは直ちに有効になります。 メッセージがロックされている状態では、有効期限が切れたメッセージをアプリケーションが所有している可能性があります。 アプリケーションがメッセージの処理を進めるか、メッセージを破棄するかは、実装によって異なります。

ミリ秒や秒オーダーの非常に低い TTL は、メッセージが受信側アプリケーションで受信される前に有効期限が切れる原因となる場合があります。 アプリケーションに対して機能する最大の TTL を考慮してください。

Note

スケジュール設定されたメッセージについては、メッセージを取得用キューに具体化するエンキュー時刻を指定します。 メッセージが Service Bus に送信される時刻は、メッセージがエンキューされる時刻とは異なります。 メッセージの有効期限は、メッセージが Service Bus に送信される時刻ではなく、エンキューされた時刻によって決まります。 したがって、expires-at-utc は引き続きエンキューされた時刻 + time-to-live になります。

たとえば、ScheduledEnqueueTimeUtc を UtcNow から 5 分、TimeToLive を 10 分に設定した場合、メッセージは今から 5 + 10 = 15 分後に期限切れになります。 メッセージは 5 分後にキューに具体化され、そこから 10 分のカウンターが始まります。

エンティティ レベルの有効期限

キューまたはトピックに送信されたすべてのメッセージには、エンティティ レベルで設定されている既定の有効期限が適用されます。 これは、作成時にポータルで設定し、後で調整することもできます。 既定の有効期限は、time-to-live が明示的に設定されていないエンティティに送信されるすべてのメッセージに使用されます。 既定の有効期限は、time-to-live 値の上限としても機能します。 time-to-live 有効期限が既定値より長いメッセージは、エンキューされる前に既定のメッセージの time-to-live 値に自動的に調整されます。

Note

  • ブローカー メッセージの既定の time-to-live 値は、特に指定されていない場合は、符号付き 64 ビット整数の可能な最大値です。
  • メッセージング エンティティ (キューおよびトピック) の既定の有効期限も、Service Bus の Standard と Premium の各レベルでは符号付き 64 ビット整数の可能な最大値です。 Basic レベルでは、既定 (かつ最長) の有効期限は 14 日間です。
  • トピックでサブスクリプションよりも短い TTL が指定されている場合、トピックの TTL が適用されます。

有効期限切れのメッセージは、必要に応じて配信不能キューに移動できます。 この設定は、プログラムによって、または Azure portal を使用して構成できます。 オプションを無効のままにすると、期限切れのメッセージは削除されます。 配信不能キューに移動された期限切れのメッセージは、ユーザー プロパティ セクションにブローカーが保存する dead-letter reason プロパティを評価することで、他の配信不能メッセージと区別できます。

ロック中のメッセージは有効期限が切れず、フラグがエンティティに設定されている場合は、ロックが破棄された時点で、または有効期限が切れるとメッセージは配信不能キューに移動されます。 ただし、メッセージが正常に到着した場合は移動されません。この場合、有効期限が切れたとされたにもかかわらず、アプリケーションによって正常に処理されたと推測できます。 メッセージ ロックと解決の詳細については、「メッセージの転送、ロック、および解決」を参照してください。

time-to-live と期限切れ時に配信不能キューに自動的 (トランザクションとして) に移動される機能を組み合わせることで、ハンドラーまたはハンドラーのグループに渡された期限付きのジョブを、期限が来たときに確実に取得し処理できます。

たとえば、規模が制限されたバックエンドでジョブを確実に実行する必要がある Web サイトがあるとします。ここで、トラフィックの急増が随時発生する、またバックエンドの可用性を隔離する必要があるとします。 通常の場合、送信されたユーザー データのためのサーバー側のハンドラーが、情報をキューにプッシュし、その後、処理の完了を確認する返信を返信キューで受け取ります。 トラフィックのスパイクがあり、バックエンド ハンドラーが期限までにバックログ アイテムを処理できない場合、期限切れのジョブは配信不能キューに返されます。 要求した操作に通常より少し時間がかかることを対話ユーザーに通知し、その要求を処理パス用の異なるキューに入れて、最終的な処理結果をメールでユーザーに送信できます。

一時エンティティ

Service Bus のキュー、トピック、およびサブスクリプションは、指定した期間使用されていない場合は自動的に削除される、一時エンティティとして作成できます。

自動クリーンアップは、エンティティが動的に作成され、テストまたはデバッグの実行が中断されたことにより、使用後にクリーンアップされない、開発およびテストのシナリオで役立ちます。 また、アプリケーションが、応答キューなどの動的エンティティを作成し、Web サーバー プロセス、または比較的寿命の短い他のオブジェクトに応答を戻し、オブジェクト インスタンスが消去されたときに確実にこれらのエンティティをクリーン アップすることが困難な場合でも有用です。

この機能は、名前空間の auto delete on idle プロパティを使用して有効にします。 このプロパティは、このプロパティはエンティティがアイドル状態 (未使用) であり続けると自動的に削除される期間を設定します。 このプロパティの最小値は 5 分です。

重要

名前空間または上位レベルで Azure Resource Manager のロックレベルを CanNotDelete に設定しても、AutoDeleteOnIdle を持つエンティティは削除されません。 エンティティを削除しない場合は、AutoDeleteOnIdle プロパティを DataTime.MaxValue に設定します 。

アイドル

エンティティ (キュー、トピック、およびサブスクリプション) のアイドルとみなされるものを次に示します。

Entity アイドル状態と見なされるもの
キュー
  • 送信なし
  • 受信なし
  • キューに対する更新なし
  • スケジュール設定されたメッセージなし
  • 閲覧/ピークなし
トピック
  • 送信なし
  • トピックに対する更新なし
  • スケジュール設定されたメッセージなし
  • トピックのサブスクリプションに対する操作なし (次の行を参照してください)
サブスクリプション
  • 受信なし
  • サブスクリプションに対する更新なし
  • サブスクリプションに新しいルールは追加されない
  • 閲覧/ピークなし

重要

キューまたはサブスクリプションに自動転送を設定している場合、受信側にキューまたはサブスクリプションで受信を実行させることになるため、これらはアイドル状態になりません。

SDK

次のステップ

Service Bus メッセージングの詳細については、次の記事をご覧ください。