Velocity Conference '13: Asynchronous messaging for performance optimization, featuring RabbitMQ

1Pivotal Confidential–Internal Use Only 1Pivotal Confidential–Internal Use Only

Asynchronous Messaging for Performance Optimization

Al SargentDirector, Product MarketingPivotal

Velocity Conference 2013June 20, 2013

2Pivotal Confidential–Internal Use Only

About me

Now: Application Fabric team @ Pivotal

Previously: SpringSource/VMware/RabbitMQ since 2010

Earlier: Sauce Labs, Wily, Mercury, Oracle


Diagram adapted from http://www.manning.com/videla/

History of Messaging

http://www.manning.com/videla/


Typical use cases for Messaging

EventI need to know when to do something

Data fragmentI need to give you a piece of this data without you needing to understand the whole schema

RoutingControl who gets which message, without changing sender and

receiver Publish

Tell everyone who wants to know about this Batch

Producer and consumer can run at independent times Telemetry

Metadata on servers, devices, etc. Load share

Add more consumers to scale up


AMQP introduction• AMQP (Advanced Message Queuing Protocol) is an open standard

application layer protocol for message oriented middleware– It is an open protocol (like TCP, HTTP, SMTP, and so on)

• The defining features of AMQP are:– Message orientation

– Queuing

– Routing (including point-to-point and publish-and-subscribe)

– Reliability

– Security

• AMQP mandates the behaviour of the messaging provider and client– Implementations from different vendors are truly interoperable

– Previous attempts to standardise middleware have focussed at the API level

• This approach did not create interoperability

– Instead of merely defining an API, AMQP defines a wire-level protocol• A wire-level protocol is a description of the format of the data that is sent

across the network as a stream of octets

• Any tool that can create and interpret messages that conform to the defined wire-level protocol can interoperate with any other compliant tool, irrespective of implementation language


AMQP motivation• AMQP was born of frustration!

– Message oriented middleware needs to be everywhere in order to be useful, but…

– Traditionally dominant solutions are typically very proprietary• They are frequently too expensive for everyday use

• They invariably do not interoperate

– The above issues with proprietary solutions have resulted in numerous home-grown developments

• Custom middleware solutions

• Custom adaptors

– The net result for a large enterprise is middleware hell• Hundred’s of applications, thousand’s of links

• Every other connection is different

• Massive waste of effort

– Costly to implement

– Costly and difficult to maintain


AMQP Comparison with other protocols

AMQP can accommodate all of the above as use-cases… and switch between them (open, ubiquitous, and adaptable)

Protocol Comments

SMTP Unreliable, slow

HTTP Synchronous, semi-reliable, no routing

XMPP No delivery fidelity or queue management

FTP Point to point, transient, does not work well with NAT/SSL

MQ Exactly once

TCP At least once, reliable but short lived, no application-level state management

UDP Fast but has no delivery guarantees


AMQP scales of deployment

Type of deployment Possible scenario

Developer/casual use 1 server, 1 user, 10 queues, 1 message per second

Production application 2 servers, 10-100 users, 10-50 queues, 25 messages per second

Departmental mission critical application

4 servers, 100-500 users, 50-100 queues, 250 messages per second

Regional mission critical application

16 servers, 500-2,000 users, 100-500 queues and topics, 2,500 messages per second

Global mission critical application

64 servers, 2K-10K users, 500-1000 queues and topics, 25,000 messages per second

Market data (trading) 200 servers, 5K users, 10K topics, 250K messages per second

As well as volume, the latency of message transfer is often important; AMQP implementations can deliver messages with latencies of less than 200μs

AMQP implementations can cover deployment at different levels of scale ranging from trivial to the mind-boggling... no job too big or too small.


AMQP conceptsEach message is stateless

Consumers create queues; these buffer messages for push to consumers

Queues are stateful, ordered, and can be persistent, transient, private, shared.Exchanges are stateless routing tables.

Consumers tell queues to bind to named exchanges; each binding has a pattern e.g. “tony” or “*.ibm.*”

Producers send messages to exchanges with a routing key e.g. “tony”, or ordered set of keys e.g. “buy.ibm.nyse”

Exchanges route messages to queues whose binding pattern matches the message routing key or keys


