This is the fourth and the final lesson in the Scalable EC2 consuming servers for SQS . In this lesson we will:
- Create an image out of the previously created EC2 instance.
- Define the lunch configuration that the scaling policy will use.
- Create a scaling policy that will increase the amount of EC2 instances when the increasing alarm is triggered by Cloud watch service, and the opposite when the decreasing alarm is triggered.
Creating the Image, AMI
Creating the image is easy. Just make sure that it is very ready to be functional when used without needing the developer to interfere. To create the image:
- Select the image instance in the running instances page in EC2.
- Click on “Actions”. Select “Image”, then “Create Image”.
- Follow the instruction, and give it a proper name, like “TestAutoScalingAMI”.
Define the Lunch Configuration
When you create a new EC2 instance, AWS asks you to define some parameters and configurations, like the policy, the security settings, and AMI used to lunch the instance. The Lunch configuration is creating these configurations and make it available for new instances. The scaling policy uses the lunch configurations to configure the created instances.
To create a new lunch configuration:
- From the side bar menu, under Auto Scaling tab, click “Lunch Configurations”.
- Click on “Create lunch configuration”.
- Choose “My AMIs”, and select the image you have created before. Next,
- Select the instance type. It is better to select in the free tier. Next.
- Give the configuration a name, “TestAutoScalingLunchConfiguration”. Select the policy you have created to access SQS service.
For this tutorial, we are done configuring. If you have anything special for your needs, feel free to navigate through the different options. Otherwise, go to review, and create the configuration.
Create Auto Scaling group
The final step is to create the Auto Scaling group.
- From the side panel click in Auto Scaling groups.
- Create Auto Scale Group.
- Select “Lunch Configuration”, and select your lunch configuration that you have just created. Next.
- Give it a name, anything. Make sure it starts with one. Select any subnet. Next.
- At the “Configure Scaling policies” step, all the magic happens.
- Click on “Use scaling policies to adjust the capacity of this group”.
- Scale between 1 and 3 instance. You can change this later, but we will use three only to prevent more costs.
- Click on the blue link below “Scale the Auto Scaling group using step or simple scaling policies”. This will expand to “Increasing Group Size” and “Decrease Group Size” options.
- For both options, select “Creating a Simple Policy”.
- For “Execute policy when” field:
- Increasing: select very old messages alarm.
- Decreasing: select few visible messages alarm.
- Make the actions to increase and decrease only one instance.
- In the “wait” field, set it to something reasonable like 300 seconds. This is the period that the scaling policy will hold before taking any new actions. The scaling group will not look into the alarms status in this period, thus, no increasing nor decreasing will happen then.
At this stage, no more configurations is needed for this tutorial. Feel free to navigate through the rest of the configurations to have an idea of what is going on. For now, review and create.
Try to lunch the client application that will send messages to the queue. Make sure that the interval between messages is 15 seconds. You will see that after a while no new instances is added other than the one initially created.
If you increase the rate of the messages sent by the client application, then the alarm status will change. This happened because the consuming server is slower than the client.
Keep monitoring the instances count from the monitoring panel in the scaling group page. This will give you insights of what is needed to be changed, like the triggering alarms.
The alarms defined in this tutorial do not perform the best. as the instances count keeps changing for the same messages rate. What do you think we can use to enhance?
As suggested before, you may use a programmable events from the consuming server. If the server finds the queue empty for several consecutive times, then that means that we do not probably need this instance. Think of other ways, and be creative 🙂
This is the end of this tutorial. Please feel free to add your thoughts and advice. Thanks for reading and watching 🙂