1.前回の続きです
前回のポストから3日後ですが、早速第2回をお届けします。
実は来週、Microsoft MVP Global Summitに参加する予定になっており、間が空いてしまうため、間隔を詰めてのポストになります。
さて、前回の最後に「バッチ受信、セッション有効化、順序性サポート、メッセージ有効期限設定」をお届けすると予告いたしましたが、これらのお話をするためにもう1つの機能も併せてご紹介させていただきたいと思い、もう1つ「パーティション分割」についても取り上げてみたいと思います。
2.一気に16倍
では早速パーティション分割を取り上げてみたいと思います。 パーティション分割は昨年の秋に追加された機能で、メッセージを複数のメッセージブローカーで処理することでスループットや耐障害性を向上することが期待できます。
この後出てくるセッションを利用する際にも、パーティション分割されていることで、セッションを利用するメリットが出てきます。
パーティション分割を有効にすると、16のメッセージブローカーが利用可能になり、それぞれ指定されたサイズのキューが作成されます。
たとえば、1GBサイズのキューを作成する際、EnablePartitioningにTrueを指定すると、1GBのキューが16個作成され合計サイズは16GBとなります。
#現時点ではパーティション数を指定する項目がQueueDescriptionに存在しない(もともと指定できない?)ため、自動的に16個作成されます。
現在作成可能なキューの最大容量が80GB であるのも、5GB ×16=80GBということに由来しています。 パーティション分割されたキューはBrokeredMessageのPartitionIDやセッションのSessionIDなどの単位で各パーティションに振り分けられるので、セッションを有効にしている場合は同一のセッションはすべて同一のパーティションに振り分けられます。
以下のコードスニペットはパーティション分割を有効にしている例です。
//パーティション分割
queueDescription.EnablePartitioning = true;
//キュー最大容量
queueDescription.MaxSizeInMegabytes = 1024;
キューの最大容量はQueueDescription のMaxSizeInMegabytes プロパティにMB単位で指定します。
上の例では、1024MB =1GBを指定してパーティション分割を有効にしているため、作成されるキューの最大容量は16GB になります。
3.大きなメッセージは分割してセッション化
Service Busキューに格納可能なメッセージ本文は256KB以下です。しかしながら、この制限を超えるメッセージを送信したいような場合、適宜分割して送ることで長文メッセージを受け渡すことができます。
この場合、複数のメッセージセットを束ねて扱うことができるとメッセージの送受信者ともにメリットがあります。
また、長文でない場合でも複数の関連性を持ったメッセージを一括で処理したい場合などもあるでしょう。
そのための手段として、Service Busキューではセッションが利用可能です。セッションは複数のメッセージをグループ化するものです。
同一のセッションに属するメッセージは同一のSessionIDを持つ必要があり、Service BusはこのSessionIDを識別子としてメッセージを配信します。
この時、パーティション分割が有効になっていると、Service Busは同一のメッセージブローカーにメッセージを配信します。
さらに、バッチ受信を有効にしておくことで一連のメッセージ群をまとめて取得することも可能です。
これにより、受信側で分割されたメッセージを再度組み立てて復元することが可能です。
この場合、Service Busキューではメッセージの順序性を保証することが可能であるため、取り出した順番にメッセージを組み立てることでより確実にメッセージを再現することも可能です。
それでは、セッションの有効化、そしてバッチ受信、メッセージの順序性サポートを有効にするコードをご紹介しましょう。
//バッチ受信をサポート
queueDescription.EnableBatchedOperations = true;
//セッション状態
queueDescription.RequiresSession = true;
//順序性保証をサポート
queueDescription.SupportOrdering = true;
これでBrokeredMessageにセッションごとのSessionIDを指定して送信する以外、送信側は特に違いはありません。
一方、受信側の挙動は少々異なります。 セッション内のメッセージを受信する場合、通常のMessageClientのReceiveメソッドを利用しますが、セッションの場合は以下のように記述します。
QueueClient Client = QueueClient.CreateFromConnectionString(“接続文字列”, “myqueue”);
BrokeredMessage message = new BrokeredMessage();
IEnumerable<BrokeredMessage> Messages;
//セッションの取得
MessageSession session = await Client.AcceptMessageSessionAsync();
//セッションからメッセージを受信
if(queueDescription.EnableBatchedOperations)
{
Messages = session.ReceiveBatch((int)queueDescription.MessageCount);
foreach (var msg in Messages)
{
//ここに各メッセージの処理を記述(省略)
msg.Complete();
}
}
else
message = session.Receive();
ここで注目すべき点は、MessageSessionオブジェクトのインスタンスであるsessionをQueueClientのAcceptMessageSessionAsyncメソッドで取得していることです。
そして、MessageSessionのReceiveまたはReceiveBatchを用いてメッセージを受信しています。 バッチ処理が有効である場合は、ReceiveBatchメソッドを利用して一連のメッセージをまとめて受信しています。
4.メッセージに有効期限を設定する
Service Busキューにポストされるメッセージは永続化され保存されます。 そのため、処理されずにいつまでも残り続けるメッセージが存在するかもしれません。
たとえば、ポイズンメッセージ排除のために利用される配信不能キューなどは処理されずにメッセージが溜り続ける可能性があります。理想的には一定期間を経過した後に自動的に消去されると嬉しいでしょう。
そんな時には、メッセージに有効期限を設定しポスト後一定期間を経過しても処理されないメッセージを削除すると良いでしょう。
メッセージに有効期限を設定するには、QueueDescriptionのDefaultMessageTimeToLiveプロパティに有効期限をTimeSpan型で指定します。デフォルトではTimeSpan.MaxValueが指定されています。
Azure管理ポータルでキューを作成した場合、初期値は14日に指定されます。
QueueDescriptionにDefaultMessageTimeToLiveを指定するコードを以下に示します。
//メッセージ有効期限
queueDescription.DefaultMessageTimeToLive = TimeSpan.FromDays(10);
上の例では、有効期限に10日を指定しています。
————————————————————————————————
このように、Service Busキューに様々な特性を持たせることで様々な利用シーンに対応可能な高信頼メッセージングプラットフォームを構築することが可能です。
次回以降はトピック&サブスクリプションについて取り上げていきたいと思います。
Comments are closed here.