In this post, we will talk about what are the available options
at the moment when you need to support MQTT protocol inside Azure.
Business requirement
Design a solution that can handle 10M messages per day that
it is deployed in one Azure Regions and support MQTT protocol.
Out-of-the-box options
Inside Microsoft Azure, the only option that we have to use
MQTT as a service is in combination with Azure IoT Hub. This service is design to
scale and manager a high number of devices and throughput. There are situations
like when you need to collect telemetric data when Azure IoT Hub is to complex
and you would like a more simple solution.
You would need just an endpoint where you can push metrics.
Inside AWS, we can use Amazon MQ that it is a managed message broker service
build on top of Apache ActiveMQ.
Similar options are available inside Azure, but none of them
is supporting MQTT. For example, Azure Event Hub is a right candidate, but unfortunate
it is supported only AMQP protocol that it is not an acceptable option for us. Other
options are available more message base oriented like Azure Queues or Azure
Service Bus, but none of them are supporting MQTT and are not designed for such
loads and at the same time to keep costs low.
Message base solutions
On the market, there are multiple message base communication
solutions that support MQTT. Most used are RabbitMQ, Apache Kafka and ActiveMQ.
You will be able to find a lot of comparison between all of these services, but
personally, for this case, I prefer RabbitMQ that offers:
- (plus) Excellent support for setup-up and configuration
- (plus) Fast and low consumption of resources
- (plus) A cluster can be defined with strong support for partitioning
- (plus) Intuitive interface and API
- (plus) Strong support from the community and well documented
- (minus) Needs strong ops knowledge
Top clients of RabbitMQ are MIT, Reddit, 9GAG, Zillow and
Rainist.
Custom solutions
The solution is based on RabbitMQ that it is hosted inside
Azure Kubernetes Services. A RabbitMQ cluster that runs inside AKS is running
on dedicated nodes with a specific configuration (nodes with a high number of
memory and fast SSD). Bitnami is offering images for Kuberntestes that are ready
to be used.
In front of the RabbitMQ, you will need Azure Load Balancer
(ALB) that would do the name resolution and the redirect to the RabbitMQ
cluster. Two public IPs are reserved inside ALB for name resolution. For this
scenario, there is no need to configure an API Gateway that would handle the
traffic. ALB is a perfect march for it.
Tips to optimize a RabbitMW cluster inside AKS
- Try to use one node (HA) if possible (no mirroring between nodes)
- Allocate notes with plenty of memory
- Disable publish confirmation if you don't need them
- Disable acknowledgements if you don't need them
- Enable RabbitMQ Hipe (precompiled)
- Disable plugins and features that you are not using
- Ensure that the queues are not staying long for a long period of time
- Don't forget to set a maximum queue size
- It is mandatory to use transient messages (not written to the disk)
- Don't use lazy queues (to avoid writing on disk)
- Use multiple no. of queues
- Use hash exchange plugin where the throughput is very very high
Conclusion
Even if inside Azure, we don’t have any other PaaS/SaaS
option beside Azure IoTHub to use MQTT protocol, AKS can be a good place where
we can run our RabbitMQ cluster using Bitnami images.
Comments
Post a Comment