Scaling Policies
- https://docs.aws.amazon.com/autoscaling/ec2/userguide/scaling_plan.html
Manual Scaling
- Maintain a current number of instances all the time
- Manually change ASG min/des/max, attach/detach instances
Cyclic (schedule based)
- Predictable load change – ex: increase capacity every Tuesday night
- Configure action, desired capacity, unique date/time
- Can edit / update action
On-demand / Dynamic (event
based)
- https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html
- Scaling in response to an event / alarm
- Alarm – watches over a single metric (CPU, memory, network in/out)
- Need a scale out and a scale in policy in response to an alarm
- Requires Cloud Watch to monitor/generate an alarm
Monitoring
- EC2 Monitoring
§ Basic Monitoring - by default EC2’s in ASG will send metrics to Cloud Watch every 5 min.
- Scaling is the ability to increase or decrease the compute capacity of your application. Scaling starts with an event, or scaling action, which instructs an Auto Scaling group to either launch or terminate Amazon EC2 instances.
- Can select a scaling policy when defining an ASG
- Scale Out / Scale In
- Can select a scaling policy when defining an ASG
- Scale Out / Scale In
- Maintain a current number of instances all the time
- Manually change ASG min/des/max, attach/detach instances
- Predictable load change – ex: increase capacity every Tuesday night
- Configure action, desired capacity, unique date/time
- Can edit / update action
- https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html
- Scaling in response to an event / alarm
- Alarm – watches over a single metric (CPU, memory, network in/out)
- Need a scale out and a scale in policy in response to an alarm
- Requires Cloud Watch to monitor/generate an alarm
- Simple Scaling
§ Adjustment up/down in response to an alarm
§ Wait for cool-down timer to expire before responding to more alarms (default 300 sec). During this time ASG will not respond to more additional alarms to prevent EC2 count increasing senselessly
§ Cool down time is not supported from scheduled scaling and for step-on demand
- Step Scaling
§ Supports multiple steps/adjustment:
§ A lower bound for the metric value
§ An upper bound for the metric value
§ The amount by which to scale, based on the scaling adjustment type
§ Ex: CPU 70%-80% -> Add 5 EC2’s
CPU 60%-70% -> Add 5 EC2’s
CPU 50%-60% -> Remove 5 EC2’s
- Warm up timer – time it takes newly launched instance to be ready and contribute to the watched metric
- With step scaling policies, you can specify the number of seconds that it takes for a newly launched instance to warm up. Until its specified warm-up time has expired, an instance is not counted toward the aggregated metrics of the Auto Scaling group. While scaling out, AWS also does not consider instances that are warming up as part of the current capacity of the group. Therefore, multiple alarm breaches that fall in the range of the same step adjustment result in a single scaling activity. This ensures that we don't add more instances than we need.
- Target Scaling
§ Works like a thermostat – set target metric (CPU etc.), add/remove EC2’s to meet the metric
§ Adjustment up/down in response to an alarm
§ Wait for cool-down timer to expire before responding to more alarms (default 300 sec). During this time ASG will not respond to more additional alarms to prevent EC2 count increasing senselessly
§ Cool down time is not supported from scheduled scaling and for step-on demand
- Step Scaling
§ Supports multiple steps/adjustment:
§ A lower bound for the metric value
§ An upper bound for the metric value
§ The amount by which to scale, based on the scaling adjustment type
§ Ex: CPU 70%-80% -> Add 5 EC2’s
CPU 60%-70% -> Add 5 EC2’s
CPU 50%-60% -> Remove 5 EC2’s
- Warm up timer – time it takes newly launched instance to be ready and contribute to the watched metric
- With step scaling policies, you can specify the number of seconds that it takes for a newly launched instance to warm up. Until its specified warm-up time has expired, an instance is not counted toward the aggregated metrics of the Auto Scaling group. While scaling out, AWS also does not consider instances that are warming up as part of the current capacity of the group. Therefore, multiple alarm breaches that fall in the range of the same step adjustment result in a single scaling activity. This ensures that we don't add more instances than we need.
- Target Scaling
§ Works like a thermostat – set target metric (CPU etc.), add/remove EC2’s to meet the metric
- EC2 Monitoring
§ Basic Monitoring - by default EC2’s in ASG will send metrics to Cloud Watch every 5 min.
§ Detailed Monitoring @ 1 min is
optional but chargeable
§ If an auto scaling launch configuration is created via the AWS CLI - Detailed Monitoring on by default
§ to change from Basic to Detailed – delete ASG and create a new one. Will only affect NEW EC2’s, not the existing ones
§ If an auto scaling launch configuration is created via the AWS CLI - Detailed Monitoring on by default
§ to change from Basic to Detailed – delete ASG and create a new one. Will only affect NEW EC2’s, not the existing ones
- ASG
Monitoring
§ Needs to be enabled
§ ASG will send group (incl underlying EC2) motoring detail to CloudWatch every 1 min
§ Carful to make sure that monitoring periods for the EC2’s and Policy (under CloudWatch – period it reaches out to check for certain metric) match
§ Ex: If EC2 monitoring is basic at 5 min (in launch configuration), make sure ASG is at 300 sec
§ Needs to be enabled
§ ASG will send group (incl underlying EC2) motoring detail to CloudWatch every 1 min
§ Carful to make sure that monitoring periods for the EC2’s and Policy (under CloudWatch – period it reaches out to check for certain metric) match
§ Ex: If EC2 monitoring is basic at 5 min (in launch configuration), make sure ASG is at 300 sec
- SCALING POLICY alarm monitoring
(60 or 300sec, etc.) needs to match the EC2 monitoring interval (1 or 5 min,
etc.)
No comments:
Post a Comment