Skip to main content

MQTT protocol inside Azure - RabbitMQ on top of AKS


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

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine: threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration: TeamCity .NET 4.51 EF 6.0.2 VS2013 It see

Navigating Cloud Strategy after Azure Central US Region Outage

 Looking back, July 19, 2024, was challenging for customers using Microsoft Azure or Windows machines. Two major outages affected customers using CrowdStrike Falcon or Microsoft Azure computation resources in the Central US. These two outages affected many people and put many businesses on pause for a few hours or even days. The overlap of these two issues was a nightmare for travellers. In addition to blue screens in the airport terminals, they could not get additional information from the airport website, airline personnel, or the support line because they were affected by the outage in the Central US region or the CrowdStrike outage.   But what happened in reality? A faulty CrowdStrike update affected Windows computers globally, from airports and healthcare to small businesses, affecting over 8.5m computers. Even if the Falson Sensor software defect was identified and a fix deployed shortly after, the recovery took longer. In parallel with CrowdStrike, Microsoft provided a too