Abhishek Lal - @AbhishekRLalSenior Program ManagerAzure Application Platform

Messaging at Scale with Azure Service Bus Queues and Topics

3-636

What’s new in SDK 2.3Dimensions of scale

Senders Throughput Receivers

Availability considerations

Microsoft Azure Service Bus Queues and Topics

Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr

SDK 2.0 April 2013

SDK 2.1 July 2013

SDK 2.2 Oct 2013

SDK 2.3 April 2014

SB1.1 Preview—6/13Interoperability with AMQP 1.0Shared Access Signature (SAS) auth modelIncluding all SDK 2.0

Shared Access Secrets (SAS)Auto-delete idle entitiesEvent-driven modelTask-based async APIsBrowsing messages

AMQP 1.0 supportPaired namespacesSymmetric server and service

Visual Studio 2013 supportPartitioned queues and topicsAMQP client support for SAS auth

SB1.1 RTM—10/18Part of Windows Azure PackAdmin and tenant management portal

New features in Azure Service Bus

OnMessageSessionConnectivityMode AutoDetect CORS supportHTTP message batchingClient side perf countersForwardTo for deadletter queues

Scale on senders

Customer scenario—collect events for analysis

Service Bus Topics

Analytics

Dashboards

Telemetry fan-in to Service Bus TopicsLoad balanced across datacentersTrue filter for all but 1 subscriptionsReal-time and batch analytics

Code (Windows—Orleans)/(Linux—Storm )

Batch analytics (HDInsight)

BI (Data warehouse)

State tracking (Az Table)

Demo: CORS support for Send/Receive messages

Binary protocols matter in messagingService Bus is a polyglot messaging service

AMQP, SBMP, HTTP/RESTProtocols can provide reach and perfSome features vary by protocol, mostly for receive scenarios Quotas for connections on AMQP/SBMP

Scale considerations for senders - protocolsProtocol considerations

Binary Protocols Matter with MessagingHTTP SBMP/AMQP

Client Client

Q S

T

N Q S

T

N

Socket Socket

HTTP 1 Entity per Socket 1 Pending Operation per Socket 60s operation timeout (NAT/Prx)SBMP/AMQP Unlimited Multiplexed Entities and Unlimited Pending Ops per Socket No fixed operation timeout Session Support (coming in AMQP)

Protocols and SDKs

Service Bus is a polyglot messaging service

“SBMP”high perf..NET only

AMQP 1.0high perf

high reach

App ( any language

)Community Libs

AMQP 1.0Any OS

App ( .NET )

SB .NET Lib“SBMP”Windows

App ( any language

)SB Wrappers

HTTPAny OS

HTTPhigh reachlower perf.

Enables cross-platform apps to be built using brokers, libraries and frameworks from different vendors Efficient—connection-oriented Reliable—fire-and-forget to

reliable, exactly-once delivery Portable data representation—

xPlat Flexible—client-client, client-

broker, and broker-broker

Open, standard messaging protocol

AMQP

OASIS Standard Oct 2012Technology vendors: Axway Software, Huawei Technologies, IIT Software, INETCO Systems, Kaazing, Microsoft, Mitre Corporation, Primeton Technologies, Progress Software, Red Hat, SITA, Software AG, Solace Systems, VMware, WSO2, Zenika. User firms: Bank of America, Credit Suisse, Deutsche Boerse, Goldman Sachs, JPMorgan Chase

Now an ISO/IEC JTC1 Standard!

AMQP 1.0 Standardization

Protocols and SDKs

WindowsSBMP(net.tcp,

proprietary)

Service Bus

Queues &

TopicsHTTP(S)

AMQP 1.0

Other platforms

https://github.com/windowsAzure/

/azure-sdk-for-python/

/azure-sdk-for-php/

/azure-sdk-for-node/

/azure-sdk-for-java/

/azure-sdk-for-ruby/

AMQP 1.0

