メッセージ セッションMessage sessions

Microsoft Azure Service Bus セッションでは、関連メッセージのバインドなしシーケンスの結合および順序指定処理が可能です。Microsoft Azure Service Bus sessions enable joint and ordered handling of unbounded sequences of related messages. セッションは、先入れ先出し (FIFO) および 要求 - 応答 のパターンで使用できます。Sessions can be used in first in, first out (FIFO) and request-response patterns. この記事では、Service Bus の使用時に、セッションを使用してこれらのパターンを実装する方法について説明します。This article shows how to use sessions to implement these patterns when using Service Bus.

注意

Service Bus の Basic レベルはセッションをサポートしていません。The basic tier of Service Bus doesn't support sessions. Standard レベルと Premium レベルはセッションをサポートしています。The standard and premium tiers support sessions. これらのレベルの違いについては、「Service Bus の価格」を参照してください。For differences between these tiers, see Service Bus pricing.

先入れ先出し (FIFO) パターンFirst-in, first out (FIFO) pattern

Service Bus で FIFO 処理を保証するには、セッションを使用します。To realize a FIFO guarantee in Service Bus, use sessions. Service Bus では、メッセージ間の関係の性質に関する規範はなく、またメッセージのシーケンスの開始または終了位置を決定する特定のモデルは定義されていません。Service Bus isn't prescriptive about the nature of the relationship between the messages, and also doesn't define a particular model for determining where a message sequence starts or ends.

セッションに固有のアプリケーション定義の識別子に セッション ID のプロパティを設定することで、センダーはメッセージをトピックまたはキューに送信するときにセッションを作成できます。Any sender can create a session when submitting messages into a topic or queue by setting the session ID property to some application-defined identifier that is unique to the session. AMQP 1.0 プロトコル レベルでは、この値は group-id プロパティに相当します。At the AMQP 1.0 protocol level, this value maps to the group-id property.

セッション対応のキューまたはサブスクリプションでは、セッション ID を持つメッセージが 1 つ以上ある場合にセッションが生成されます。On session-aware queues or subscriptions, sessions come into existence when there's at least one message with the session ID. 1 度生成されたセッションの有効期限や存続期間、および API は定義されていません。Once a session exists, there's no defined time or API for when the session expires or disappears. 理論上は、メッセージを今日のセッションで受信して、次のメッセージを 1 年後に受信したとしても、セッション ID が一致する限り、Service Bus の観点からすると同じセッションになります。Theoretically, a message can be received for a session today, the next message in a year's time, and if the session ID matches, the session is the same from the Service Bus perspective.

通常、アプリケーションでは関連するメッセージの開始および終了は明確に認識されます。Typically, however, an application has a clear notion of where a set of related messages starts and ends. Service Bus では、特定の規則は設定されていません。Service Bus doesn't set any specific rules. たとえば、アプリケーションでは、最初のメッセージの Label プロパティを start に、中間メッセージの場合であれば content に、最後のメッセージであれば end に設定できます。For example, your application could set the Label property for the first message to start, for intermediate messages to content, and for the last message to end. コンテンツ メッセージの相対位置は、現在のメッセージの SequenceNumberstart メッセージの SequenceNumber との差分として計算できます。The relative position of the content messages can be computed as the current message SequenceNumber delta from the start message SequenceNumber.

この機能は、Azure Resource Manager からキューやサブスクリプションの requiresSession プロパティを設定するか、ポータルでフラグを設定することによって有効化できます。You enable the feature by setting the requiresSession property on the queue or subscription via Azure Resource Manager, or by setting the flag in the portal. これは、関連する API 操作を使用する前に必要です。It's required before you attempt to use the related API operations.

ポータルでは、次の例に示すように、エンティティ (キューまたはサブスクリプション) の作成中にセッションを有効にすることができます。In the portal, you can enable sessions while creating an entity (queue or subscription) as shown in the following examples.

キューの作成時にセッションを有効にする

サブスクリプションの作成時にセッションを有効にする

重要

キューまたはサブスクリプションでセッションが有効になっている場合、クライアント アプリケーションでは通常のメッセージを送受信 できなくなりますWhen Sessions are enabled on a queue or a subscription, the client applications can no longer send/receive regular messages. すべてのメッセージは、(セッション ID を設定して) セッションの一部として送信し、セッションを受信することで受信する必要があります。All messages must be sent as part of a session (by setting the session id) and received by accepting the session.

セッションに対応する API は、キューまたはサブスクリプション クライアントに存在します。The APIs for sessions exist on queue and subscription clients. セッションやメッセージの受信タイミングを制御する命令モデルと、受信ループ管理の複雑さを隠すハンドラー ベースのモデルがあります。There's an imperative model that controls when sessions and messages are received, and a handler-based model that hides the complexity of managing the receive loop.

サンプルについては、「次のステップ」セクションにあるリンクを使用してください。For samples, use links in the Next steps section.

