Messaging for IoT

Messaging for IoT October 2015

Martyn  Taylor,  Dejan  Bosanac

Presenters

Martyn  Taylor •  Senior  So4ware  Engineer  at  Red  Hat •  Apache  Ac>veMQ  CommiCer

•  Mainly  working  on  Apache  Artemis •  Keen  interest  in  IoT Bosanac  Dejan •  Senior  So4ware  Engineer  at  Red  Hat •  Apache  Ac>veMQ  commiCer  and  PMC  member •  Co-­‐author  of  Ac>veMQ  in  Ac>on

Agenda

•  IoT  messaging  basics •  Tasks  and  challenges •  PaCerns  and  protocols

•  IoT  messaging  brokers •  Apache  Ac>veMQ •  Ac>veMQ  Artemis

•  IoT  messaging  scaling •  Ver>cal  and  horizontal •  Qpid  Dispatch  Router •  Scalable  deployments

IoT Messaging Basics

•  IoT  Topology •  Messaging  tasks •  Messaging  challenges

IoT Topology

 Big  Data

Messaging  Infrastructure

Analy>cs

Enterprise  Middleware

Devices

IoT Messaging Infrastructure

Task •  Provides  connec>vity  between  devices  and  backend  systems Challenges •  Interoperability •  Deployment  environment •  High  Availability •  Scalability

IoT connectivity patterns

•  IoT  Communica>on  PaCerns

•  Telemetry,  Command  &  Control,  Enquiry,  No>fica>ons •  Protocols  and  Technologies

•  JMS •  MQTT •  AMQP

Telemetry

•  Device  →  Service •  One  way  (push) •  Failures  tolerable •  Lots  of  small  data

Command  and  Control

•  Service  →  Device •  Two  way  (Req/Resp) •  Less,  more  important  data •  1  →  1  and  1  →  many  

•  grouping  

Enquiry

•  Device  →  Service •  1  →  1 •  Two  way  (Req/Resp)

No>fica>on

•  Service  →  Device •  One  Way  (push) •  1  →  Many

•  Grouping

Requirements  on  the  transport

•  Communica>on  from/to  devices •  1  →  1

•  Device  Addressing •  1  →  Many

•  Group  Addressing •  Push •  Request  →  Response

IoT  Networks

•  Unreliable •  Handle  network  failures

•  Expensive  and  Constrained •  Low  network  overhead

IoT  Devices

•  Limited  Resources •  Low  processing  overhead

•  Large  scale  and  varied •  Inter-­‐operable

•  BaCery  powered •  Work  offline

IoT  Environment  Challenges

•  Interoperable •  Connec>on  Failure  Handling •  Offline •  Low  network  overhead •  Low  Processing  overhead

JMS

•  Addresses  majority  of  requirements •  1-­‐1,  1-­‐Many,Grouping,Device  address

•  Queues,  Topics,  Message  Selectors •  Push •  Req/Resp

•  Reply  to  queues •  Inter-­‐operable

•  JVM •  Connec>on  failures

•  Durable  Messages  and  Various  ACK  Modes

JMS

•  Inter-­‐operability •  Java  Run>me  only •  Protocol  vs  API

•  Vendor  specific •  Rich  feature  set

•  Complexity  on  the  client •  Large  footprint

•  Vendor  protocols •  High  network  overhead

MQTT

•  OASIS  standard  (v3.1.1) •  Created  by  IBM

•  Light  weight •  Low  network  message •  Simple  protocol

•  Pub  /  Sub

•  Quality  of  Service

•  Connec>on  failures

•  Very  popular  in  IoT  scenarios

QoS  Levels

Overheads

•  Sending  /  Receiving  messages •  QoS  0  =  8  bytes •  QoS  1  =  min  12  bytes •  QoS  2  =  min  20  bytes

•  Clients  have  small  code  foot  print •  Simple  protocol •  Burden  on  the  broker

Failures

Reconnects

Subscrip>ons

•  Topics •  Hierarchical  addresses

•  e.g.  building/core/floor/2/office/1 •  Supports  wild  cards

•  building/core/floor/# •  building/core/floor/+/toilet/+

•  QoS  per  topic •  Outlives  a  connec>on

AMQP  1.0

