This post is part of a bigger topic Autoscaling Publishers in AWS.
In a previous post we talked about the Auto Scaling Groups, but we didn't go into details on the Scaling Policies. This is the purpose of this blog post.
As defined earlier, the Scaling Policies define the rules according to which the group size is increased or decreased. These rules are based on instance metrics (e.g. CPU), CloudWatch custom metrics, or even CloudWatch alarms and their states and values.
We defined a Scaling Policy with Steps, called 'increase_group_size', which is triggered first by the CloudWatch Alarm 'Publish_Alarm' defined earlier. Also depending on the size of the monitored CloudWatch custom metric 'Waiting for Publish', the Scaling Policy with Steps can add a difference number of instances to the group.
The scaling policy sets the number of instances in group to 1 if there are between 1000 and 2000 items Waiting for Publish in the queue. It also sets the group size to 2 if there are more than 2000 items in the queue.
This logic expects the Alarm is in state ALARM first, and then depending on the items in Waiting for Publish, it will set the group size accordingly.
For the other Scaling Policy, called 'decrease_group_size', the logic is a bit different. This is a simple scaling policy, which sets the group size to 0 (removes all publishers) if the Publish_Alarm is in state OK.
To notice in the image above the logic is incorrect, and I suspect this has to do with the fact AWS GUI cannot display this setup. Instead, we need to go to the CloudWatch Alarm setup GUI and setup the logic there, as per screenshot below:
Note the Actions for this alarm: 2 AutoScaling Actions, one for increase and one for decrease of group size.
For the decrease action: whenever the alarm is in state OK, perform action 'decrease_group_size', which means terminate all instances in the group.
For the increase action, whenever the alarm is in state ALARM, perform actions according to scaling policy with steps 'increase_group_size'.
In a previous post we talked about the Auto Scaling Groups, but we didn't go into details on the Scaling Policies. This is the purpose of this blog post.
As defined earlier, the Scaling Policies define the rules according to which the group size is increased or decreased. These rules are based on instance metrics (e.g. CPU), CloudWatch custom metrics, or even CloudWatch alarms and their states and values.
We defined a Scaling Policy with Steps, called 'increase_group_size', which is triggered first by the CloudWatch Alarm 'Publish_Alarm' defined earlier. Also depending on the size of the monitored CloudWatch custom metric 'Waiting for Publish', the Scaling Policy with Steps can add a difference number of instances to the group.
The scaling policy sets the number of instances in group to 1 if there are between 1000 and 2000 items Waiting for Publish in the queue. It also sets the group size to 2 if there are more than 2000 items in the queue.
This logic expects the Alarm is in state ALARM first, and then depending on the items in Waiting for Publish, it will set the group size accordingly.
For the other Scaling Policy, called 'decrease_group_size', the logic is a bit different. This is a simple scaling policy, which sets the group size to 0 (removes all publishers) if the Publish_Alarm is in state OK.
To notice in the image above the logic is incorrect, and I suspect this has to do with the fact AWS GUI cannot display this setup. Instead, we need to go to the CloudWatch Alarm setup GUI and setup the logic there, as per screenshot below:
Note the Actions for this alarm: 2 AutoScaling Actions, one for increase and one for decrease of group size.
For the decrease action: whenever the alarm is in state OK, perform action 'decrease_group_size', which means terminate all instances in the group.
For the increase action, whenever the alarm is in state ALARM, perform actions according to scaling policy with steps 'increase_group_size'.
Comments