セッションの機能Session features

セッションは、順序指定の送信を維持し保証しながら、インターリーブされたメッセージ ストリームの同時逆多重化を提供します。Sessions provide concurrent de-multiplexing of interleaved message streams while preserving and guaranteeing ordered delivery.

セッション機能で順序指定の送信が維持される方法を示す図。

セッション受信プロセスは、セッションを受け入れるクライアントによって作成されます。A session receiver is created by a client accepting a session. セッションがクライアントによって受け入れられて保持されると、クライアントではキューまたはサブスクリプションでそのセッションの セッション ID を持つすべてのメッセージに対する排他ロックが保持されます。When the session is accepted and held by a client, the client holds an exclusive lock on all messages with that session's session ID in the queue or subscription. また、後で到着する セッション ID を持つすべてのメッセージに対しても排他ロックが保持されます。It will also hold exclusive locks on all messages with the session ID that will arrive later.

このロックは、受信側で close 関連のメソッドを呼び出した場合、またはロックの有効期限が切れた場合に解放されます。The lock is released when you call the close related methods on the receiver or when the lock expires. 受信側には、ロックを更新するためのメソッドもあります。There are methods on the receiver to renew the locks as well. その代わりに、ロックの更新を続ける期間を指定できる、ロックの自動更新機能を使用できます。Instead, you can use the automatic lock renewal feature where you can specify the time duration for which you want to keep getting the lock renewed. セッション ロックは、ファイルの排他的ロックと同様に処理する必要があります。つまり、アプリケーションは、セッションが不要になったり、それ以上のメッセージが想定されなくなったりしたらただちにセッションを閉じる必要があります。The session lock should be treated like an exclusive lock on a file, meaning that the application should close the session as soon as it no longer needs it and/or doesn't expect any further messages.

複数の同時受信プロセスがキューからプルする場合、特定のセッションに属するメッセージは、そのセッションに対するロックを現在保持している特定の受信プロセスに送信されます。When multiple concurrent receivers pull from the queue, the messages belonging to a particular session are dispatched to the specific receiver that currently holds the lock for that session. この操作により、1 つのキューまたはサブスクリプション内のインターリーブされたメッセージ ストリームはさまざまな受信プロセスに対してクリーンに逆多重化されます。また、ロック管理が Service Bus 内のサーバー側で行われるため、それらの受信プロセスはさまざまなクライアント マシン上に存続できます。With that operation, an interleaved message stream in one queue or subscription is cleanly de-multiplexed to different receivers and those receivers can also live on different client machines, since the lock management happens service-side, inside Service Bus.

上の図には、3 つの同時セッション受信プロセスが示されています。The previous illustration shows three concurrent session receivers. SessionId = 4 の 1 つのセッションには有効な所有クライアントがなく、メッセージはこの特定のセッションから配信されません。One Session with SessionId = 4 has no active, owning client, which means that no messages are delivered from this specific session. セッションは、サブ キューなどのさまざまな方法で機能します。A session acts in many ways like a sub queue.

セッション受信プロセスによって保持されるセッション ロックは、peek-lock 解決モデルによって使用されるメッセージ ロックの傘です。The session lock held by the session receiver is an umbrella for the message locks used by the peek-lock settlement mode. セッションに対してロックを保持できるのは、1 つの受信プロセスだけです。Only one receiver can have a lock on a session. 受信プロセスは多数のインフライト メッセージを受け取る可能性がありますが、メッセージは順番に受信されます。A receiver may have many in-flight messages, but the messages will be received in order. メッセージを破棄すると、同じメッセージが、次の受信操作で再利用されます。Abandoning a message causes the same message to be served again with the next receive operation.

メッセージ セッションの状態Message session state

ワークフローが大規模で高可用性のクラウド システムで処理される場合、特定のセッションに関連付けられている、ワークフロー ハンドラーは、想定外の障害から回復でき、異なるプロセスやマシンで部分的に完了した作業をその作業が開始した場所から再開できる必要があります。When workflows are processed in high-scale, high-availability cloud systems, the workflow handler associated with a particular session must be able to recover from unexpected failures and can resume partially completed work on a different process or machine from where the work began.

セッション状態機能は、そのセッションに対して記録された処理の状態になるようにすぐに利用可能なセッションが、新しいプロセッサによって取得されるときに、ブローカー内のメッセージ セッションのアプリケーションで定義された注釈を使用できます。The session state facility enables an application-defined annotation of a message session inside the broker, so that the recorded processing state relative to that session becomes instantly available when the session is acquired by a new processor.

Service Bus の観点からは、メッセージ セッションの状態は、Service Bus Standard の場合は 256 KB の、Service Bus Premium の場合は 1 MB のサイズのデータを保持できる不透明なバイナリ オブジェクトです。From the Service Bus perspective, the message session state is an opaque binary object that can hold data of the size of one message, which is 256 KB for Service Bus Standard, and 1 MB for Service Bus Premium. セッションに対する処理状態は、セッション状態に保持されるか、セッション状態は記憶域の場所または情報が保管されているデータベース レコードを指すことができます。The processing state relative to a session can be held inside the session state, or the session state can point to some storage location or database record that holds such information.

