Azure Container Apps – service bus [part 6]

Azure Container Apps – service bus, works together like a perfect couple! Achieving integration is a breeze, and the impact on performance is truly remarkable. In this guide, I’ll walk you through the steps to set up this integration and share the results of my performance tests. Rest assured, all the necessary resources are at your disposal. You can access the entire series on Azure Container Apps right here. If you find my articles valuable, I would greatly appreciate your support through likes or comments on LinkedIn. Thank you!

Azure Container Apps – service bus – integration

Before delving into the integration setup, you can access all the necessary source files by downloading them from this location. If you’re unsure about how to configure Azure Container Apps with Terraform, please refer to my previous post titled “Azure Container Apps – Using Terraform to Create [Part 1].”

As you’re already aware, establishing integration between Azure Container Apps and Azure Service Bus is a straightforward process. So, what do we need to set up? Take a look at the Terraform code snippet below:

Azure Container Apps – service bus Terraform configuration
Azure Container Apps – Azure Service Bus Terraform configuration

Configuration Steps Description:

  1. Establish a secret for the Azure Service Bus connection string. In the subsequent steps, we will reference the name of this secret.
  2. Configure a custom scaling rule for your Azure Container Apps, enabling them to scale up or down based on queue length. This rule utilizes the “messageCount” property to calculate the number of replicas needed. For example, if you set “messageCount” to 20 and there are 1000 messages in the queue, your Container App will scale to 25 replicas. Why? Because the maximum number of replicas is set to 25 🙂
  3. Configure authentication for the scaling rule using the secret you created. It’s important to note that the authentication for the scaling rule is distinct from the authentication your application uses to connect to the Azure Service Bus. You still need to apply authentication in your application for that purpose. The connection string mentioned here is solely used for calculating the replica count.

Azure Container Apps – service bus – performance

I conducted a total of five comprehensive performance tests. In the initial four tests, there were 11,000 messages in the service bus, and the resource limits were constrained to 0.25 CPU and 0.5 GiB of memory. The testing procedure followed this sequence: reading a message, simulating a 150 ms workload, and then marking the message as completed in the queue. Below, you’ll find a diagram illustrating the message count at one, two, and three minutes after the execution commences.

Azure Container Apps – service bus performance
Azure Container Apps – Azure Service Bus performance

As observed, the job was completed more swiftly with 25 replicas, which comes as no surprise. What’s even more intriguing is that all replicas were fully operational within just 30 seconds of applying the custom scale rule. In my view, this is an outstanding outcome. Azure Container Apps allows scaling up to 300 instances, making it an exceptionally potent service!

For my next test, I increased the message count to 100,000. I maintained the Azure Service Bus custom scale rule at a message count of 1,000, while keeping the other settings consistent with the previous execution.

Azure Container Apps – service bus performance
Azure Container Apps – Azure Service Bus performance

As evident, the consumption of my 100,000 messages took place in under 10 minutes. It’s essential to bear in mind that there’s an additional 150 ms delay per message, designed to simulate actual work execution. I increased the number of queue consumer replicas to 25. It’s worth noting that the rate at which messages are consumed follows a fairly consistent linear pattern, allowing for accurate predictions of your application’s behavior. This makes estimating the required number of replicas a more straightforward task.

What was the procedure for conducting the test?

How did I carry out this test? If you wish to replicate it, here are the steps you need to follow:

  1. Obtain the sample apps and Terraform scripts by downloading them from this location.
  2. Run the Terraform script found in the “2_terraform/step_1” directory using a straightforward “terraform apply” command.
  3. Once the script completes its execution, use the following command to retrieve the secret values from the Terraform output.
terraform output -json
  1. Create a Docker image for the application used to insert messages into Azure Service Bus. You can find the application in the following directory: “1_samples/AddMessages.” Execute the Docker command provided below.
docker build -t addmessages:1 .
  1. After the build, run the image with env variables:
docker run --env serviceBusConnectionString='#VALUE_FROM_STEP_3#' --env serviceBusQueues='test1|test2|test3|test4' -e messageCount=10000 addmessages:1
  1. You have the flexibility to customize the “serviceBusQueues” and “messageCount” parameters to align with your specific requirements.
  2. Next, we will create an image for the message consumer. To do this, navigate to the following directory: “1_samples/ContainerAppsServiceBusSample,” and then execute the following command:
az acr build --registry #ACR_NAME_FROM_STEP_3# --image messagereader:1 .
  1. Once the image is successfully created, you can proceed to create an Azure Container App. To do this, navigate to the directory “2_terraform/step_2” and initiate the command as follows:
terraform apply -var 'servicebus_queueName=test1' -var 'servicebus_namespace=#VALUE_FROM_STEP_3#' -var 'servicebus_messageScaleRule=500' -var 'service_bus_connection_string=#VALUE_FROM_STEP_3#' -var 'acr_url=#VALUE_FROM_STEP_3#' -var 'image_name=messagereader:1' -var 'user_managed_idenity_resource_group=#VALUE_FROM_STEP_3#'
  1. Upon completing the resource creation, your Azure Container App will commence the process of message consumption from the Azure Service Bus. You have the flexibility to modify parameters such as “maxReplicas,” “messageScaleRule,” and queue names to implement various configurations. To conduct a different test setup, you can easily rerun the command provided above with the desired parameter adjustments.

User Managed Identity usage

Please take note that within the scripts located in “2_terraform/step_1,” a User Managed Identity is established with AcrPull permissions from the Azure Container Registry. This identity will be employed by an Azure Container App for image retrieval from the registry, serving as an excellent illustration of User Managed Identity utilization.

Summary

In this article, you’ve learned how to seamlessly integrate and scale Azure Container Apps in conjunction with Azure Service Bus. This service proves to be highly capable of handling substantial message volumes. In my tests, it efficiently processed 12,000 messages within a 60-second interval, with a delay of 150 milliseconds per message. Remarkably, I achieved this performance using only 25 replicas, even though you have the option to scale up to 300 replicas.

I genuinely hope you found this information valuable. If you did, I would greatly appreciate your support through actions like Liking, Commenting, or becoming a follower on my LinkedIn profile. Your engagement means a lot to me.

You can access all the articles in this series right here.

Leave a Reply

Your email address will not be published. Required fields are marked *