•  Interna>onal  Standard  (ISO/IEC  ISO  19464) •  Binary  Protocol •  Rich  feature  set:

•  conversa>on  mul>plexing •  advanced  flow  control •  Type  system •  QoS  Guarantees

•  Symmetrical  message  exchange •  No  Broker  required

QoS  Guarantees

   Quality  of  Service  guarantees •  At  most  once

•  Fire  and  Forget •  At  least  once

•  Retry •  Exactly  once

•  3  Way  Ack

Type  System

•  Highly  Interoperable •  Rich  Type  Set

•  Primi>ves •  integer,  long •  lists,  maps

•  Descrip>ve  types •  Allow  applica>on  defined  types

•  Mappings  in  most  languages

Symmetrical  Protocol

•  Client  -­‐>  Broker •  Broker  less  message

•  Client  -­‐>  Client •  Client  -­‐>  Router

•  Interes>ng  features •  Smart  rou>ng

Flow  control  and  Mul>  Channels

•  Limit  producer  and  consumer  flow •  Each  channel  (link)  can  be  controlled  individually •  Limit  telemetry  flow  for  command  messages

Protocols  Overview

•  Lots  of  IoT  protocol  choices  including  several  not  discussed  here •  The  right  choice  depends  of  the  scenario •  Scenarios  may  combine  protocols

CoAP

Target  usecase Long-­‐haul  (&  local)

Long-­‐haul Local  (&  long-­‐haul)

Long-­‐haul

Compactness High Medium Highest Verbose Security SSL SSL DTLS SSL Flow  control No Yes No No Structured  message

No Yes No Yes

Complexity Medium High Low Lowest

IoT Messaging Brokers

•  Apache  Ac>veMQ •  Ac>veMQ  Artemis

Apache ActiveMQ

•  Apache  Ac>veMQ  is  a  high-­‐performance,  scalable  messaging  broker •  Started  as  an  open  source  JMS  broker •  Moved  to  Apache  So4ware  Founda>on  in  2006 •  Now  widely  used  open  source  messaging  system

Apache ActiveMQ

•  Mul>-­‐Protocol/Mul>-­‐Language  Support •  Invented  Stomp  protocol  in  2006 •  Now  supports  AMQP  1.0,  MQTT  3.1.1,  HTTP,  STOMP  protocols •  Broad  range  of  supported  client  libraries  for  all  kinds  of  device  

hardware

Apache ActiveMQ

•  Benefits

•  Feature  rich •  BaCle-­‐tested  in  many  produc>on  environments •  Good  security  support •  Flexible •  Configurable •  Embeddable

Apache ActiveMQ

•  Limita>ons

•  Broker  core  gepng  old •  WriCen  using  synchronous  thread-­‐locking  model •  It  limits  ver>cal  scalability  of  the  broker •  Number  of  threads  raise  with  number  of  connec>ons  and  des>na>ons

Ac>veMQ  Artemis

•  Mul>  Protocol  Broker

•  AMQP,  MQTT,  STOMP,  OpenWire,  Artemis  Core •  JMS  (API)

•  Started  as  HornetQ  JBoss  project  in  2009 •  Embedded  WildFly  (JBoss  AS)  JMS  messaging  service •  In  2014  donated  to  Apache  Ac>veMQ

•  Sub  project  Ac>veMQ  Artemis. •  Latest  Release  1.1.0

Ac>veMQ  Artemis:  Core

•  Contains  Broker  Business  logic •  Core  maintains  a  >ght  scope

•  Message  Rou>ng •  Persistence •  Protocol  u>lity  API •  HA  and  Scaling

•  Highly  Performance •  Protocols  are  plugged  in

Ac>veMQ  Artemis:  Architecture

Artemis Core

Apache  Artemis  Summary

•  Great  performance  due  to •  Reac>ve  Architecture •  Efficient  Append  only  Journal

•  Mul>  -­‐  Protocol  Broker •  AMQP,  MQTT,  STOMP,  CORE,  OpenWire •  JMS

•  HA  and  Scalability  built  in

Apache  Artemis  Next  Steps

•  Take  features  from  Ac>veMQ

•  Enhance  OpenWire  support  for  Ac>veMQ  compa>bility

