sdk 2.0 april 2013 sdk 2.1 july 2013 sdk 2.2 oct 2013 sdk 2.3 april 2014 sb1.1 preview—6/13...
TRANSCRIPT
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.