Dynamic Scaling Made Simple: SQS Integration with Cloud Watch, SNS, and Autoscaling Group
Autoscaling is a core concept in AWS that allows you to scale EC2 instances up and down based on specific metrics and certain conditions. Creating an autoscale group with auto-scaling enabled is one of the simplest ways to achieve autoscaling. But what if you want more control over your auto-scale groups? What if you want to add some logic around when particular service failures trigger an increase in your automatic scaling usage?
In this blog, you will integrate Simple Queue Service with Cloud watch alarm to trigger an Autoscaling group to handle the load of your application. The scenario is like you are having an Application that triggers the SQS queue as soon as the load on the application becomes heavy, and as soon as the threshold for the number of messages displayed on the SQS increases by a certain number, It triggers the Cloud Watch Alarm to scale up the load and creates an instance and when the load becomes less or stable it triggers the cloud watch alarm to scale in the application based on the SQS display message.
This scenario is one of the best examples of how we can autoscale based on some real use cases. In this Blog, I'll be manually increasing and decreasing the number of messages, but you can use an application tier with the lambda function to trigger the SQS message.
This blog will be a hands-on demonstration, so if you’d like to follow along be sure you have the setup of an Active AWS account.
Let’s start the adventure now!
CREATE LAUNCH TEMPLATE
Launch Templates are the templates of configuration details that contains the type of instance resource we want to create when there will be the requirement to scale up.
STEP 1: Go to the launch Template page on the AWS Management Console.
STEP 2: Select the type of instance, AMI, Network, and storage you want your fleet of EC2 instances to have and Click Create Launch Template. If you want to configure a Web server in the instance use the use script to install and launch the web server.
#!/bin/bash
yum update -y
yum install -y httpd.x86_64
systemctl start httpd.service
systemctl enable httpd.service
echo "Hello World from $(hostname -f)" > /var/www/html/index.html
CREATING AN AUTOSCALING GROUP
An autoscaling group can be useful to scale up and down your architecture during the time of sudden traffic or failover. Here you will first create a simple auto-scaling group by selecting launch templates and configuration details and then create a dynamic scaling policy for scale-up and scale-down.
STEP 1: Go to the Auto Scaling group in AWS Management Console and click Create AutoScaling Group.
STEP 2: Give the name and add Launch Template. Click Next
STEP 3: Select the VPC and the subnets where the scaled ec2 instances will be launched, and keep the rest setting by default. Click Next
STEP4: Provide a desired, minimum, and Maximum count of instances you want.
STEP 5: Add Tags for the autoscaling group to uniquely identify the instance launched by it. Keep rest settings by default and create the autoscaling group.
The below picture shows that one instance is already launched as we set the desired as 1.
STEP 6: Creating Dynamic Scaling Policy, This policy helps in the automatic scaling up and in the instances based on some metrics or rules. There are three types of Scaling policy Target Tracking, simple Scaling, and Step Scaling. You will be using Step Scaling as it provides better control and is cost-effective. Before Creating Dynamic Policy you have to create the Simple Queue, Cloudwatch Alarm, and SNS topic.
CREATING SQS QUEUE
It’s a service that provides a queue for applications to place messages for asynchronous processing or queuing where messages are processed in a non-blocking fashion. Applications can send messages to a queue to further do some processing. You will be creating a vanilla Simple Queue with default settings to do this demo.
STEP 1: Go to the Simple Queue Service page in AWS Management Console.
STEP 2: Give the name and keep the rest settings as default and click Create.
You have successfully created the queue. The available message shows the number of messages in the queue.
CREATING A SNS TOPIC
The Simple Notification Service SNS integrates notifications with a variety of services, including Amazon S3, Amazon DynamoDB, and others. These services notify customers whenever something happens in their AWS environments, whether that’s an object being updated (with an object dump), an object being deleted (with an object delete), or simply an email notification being sent.
STEP 1: Go to Simple Notification Service in the AWS Management Console. Click Create Topic
STEP 2: Choose the standard type as you just need SNS to send notifications to emails for alarm. Keep Rest settings as Default and click Create
Step 3: Now we have to create a subscription for the Topic, which have multiple options for integration.
STEP 4: Select the protocol as Email and provide the email to which the notifications will be sent.
STEP 5: Check your Registered email to allow SNS to send notifications.
Now as soon as an alarm will be triggered, an email will be sent to the subscribed email address with the details of the event.
CREATING CLOUD WATCH ALARMS
Amazon Cloudwatch service is a great resource manager and a monitoring tool. I have been using this in AWS my life by monitoring various aspects i.e. network connections, applications, resources, and storage to provide me an overview of any issue for my use case. Here it will be used with SQS and Auto Scaling Group. You will be creating two alarms one for scaling up and the other for down.
CREATING SCALE-UP ALARM
STEP 1: Go to the Cloud Watch page on the AWS Management Console.
STEP 2: Click on the Create Alarm.
STEP 3: Choose the metrics you want to monitor, Click the SQS -> Queue Metrics, then search and Select the Approximate Number of Message Visible query for the SQS queue you just created.
STEP 4: Give the Metric Name and Statistics you want to measure the alarm in, eg: the period of 1 minute, and Choose the Maximum.
STEP 5: Select the static threshold type with the condition, if the datapoints go above 9 datapoints for 1 minute then trigger the alarm.
STEP 6: Select the Trigger as “In alarm” state and choose the SNS topic we just created above. Rest keep the settings as Default and click Next.
STEP 7: Give the name and description of the alarm. Review and click Create.
You have successfully created the Scale-up alarm
CREATING SCALE IN ALARM
The Initial Steps for selecting metrics are the same as the scale-up alarm. In this Alarm, you are triggering the scale in process i.e. when the message becomes stable or lesser than stable.
STEP 1: Choose the Statistics and the period.
STEP 2: In the condition section select lesser than 9, if the data points value goes below 9 then trigger the alarm. Rest Part is the same as the Scale Up Alarm.
You have successfully created two alarms, Now let’s connect these alarms with the autoscaling group dynamic scaling Policy.
After Creating all the components let's get back to the dynamic Autoscaling Policy part.
CREATING DYNAMIC SCALING POLICY
STEP 1: Create a scale-up policy, choose Step Scaling, and Select my-sqs-cloud watch-alarm from the dropdown menu. Select Action as Add and Capacity 1 when the threshold alarm reaches greater than the 9 datapoints value for 1 minute. Click Create.
STEP 2: Create Scaling Policy for scale in, Choose Step Scaling, and select my-cloudwatch-sqs-ScaleIn alarm from the dropdown. Select Action as Remove 1 when the alarm rule is breached. Click Create.
You have successfully configured your AutoScaling Group with 2 Dynamic Scaling Policy to manage your workload.
Let's Test the Setup Now.
TESTING THE SETUP
You have successfully created all the components of the architecture let's test the setup now. I will manually Send Some messages to the queue to simulate an increase in traffic, which can be done automatically using application tier and lambda function
Click on Send a message after writing your message. Send more than 9 messages to trigger the scale-up alarm.
Till Now no new instance is created other than the desired default one.
Wait For about 1 minute for the Cloudwatch alarm to go into the alarm state.
You can see the sudden increase in message display value, and a new instance is launched by the autoscaling group.
A mail is also sent to the subscribed email address when the Alarm is triggered, and the scaling values are reset automatically by the scaling policy.
If we further increase the message to 13, You can see a sudden spike in the graph, which further triggers the auto-scaling group to launch 1 more instance.
If we Delete some message here manually which can be done by other means i.e. in real life this means that the application is again stable or there is lesser demand for the application, This will trigger the scale in alarm which further terminates the instance based on the value of the metric.
After 1 minute the scale-in alarm will be triggered which sends an email to the subscribed email.
According to the rule if the message value is less than 9 then the scale in policy should terminate the instances.
You can see that the instance created before is automatically terminated as soon as the scale in alarm is triggered to bring back the architecture to a normal state.
CONCLUSION
In conclusion, integrating Amazon Simple Queue Service (SQS) with the Auto Scaling Group, CloudWatch, and Amazon SNS opens up a world of possibilities for efficient and automated instance scaling in response to SQS metrics. This powerful combination allows businesses to dynamically manage their infrastructure, ensuring optimal performance and resource utilization.
However, it is essential to carefully configure and test the integration to align with the unique requirements of each application and its workload patterns. Regularly monitoring the system’s behavior and adjusting scaling policies based on real-world performance is crucial to maximizing the benefits of this integration.
Thanks For Reading!