•  JDBC  Journal  implementa>on

•  More  protocols •  CoAP •  Your  protocol  here….

IoT Messaging Scaling

•  Ver>cal  and  Horizontal  scaling  of  Brokers •  Qpid  Dispatch  Router •  Scalable  Deployment

Broker – Vertical Scaling

•  Give  broker  enough  resources •  Reduce  thread  usage

•  NIO  transport •  Reac>ve  architecture

•  Improve  monitoring  under  stress •  Advisory  messages •  Selec>ve  Mbean  registra>on

Broker – Horizontal Scaling

•  One  broker  can  only  do  so  much •  Horizontal  scaling  by  using  networks  of  brokers

•  Load  balance  connec>ons •  Limita>ons

•  All  des>na>ons  on  all  brokers •  Broker  network  is  the  boCleneck

Qpid Dispatch Router

•  Lightweight  AMQP  1.0  message  router  wriCen  in  C •  hCp://qpid.apache.org/components/dispatch-­‐router/   •  Provides  flexible  and  scalable  interconnect  between  AMQP  

endpoints

Qpid Dispatch Router

•  It  is  not  a  broker •  It  never  owns  a  message   •  It  propagates  AMQP  transfer,  seClement  and  disposi>on  frames  

between  endpoints •  Message  based  or  link  based  rou>ng

Router

/device1

/device2

Qpid Dispatch Router

•  It  can  be  deployed  in  mul>ple  router-­‐broker-­‐endpoint  topology •  Redundant  paths

Router

Broker

Router

Qpid Dispatch Router

•  Cost-­‐based  route  computa>on

Router

Broker

Router

Qpid Dispatch Router

•  Automa>c  re-­‐rou>ng  on  failure

Router

Broker

Router

Qpid dispatch router

•  Benefits

•  BeCer  scaling  due  to  more  focused  tasks •  Smart  rou>ng  can  be  used  to  par>>on  the  traffic •  Ideal  candidate  for  gateway  into  the  system

Scalable deployments

•  Combina>on  of  brokers  and  routers  provides  powerful  tool  box •  Brokers  should  focus  on  storing  messages •  Routers  should  do  the  rest •  Allows  for  horizontal  scaling  topologies  that  can  solve  IoT  

challenges

Scalable deployments

•  Smarter  scaling  techniques  using  routers

•  Connec>ons  concentra>on •  Des>na>ons  concentra>on •  Des>na>on  sharding •  Smart  rou>ng

Connection Concentration

Router

Broker

•  Challenge:    Reduce  the  number  of  connec>ons  on  the  broker

Destination Concentration

Router

Broker

/building1/room1

/building1

/building1/room2

/building1/room2

•  Challenge:    Reduce  the  number  of  des>na>ons  on  the  broker

Destination Sharding

Router

Broker

Queue.A

Broker

Queue.B

•  Challenge:    Distribute  des>na>ons  across  brokers

Deployments – Smart Routing

Router

Broker

QoS  0

•  Challenge:    Decrease  the  load  of  messages  on  the  broker

Deployments – Smart Routing

Router

Broker

QoS  1

Summary

•  IoT  offers  a  new  set  of  problems  for  communica>on •  Messaging  is  a  good  fit •  We  need  new  tools  and  technologies  to  help

•  Protocols  such  as  AMQP  and  MQTT  help  address  some  of  these  problems

•  Ac>veMQ  and  Artemis  are  evolving  to  meet  IoT  demands •  New  tools  such  as  Apache  Dispatch  Router  allow  us  to  do  some  

novel  things  to  help  scale  to  really  high  numbers

Resources

•  Slides •  hCp://hCp://www.slideshare.net/dejanb/messaging-­‐for-­‐iot    

•  MQTT •  Spec:  hCp://www.mqC.org   •  Libraries  and  tutorials:  hCp://www.eclipse.org/paho/  

•  AMQP •  Spec:  hCp://www.amqp.org/   •  Libraries  and  tutorials:  hCp://qpid.apache.org/  

•  Ac>veMQ  and  Artemis •  hCp://ac>vemq.apache.org/  

•  Dispatch  Router •  hCp://qpid.apache.org/components/dispatch-­‐router/