This is a three part series which explains how one should go about autoscaling and deployments in AWS ECS.
Note: Throughout the entire series, we will be discussing ECS(EC2) and not ECS Fargate, so when I say ECS please read it ECS(EC2).
The series is divided in below three parts:
I. Autoscaling in AWS ECS.
II. ECS Blue/Green Deployment.
III. ECS Rolling Update deployment.
This blog is first part of this series.
Autoscaling in ECS(EC2):
When you choose a container orchestration technology, the very important part to decide is how well that technology behaves in case of variable load.
In peak load it should scale up flawlessly without incurring any downtime and in minimal load it show scale down to cut down on the bill.
Note: In case of ECS with Farget, autoscaling is managed by ECS automagically and we don’t need to intervene in any manner whatsoever.
Let’s jump right in and discuss how well AWS ECS handles the autoscaling.
Autoscaling happens at two levels in ECS:
1. Cluster level autoscaling
2. Service level autoscaling
- Cluster level autoscaling:
This scaling comes in picture whenever the cumulative tasks in the cluster hit the minimum or maximum load limit which trigger a scaling event in ASG.
AWS ECS makes use of EC2 Autoscaling Group (ASG) to handle the autoscaling which is natively available to it.
There are two ways autoscaling can be configured in ECS:
1. Manual Autoscaling
2. ECS Cluster Auto Scaling (CAS)
1.1. Manual Autoscaling:
I know, ‘manual+auto’ scaling doesn’t sound too well together but stay with me and you will know what is manual in this autoscaling.
As the name suggests, in this type of scaling, most of the things have to be configured manually.
You need to follow below steps for this setup:
— You need to create an ASG.
— Setup Scaling Policies.
— Configure the ASG to be associated with ECS cluster with scaling policies as shown below:
Setting up scaling based on CPU using Target Tracking policies:
aws autoscaling put-scaling-policy --auto-scaling-group-name ASG-NAME --policy-name CPU-POLICY --policy-type TargetTrackingScaling --target-tracking-configuration file://CPU-Tracking-Policy --region AWS-REGION
Contents of file ‘CPU-Tracking-Policy’:
Setting up scaling based on memory using Target Tracking policies:
aws autoscaling put-scaling-policy --auto-scaling-group-name ASG-NAME --policy-name MEMORY-POLICY --policy-type TargetTrackingScaling --target-tracking-configuration file://Memory-Tracking-Policy --region AWS-REGION
Contents of file ‘Memory-Tracking-Policy’:
Note: Make note of ‘ — policy-type TargetTrackingScaling’ in the command and ‘“TargetValue”: 80’ in the policy document.
The provided commands will create a scaling policy of type ‘Target Tracking’. Which means that whatever the ‘TargetValue’ is specified in the policy (80 in our case),
ASG will try to maintain that. For example if CPU goes beyond 80% it will scale up and if goes below 80% it will trigger a scale in event.
Make sure you setup the ‘Default cool down’ parameter correctly in the ASG to avoid the delayed or hasty scaling actions.
These policies will monitor the ECS cluster’s CloudWatch metric and notify the ASG when to trigger the scaling activity.
1.2. ECS Cluster Auto Scaling (CAS):
Recently AWS has introduced a new scaling mechanism which takes off a lot of load from us to manage the scaling parameter and ECS takes care of autoscaling automatically and in a much better managed way.
More on this on part III of this series. https://nsrblogs1387.medium.com/title-part-iii-of-iii-ecs-rolling-update-deployment-ae844d28aa62
2. Service Level Autoscaling:
In ECS we define the CPU and Memory for every task in the task definition.
What happens when multiple hits to underlying resources have consumed these resources.
In such case, we can configure the scaling on Service Level.
In ECS we can define, for example, set the target value for Service CPU to 80%. So when 80% CPU of this service is consumed a new task will be triggered.
Similar to ASG we configure Cool Down period here as well.
Next: Part II of this series will explain ECS Blue/Green Deployment and how it is different from Rolling Update Deployment. https://nsrblogs1387.medium.com/part-ii-of-iii-ecs-blue-green-deployment-aa3db5b5a993