HTTP(S)

Samples / Prototypes

Batching increases throughput For send you can use SendBatch or implicit batching with

BatchFlushInterval For receive use ReceiveBatch or PrefectCount Does affect latency

Strongly recommend using asynchronous operations Do not flood the asynchronous job queue. Don't call BeginXXX in a tight

loop

Significantly higher throughput on connected protocols vs. HTTP HTTP send batching now available!

Sync vs. Async vs. Batch

Demo: Sync vs. Async vs. Batch

Release in Azure SDK 2.2 Partitioned entities spread messages

across several nodes

Allow for 16GB to 80GB queues/topics Resilient to unavailability of storage units Achieve higher throughput Improve the availability of queues/topics ALWAYS USE THESE! – will be default in

next SDK

Partitioned queues and topics

Sessions Full support to session semantics (SetState/GetState, correlation and

ordering Just set the SessionId property on message

PartitionKey By default we assign a partition to any incoming message Set this property if you need transactions

MessageId Deduplication fully supported for partitioned entities based on MessageId

Quota Limited to 100 entities per namespace

Partitioned queues and topics

NamespaceManager nm = NamespaceManager.CreateFromConnectionSTring(myConnString);

// Create partitioned topicTopicDescription td = new TopicDescription(myTopicName);             td.EnablePartitioning = true;nm.CreateTopic(td);

// Create partitioned queueQueueDescription qd = new QueueDescription(myQueueName);             qd.EnablePartitioning = true;nm.CreateQueue(qd);

Create partitioned queues and topics

Each instance of MessagingFactory is a connection to the service

Create more instances of MessagingFactory from your servers where you want to maximize throughput

Connection level resilience is built-in

Scale considerations for connection throughputCreate more connections where applicable

Session correlation Originator sets some SessionId on outbound session Receiver reuses SessionId for reply session Originator filters on known SessionId using session

receiver

Message correlation (queues) Originator sets message-or CorrelationId, receiver copies

it to reply Reply sent to originator-owned queue indicated by

ReplyTo Originator receives and dispatches on CorrelationId

Subscription correlation (topics) Originator sets message-or CorrelationId, receiver copies

it to reply Originator has Subscription on shared reply topic w/rule

covering Id Originator receives and dispatches on CorrelationId

Several options available to correlate related messages (such as for request–response)

Scale considerations for senders - correlation

Work-Set Pinning Sessions allow pinning sets of related sets of related messages to a

particular receiver even when using competing consumers.

Sessions

S RQueue

R

R

Sessions – Creating Session-Aware Entities

namespaceManager.CreateQueue( new QueueDescription(queueName) { RequiresSession = true });

namespaceManager.CreateSubscription( new SubscriptionDescription(topicName, subName) { RequiresSession = true });

Sessions – Sending Messages

var msg = new BrokeredMessage { SessionId = sessionId, Properties = { { "JobId", jobId }, { "Result", result } } };

Sessions – Receiving Messages

var qc = messagingFactory.CreateQueueClient(queueName);

var session = replyQueueClient.AcceptMessageSession(sessionId);var msg = session.Receive();

orvar session = replyQueueClient.AcceptMessageSession();var msg = session.Receive();

orreplyQueueClient.OnMessageSession(…)

Allows storing session state in Service BusSize limit equivalent to one message (256KB)Enables Work Set pinning with safe failover to secondary

Session State

S RQueue

R

R

Demo: Correlation using sessions

Shared access signature Ability to configure authorization rules at the service

bus namespace or entity level Authorization rules configured at namespace root

grant rights to all entities in the namespace Each topic/queue can have up to 12 rules (a key per

rule) Clients authenticate by providing token (generated

by signing the URI of resource and an expiry with the key)

Access control service STS service to enable federation with identity

providers ACS issues SWT with specific claims,

i.e., send, listen, manage

Scale considerations for senders – auth modelsIntegrated and simple auth models supported

Considerations include number of unique senders, token lifetimes (generation rate, expiry, renewal) and service dependencies

Demo: SAS Auth rules for Queues

Binary protocols matter in messaging Use batching (http and amqp) for send and receive Unlimited concurrent http connections Up to 100 concurrent AMQP connections per

queue/topic

Per sender stream correlation Use SessionID to create per sender virtual queues Use Session State to track individual stream

processing No throughput/usage isolation between senders

Auth models SAS preferred authorization model, 12 rules per

entity ACS token generation limited to ~40/second

Scale considerations for senders - summaryQueues and topics can be used to fan—in messages from large number of senders from a variety of platforms

Scale on receivers

Continuous client state synchronization

Service Bus TopicsVS Online Backend

Team Foundation Services

Topic per VS userSubscription per VS instanceAlways connected using AMQPLow latency notifications to IDEs Platforms with no native notification

Topic and subscriptions for pub/sub One-to-one, one-to-many and many-to-many Up to 2000 subscriptions per topic Filters allow you to target messages SQL92 and correlation filters

Message flows with auto-forwarding From queues/subscriptions to queues/topics

For transient subscribers use AutoDeleteOnIdle

Scale considerations for receivers

Queues and topics can be used to fan-out messages to large number of receivers from a variety of platforms

Scenario Sender broadcasts event to all interested receivers

Common use-cases Event notification

Publish-subscribe—one to many

S RTopic SubSub

Sub

R

R

Scenario Route a message to different recipients based on data contained in the

message

Common use-cases Order processing systems

Content-based router—one to one

S RTopic SubSub

Sub

R

R

Rule conditions form mutually exclusive ranges

Allows partitioning-aware message distribution

No need for sender to be aware of partitioning

Partitioning

S RTopi

cSubSub

Sub

R

R

PartId > 272 AND PartId

<= 567

PartId > 0 AND PartId

<= 272

PartId > 567 AND PartId

<= 791

TopicDescription mainTopic = namespaceManager.CreateTopic(“topicName");

namespaceManager.CreateSubscription(“topicName", “AuditSubscription"); namespaceManager.CreateSubscription(“topicName", “Category1Subscription",

new SqlFilter(“Category = 1"));

namespaceManager.CreateSubscription(“topicName", “CategoryNot1Subscription",

new SqlFilter(“Category <> 1"));

BrokeredMessage myMessage = new BrokeredMessage(); myMessage.Properties.Add(“Category”, 1);

or myMessage.Properties.Add(“Category”, 2);

or myMessage.Properties.Add(“Category”, 3);

Publish-subscribe—one to one

Scenario The sender wants to send the message to a list of recipients

Common use-cases Order processing systems—route to specific vendors/departments

Recipient list

S RTopic SubSub

Sub

R

R

TopicDescription mainTopic = namespaceManager.CreateTopic(“topicName");

namespaceManager.CreateSubscription(“topicName", “AuditSubscription"); namespaceManager.CreateSubscription(T“topicName", "FirstSubscription",

new SqlFilter("Address LIKE '%First%'"));

namespaceManager.CreateSubscription(T“topicName", “SecondSubscription", new SqlFilter("Address LIKE '%Second%'"));

BrokeredMessage myMessage = new BrokeredMessage(); myMessage.Properties.Add(“Address”, “First”);

or myMessage.Properties.Add(“Address”, “Second”);

or myMessage.Properties.Add(“Address”, “First,Second”);

Publish-subscribe—many to many

Demo: PubSub messaging with Topics and Filters

Chain together queues/topics Build rich messaging flows Scale out topics/subscriptions Fan-in from several queues Source: queue/subscription Destination: queue/topic

Message flows with auto-forwarding

QueueDescription destinationQ = new QueueDescription("myQ2");QueueDescription sourceQ = new QueueDescription("myQ1");sourceQ.ForwardTo = “myQ2";NamespaceManager nm = NamespaceManager.Create();nm.CreateQueue(destinationQ);nm.CreateQueue(sourceQ);

//New in Azure SDK 2.3QueueDescription DLQTarget = new QueueDescription("DLQ");nm.CreateQueue(DLQTarget);sourceQ.ForwardDeadLetteredMessagesTo = "DLQ";nm.CreateQueue(sourceQ);

Auto-forwarding

Connectivity scale out for dynamic connectionsService Bus as scale-out backplane

Scale out solutions SignalR -

http://github.com/signalr Socket.io -

http://github.com/WindowsAzure/socket.io-servicebus

Devices

PC

Browsers

Basic Devices

IIS (Node.js) Server

IIS (Node.js) Server

IIS (Node.js) Server

IIS (Node.js) Server

S

Serv

ice B

us To

pic

Supports dynamic topologies for messaging

Minimum duration is 5 minutes

Activity includes send, receive, pending receive as well as entity updates

Transient subscribers can use AutoDeleteOnIdle

TopicDescription topicDescription = new TopicDescription("myTopic"); topicDescription.AutoDeleteOnIdle = TimeSpan.FromMinutes(30); namespaceManager.CreateTopic(topicDescription);

AutoDeleteOnIdle

Availability considerations

Code needs to be resilient against operation failures and connectivity issues

DeadLetterQueues help protect the backend service

All exceptions with .IsTransient set can be retried By default we have exponential back off enabled, only give up if you

have somewhere else to go

Partitioned queues/topics significantly improve availability

For Datacenter wide issues use paired namespaces

What can go wrong will go wrong!

MessagingFactory mf = MessagingFactory.Create();

mf.RetryPolicy = RetryExponential.Default; // retry on transient errors until the OperationTimeout is reached

mf.RetryPolicy = RetryPolicy.NoRetry; // disables retry for transient errors

Availability – client retry

Availability – paired namespaces

Service BusNamespace

Web / FrontendRoles

Worker / Backend Roles

Paired namespace – send behavior

Service BusNamespace

Web / FrontendRoles

Service Bus Paired Namespace

Worker / Backend Roles

Paired namespace – syphon

Service BusNamespace

Web / FrontendRoles

Service Bus Paired Namespace

Syphon enabled

Worker / Backend Roles

Paired namespace - receive scenario

Service BusNamespace

Web / FrontendRoles

Service Bus Paired Namespace

Worker / Backend Roles

factory = MessagingFactory.Create(SB_Primary_NS_Address);factory.PairNamespaceAsync(new SendAvailabilityPairedNamespaceOptions(              secondaryNamespaceManager:paired_NS_manager,           messagingFactory:paired_NS_factory,           backlogQueueCount:10,           failoverInterval:TimeSpan.FromMinutes(2),           enableSyphon:true           ));factory.Open();

Paired namespace - API

Sender availability is supportedSessions and scheduled messages workOrdering may be lostEnd-to-end receive latency will varyFixed set of transfer queues (limits size)Syphon can be selectively startedUser provisions secondary NamespaceBilling implication – regular message operations apply

Paired Namespace - key considerations

Microsoft Azure Service Bus scale in all dimensions

Senders Throughput Receivers

Improve Reliability and Availability using new features

Partitioned Queues & Topics Paired Namepsaces

Summary – Messaging at scale

ResourcesWhat’s new in Azure SDK 2.3Performance best practicesService Bus Authentication and AuthorizationPartitioned Queues & Topics

Availability considerations

Disaster recoveryService Bus for Windows Server

Service BusOverviewDocumentationTutorials

AMQP 1.0 supportOverviewDeveloper Guide.NET TutorialJava Tutorial

Your Feedback is Important

Fill out an evaluation of this session and help shape future events.

Scan the QR code to evaluate this session on your mobile device.

You’ll also be entered into a daily prize drawing!

© 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.