AWS_EN

EC2 Auto Scaling – Simple Scaling based on CPU utilization

スポンサーリンク
EC2 Auto Scaling - Simple Scaling based on CPU utilization AWS_EN
スポンサーリンク
スポンサーリンク

EC2 Auto Scaling – Simple Scaling based on CPU utilization

The following pages cover the basics of EC2 Auto Scaling.

In this page, we will review the behavior of dynamic scaling.
There are three types of dynamic scaling in EC2 Auto Scaling

  • Simple Scaling
  • Step scaling
  • Target Tracking Scaling

In this page, we will check the behavior of Simple Scaling.
It scales the number of instances based on CPU usage.

For more information on step scaling, please refer to the following page.

For target tracking scaling, please refer to the following page

Environment

Diagram of EC2 Auto Scaling - Simple Scaling based on CPU utilization

Create an ALB and attach EC2 Auto Scaling in private subnets.

Set the number of Auto Scaling instances as follows

  • Minimum number: 1
  • Maximum number: 2
  • Desired number: 1

Set scaling to run based on CPU utilization.
Scale out when CPU utilization exceeds 30% and scale in when it falls below 30%.

The EC2 instance to be started in the Auto Scaling group, but it should be the latest version of Amazon Linux 2.
Install Apache from the yum repository on S3 and configure it to act as a web server.

Use SSM Session Manager to access the launched instance.

CloudFormation template files

Build the above configuration with CloudFormation.
The CloudFormation templates are located at the following URL

awstut-fa/087 at main · awstut-an-r/awstut-fa
Contribute to awstut-an-r/awstut-fa development by creating an account on GitHub.

Explanation of key points of the template files

This page focuses on how to configure Simple Scaling in EC2 Auto Scaling.

For information on how to attach resources in a private subnet to an ALB, please refer to the following page

For information on how to execute yum on instances in a private subnet, please refer to the following page

(Reference) Launch Template

Resources: LaunchTemplate: Type: AWS::EC2::LaunchTemplate Properties: LaunchTemplateData: IamInstanceProfile: Arn: !GetAtt InstanceProfile.Arn ImageId: !Ref ImageId InstanceType: !Ref InstanceType SecurityGroupIds: - !Ref InstanceSecurityGroup UserData: !Base64 | #!/bin/bash -xe yum update -y yum install -y httpd systemctl start httpd systemctl enable httpd ec2-metadata -i > /var/www/html/index.html LaunchTemplateName: !Sub "${Prefix}-LaunchTemplate"
Code language: YAML (yaml)

A Launch template is a resource for configuration information for EC2 instances to be launched within an Auto Scaling group.
You must create a Launch template or launch configuration to configure EC2 Auto Scaling.
However, it is currently deprecated to configure Auto Scaling using Launch configuration.

We strongly recommend that you do not use launch configurations. They do not provide full functionality for Amazon EC2 Auto Scaling or Amazon EC2. We provide information about launch configurations for customers who have not yet migrated from launch configurations to launch templates.

Launch configurations

These are basically the same configuration items as for EC2 instances.
For example, specify the AMI and instance type of the instance to be launched with the ImageId and InstanceType properties.

User data can be set with the UserData property.
This time we will install and activate Apache, write the instance ID in an HTML file, and set it in the Apache root page.

Auto Scaling Group

Resources: AutoScalingGroup: Type: AWS::AutoScaling::AutoScalingGroup Properties: AutoScalingGroupName: !Sub "${Prefix}-AutoScalingGroup" DesiredCapacity: !Ref DesiredCapacity LaunchTemplate: LaunchTemplateId: !Ref LaunchTemplate Version: !GetAtt LaunchTemplate.LatestVersionNumber MaxSize: !Ref MaxSize MinSize: !Ref MinSize VPCZoneIdentifier: - !Ref PrivateSubnet1 - !Ref PrivateSubnet2 TargetGroupARNs: - !Ref ALBTargetGroup
Code language: YAML (yaml)

No special settings are required for the Auto Scaling group in configuring Simple Scaling.

Set the number of instances to be created in the group as follows
Set the desired number to 1 in the DesiredCapacity property.
Set the maximum number to 2 in the MaxSize property.
Set the minimum number to 1 in the MinSize property.

Scaling Policy