セッション状態を管理するためのメソッド、SetState と GetState はセッション受信プロセスのオブジェクトにあります。The methods for managing session state, SetState and GetState, can be found on the session receiver object. 過去にセッション状態がなかったセッションは、GetState への参照として null を返します。A session that had previously no session state returns a null reference for GetState. 以前に設定したセッション状態をクリアするには、受信側の SetState メソッドに null を渡します。The previously set session state can be cleared by passing null to the SetState method on the receiver.

セッション状態は、セッション内のすべてのメッセージが処理されても、クリア (null を返す) されない限りそのままです。Session state remains as long as it isn't cleared up (returning null), even if all messages in a session are consumed.

キューに保持されたセッション状態またはサブスクリプション数は、そのエンティティのストレージ クォータがいっぱいになるまで計算されます。The session state held in a queue or in a subscription counts towards that entity's storage quota. このため、セッションで、アプリケーションが終了したら、外部管理コストを回避するために、アプリケーションで保持された状態をクリーンアップすることをを推奨します。When the application is finished with a session, it is therefore recommended for the application to clean up its retained state to avoid external management cost.

配信数の影響Impact of delivery count

メッセージごとの配信数の定義は、セッションのコンテキストと、セッションがない場合とで若干異なります。The definition of delivery count per message in the context of sessions varies slightly from the definition in the absence of sessions. 配信数が増える場合についてまとめた表を次に示します。Here is a table summarizing when the delivery count is incremented.

シナリオScenario メッセージの配信数が増えるIs the message's delivery count incremented
セッションは受け入れられますが、(タイムアウトによって) セッション ロックの有効期限が切れていますSession is accepted, but the session lock expires (due to timeout) はいYes
セッションは受け入れられ、セッション内のメッセージは (ロックされている場合でも) 完了しておらず、セッションは閉じられていますSession is accepted, the messages within the session aren't completed (even if they are locked), and the session is closed いいえNo
セッションは受け入れられ、メッセージが完了した後、セッションは明示的に閉じられていますSession is accepted, messages are completed, and then the session is explicitly closed 該当なし (これは標準のフローです。N/A (It's the standard flow. この場合、メッセージはセッションから削除されます)Here messages are removed from the session)

要求 - 応答パターンRequest-response pattern

要求 - 応答パターンは、適切に確立された統合パターンであり、送信側アプリケーションから要求を送信でき、受信側が送信側アプリケーションに応答を正しく送信する手段を提供します。The request-reply pattern is a well-established integration pattern that enables the sender application to send a request and provides a way for the receiver to correctly send a response back to the sender application. このパターンには、通常、アプリケーションからの応答の送信先となる、有効期間が短いキューまたはトピックが必要です。This pattern typically needs a short-lived queue or topic for the application to send responses to. このシナリオでは、セッションは、同等のセマンティクスを持つ単純な代替ソリューションを提供します。In this scenario, sessions provide a simple alternative solution with comparable semantics.

送信側アプリケーションを一意に識別するように特定のヘッダー パラメーターを設定することにより、複数のアプリケーションが 1 つの要求キューに要求を送信できます。Multiple applications can send their requests to a single request queue, with a specific header parameter set to uniquely identify the sender application. 受信側アプリケーションは、キューに入ってくる要求を処理し、セッション対応のキューで応答を送信して、送信側が要求メッセージで送信した一意識別子にセッション ID を設定します。The receiver application can process the requests coming in the queue and send replies on the session enabled queue, setting the session ID to the unique identifier the sender had sent on the request message. 要求を送信したアプリケーションは、特定のセッション ID でメッセージを受信し、応答を正しく処理することができます。The application that sent the request can then receive messages on the specific session ID and correctly process the replies.

注意

最初の要求を送信するアプリケーションでは、セッション ID を認識し、それを使用して、応答を期待しているセッションがロックされるようにする必要があります。The application that sends the initial requests should know about the session ID and use it to accept the session so that the session on which it is expecting the response is locked. アプリケーションのインスタンスをセッション ID として一意に識別する、GUID を使用することをお勧めします。特定の受信プロセスが応答をロックして処理できるようにするには、キューのセッション受信プロセスにセッション ハンドラーまたはタイムアウトを指定しないでください。It's a good idea to use a GUID that uniquely identifies the instance of the application as a session id. There should be no session handler or a timeout specified on the session receiver for the queue to ensure that responses are available to be locked and processed by specific receivers.

次のステップNext steps

Service Bus メッセージングの詳細については、Service Bus のキュー、トピック、およびサブスクリプションに関するページを参照してください。To learn more about Service Bus messaging, see Service Bus queues, topics, and subscriptions.