P XC

CM3M1 M2

AMQP direct exchanges

QueueBindingRouting

key

• Point to point messaging

• A single message that needs to be sent to a single recipient

• Can have multiple consumers (load will be balanced across them)


AMQP fan-out exchange

• A fan-out exchange is a “publish-subscribe” mechanism• Used to send a single message to multiple recipients (very similar to an email distribution

list) • Any queue bound to a fan-out exchange will receive any message sent to the exchange• Message consumption of each queue will be dependent on the number of consumers and

speed of message consumption

P X C

C

CM3M1 M2

M3M1 M2

M3M1 M2 C

Queue 1

Queue 1

Queue 3

Same message sent to multiple queues/recipients


P X

CM1 M2

M1 M2

M3

M1

C

C

AMQP topic exchange

Queue 1

Queue 2

Queue 3

Binding pattern B

Binding pattern C

Binding pattern A

• Content-based routing mechanism

• Messages posted to queues based on binding pattern (PCRE used)

• Very powerful mechanism


RabbitMQ: Modern Messaging for the Cloud

Multi-geo, cloud-scale Message Bus

RabbitMQ Message BrokerAMQP, JMS, MQTT, STOMP, HTTP, HTTPS…

Point-to-point and pub-sub

Virtual hosts, dynamic configuration

Cluster within single datacenter

Federate across multiple datacenters

Cloud Services DevicesApplications


RabbitMQ: Run Everywhere, Connect Anything

Hundreds of other clients

C

Frameworks

Languages

Operating Systems

https://www.rabbitmq.com/devtools.html

http://www.rabbitmq.com/tutorials/tutorial-one-java.html

http://www.rabbitmq.com/tutorials/tutorial-one-python.html


• Problem: A tightly coupled Grails Application is serving ads to a web page. Ads are refreshed every four hours, using a synchronous batch update process. Then, a new business guideline is introduced, which requires the refresh rate of the ads to be increased by 50 percent.

• Solution: To increase the refresh rate without putting additional strain on the existing servers, employ a solution utilizing RabbitMQ. Instead of having a Quartz Job run every four hours to call one service, reconfigure the Quartz Job to run every hour and post messages to a queue. Once a message becomes available on the queue, other servers are on standby to read it and then refresh the given segment of ads.

• Benefits of using RabbitMQ: – separate requests and actions– scalability – ease of increasing processing

capabilities– ability to have apps coded in different

languages communicate with one another– great for batch processing in an

asynchronous manner

http://www.wapolabs.com/2012/02/07/leveraging-rabbitmq-to-decouple-your-application/

Leveraging RabbitMQ to decouple a webapp

Synchronous batch update process

RabbitMQ solution

http://www.wapolabs.com/2012/02/07/leveraging-rabbitmq-to-decouple-your-application/


Government of India: UIADI

• One of the largest IT projects ever

• Biggest online identity project in the world

• Enabling social services and microfinance for 1.2 billion people

• Very significant countrywide infra with many moving parts

http://www.biometrics.org/bc2012/presentations/UIDAI/Technology_Tampa_v1040.pdf





BBC Zeitgeist

Zeitgeist is a prototype developed by BBC Research & Development to discover and track

the most shared BBC webpages on Twitter.

http://www.bbc.co.uk/blogs/researchanddevelopment/2010/09/what-makes-zeitgeist-tick.shtml

http://www.bbc.co.uk/blogs/researchanddevelopment/2010/09/what-makes-zeitgeist-tick.shtml


Number of connected devices is growing

Source: McKinsey, May 2011


1

Sensor with MQTT client

2

Pivotal RabbitMQ

3

Spring AMQP

Spring Hadoop & XD

Pivotal tc Server

4

Pivotal HD

Use Case: Big Data ApplicationsHow Pivotal components fit together


• The rabbitmq-management plugin provides an HTTP-based API for management and monitoring the RabbitMQ broker

• Two tools are provided that use this API:

• A powerful browser-based UI

• A powerful command line tool (rabbitmqadmin)

• rabbitmqadmin can perform the same actions as the web-based UI, and is convenient for use when scripting

• Or you can use the API to develop your own tools...

RabbitMQ: management and monitoring






www.github.com/gopivotal