Resources: ScalingPolicy1: Type: AWS::AutoScaling::ScalingPolicy Properties: AdjustmentType: ChangeInCapacity AutoScalingGroupName: !Ref AutoScalingGroup Cooldown: !Ref Cooldown PolicyType: SimpleScaling ScalingAdjustment: !Ref ScalingAdjustment1 ScalingPolicy2: Type: AWS::AutoScaling::ScalingPolicy Properties: AdjustmentType: ChangeInCapacity AutoScalingGroupName: !Ref AutoScalingGroup Cooldown: !Ref Cooldown PolicyType: SimpleScaling ScalingAdjustment: !Ref ScalingAdjustment2
Code language: YAML (yaml)

To configure Simple Scaling, two scaling policies are created.
The first policy is for scaling out and the second is for scaling in.

Set the type of scaling policy in the PolicyType property.
In this case, we specify “SimpleScaling” since this is a simple scaling.

You can set the cooldown period in the Cooldown property.
The explanation of the cooldown is as quoted below.

After your Auto Scaling group launches or terminates instances, it waits for a cooldown period to end before any further scaling activities initiated by simple scaling policies can start. The intention of the cooldown period is to prevent your Auto Scaling group from launching or terminating additional instances before the effects of previous activities are visible.

Scaling cooldowns for Amazon EC2 Auto Scaling

In this case, we specify “300” and wait 5 minutes for the next scaling to occur.

The ScalingAdjustment property is a parameter related to the adjustment value.
It is the amount by which the number of instances in the Auto Scaling group is increased or decreased when scaling is performed.
In this case, “1” and “-1” are specified for the two policies, respectively.

Set the scaling adjustment type with the AdjustmentType property.
This time, specify “ChangeInCapacity”.
The description of this type is quoted below.

ChangeInCapacity — Increment or decrement the current capacity of the group by the specified value. A positive value increases the capacity and a negative adjustment value decreases the capacity. For example: If the current capacity of the group is 3 and the adjustment is 5, then when this policy is performed, we add 5 capacity units to the capacity for a total of 8 capacity units.

Scaling adjustment types

In this configuration, one instance is started in the group during normal operation, but during scale-out, one additional instance is started to create a two-unit configuration, and during scale-in, one instance is removed to create a one-unit configuration.

CloudWatch Alarm

Resources: Alarm1: Type: AWS::CloudWatch::Alarm Properties: AlarmActions: - !Ref ScalingPolicy1 AlarmName: !Sub "${Prefix}-Alarm1" ComparisonOperator: GreaterThanOrEqualToThreshold Dimensions: - Name: AutoScalingGroupName Value: !Ref AutoScalingGroup EvaluationPeriods: !Ref AlarmEvaluationPeriod MetricName: CPUUtilization Namespace: AWS/EC2 Period: !Ref AlarmPeriod Statistic: Average Threshold: !Ref AlarmThreshold Alarm2: Type: AWS::CloudWatch::Alarm Properties: AlarmActions: - !Ref ScalingPolicy2 AlarmName: !Sub "${Prefix}-Alarm2" ComparisonOperator: LessThanOrEqualToThreshold Dimensions: - Name: AutoScalingGroupName Value: !Ref AutoScalingGroup EvaluationPeriods: !Ref AlarmEvaluationPeriod MetricName: CPUUtilization Namespace: AWS/EC2 Period: !Ref AlarmPeriod Statistic: Average Threshold: !Ref AlarmThreshold
Code language: YAML (yaml)

CloudWatch alarms act as triggers for scaling policy action.
Alarms are created for each scaling policy.

The first alarm is for the scale-out policy and the second alarm is for the scale-in policy.
This is specified in the AlarmActions property.

Set the target for metric measurement in the Dimensions property.
This time, to measure the CPU utilization of the Auto Scaling group, specify “AutoScalingGroupName” for Name and the ID of the group for Value.

This time, set the scaling to be started according to the CPU utilization.
By specifying “CPUUtilization” for the MetricName property, “AWS/EC2” for the Namespace property, and “Average” for the Statistic property, the average CPU utilization for the entire Auto Scaling group is measured.

The measurement period of CPU utilization is set with the Period property.
In this case, “60” is specified to measure every minute.

Threshold values are set with the ComparisonOperator, Threshold, and EvaluationPeriods properties.
For Alarm 1, specify “GreaterThanOrEqualToThreshold,” “30,” and “2,” respectively, to trigger when CPU usage reaches 30% or more for two consecutive times.
Alarm 2 specifies “LessThanOrEqualToThreshold”, “30”, and “2”, respectively, and is triggered when CPU utilization falls below 30% for two consecutive times.

Use CloudFormation to build this environment and check the actual behavior.

Create CloudFormation stacks and check resources in stacks

Create a CloudFormation stacks.
For information on how to create stacks and check each stack, please refer to the following page

After checking the resources in each stack, information on the main resources created this time is as follows

  • ALB: fa-087-ALB
  • DNS name of ALB: fa-087-alb-737613323.ap-northeast-1.elb.amazonaws.com
  • ALB target group: fa-087-albTargetGroup
  • Launch template: fa-087-LaunchTemplate
  • EC2 Auto Scaling group: fa-087-AutoScalingGroup
  • CloudWatch alarm1: fa-087-Alarm1
  • CloudWatch Alarm 2: fa-087-Alarm2

Confirm the created resource from the AWS Management Console.
Confirm the ALB.

Detail of ALB 1.

Confirm the DNS name, etc. of the ALB.

Confirm the Auto Scaling group.

Detail of EC2 Auto Scaling 1.

The desired/minimum number is 1 and the maximum number is 2. In other words, within the Auto Scaling group, one instance will be launched during normal operation and two instances during scale-out.

Check the scaling policy.

Detail of EC2 Auto Scaling 2.

You can see that two scaling policies have been created.
These policies are for scale-out/in.
You can also check the conditions that trigger the CloudWatch alarm, which is the trigger for the action of the two policies.

Detail of EC2 Auto Scaling 3.

Looking at the activity history of the Auto Scaling group, we can see that one instance was created in the group that was empty.

Detail of EC2 Auto Scaling 4.

Checking the instances in the group, we can see that one instance is indeed running.

The CPU utilization at this point is as follows.

Detail of EC2 Auto Scaling 5.

Since the CPU utilization is less than 30%, scale-out will not be started.

Check Operation

Normal

Now that everything is ready, access the ALB.

Detail of ALB 2.

The instance has been accessed.
You can see that the Auto Scaling group is indeed attached to the ALB.

Scale-out

Check the behavior during scale-out.
Use SSM Session Manager to access the instances in the Auto Scaling group.

% aws ssm start-session --target i-013a345e86bf1eda1 Starting session with SessionId: root-0d5c2cb28ca211e00 sh-4.2$
Code language: Bash (bash)

For more information on SSM Session Manager, please refer to the following page

Use the yes command to increase the CPU utilization of the instance.

sh-4.2$ yes > /dev/null &
Code language: Bash (bash)

After waiting for a while, CPU utilization exceeds 30%.
Now the conditions for scale-out to start have been met.

Detail of EC2 Auto Scaling 7.

The activity history of the Auto Scaling group shows that a new instance has been started.

Detail of EC2 Auto Scaling 8.

Checking the instances in the group, we see that two instances have indeed been launched.

We access the ALB again.

Detail of EC2 Auto Scaling 9.

In addition to the first instance, we were able to access the second instance alternately.
As described above, we see that the policy for scale-out has acted and a second instance has been created in the Auto Scaling group.

Scale-In

We wait for a while to check the behavior during scale-in.

Detail of EC2 Auto Scaling 10.

With the second instance activated, the average CPU utilization for the entire Auto Scaling group has dropped below 30%.
The conditions for scale-in to start have now been met.

Detail of EC2 Auto Scaling 11.

Looking at the activity history of the Auto Scaling group, we can see that one instance has been deleted.

Detail of EC2 Auto Scaling 12.

Checking the instances in the group shows that indeed one instance was started.
The instance that was deleted is the instance whose CPU utilization was increased by the yes command.

Check the CPU utilization again.

Detail of EC2 Auto Scaling 13.

The CPU utilization has returned to less than 1%.
This is because the yes command, etc. is not executed on the instance that is currently running.
As described above, we see that the policy for scale-in has acted and one instance in the Auto Scaling group has been deleted.

Summary

We have confirmed the behavior of Simple Scaling, a type of dynamic scaling of EC2 Auto Scaling.

タイトルとURLをコピーしました