Target tracking scaling
Target tracking scaling计算CloudWatch某个Metric的平均值，当大于或小于设置的目标值时，触发扩缩容操作
设置多个target tracking scaling policy
通常线上会关注多个指标，例如CPU利用率、连接数、网络流量等等，可以为ASG设置多个不同policy，让它们一起协作实现更灵敏的扩容
ASG的出发点是保证业务可用性，所以对扩容和缩容，它的行为是不同的：
- 如果任何一个策略触发了扩容，则ASG会扩容
- 只有所有策略触发缩容后，ASG才会缩容
AWS这么设计，一部分考虑也是为了增加帐单(逃)
Target tracking scaling实验
首先把上一节的capacity做调整：
把Desired capacity调成1，这样仅剩下一台EC2， 便于我们登录上去模拟CPU负载高的场景(只需要登录一台即可)：
创建新的dynamic scaling policy:
选择Target tracking scaling，有四种类型的metric，选择CPU即可：
由于上一节设置了默认的warmup时间，所以这里不需要再单独设置：
点击创建，完成后在Automatic scaling的页面看到新创建的policy：
当创建一个ASG policy时，会在CloudWatch alarm里自动创建两条规则，一条是scale in相关的，另一条是scale out相关的。我们看到scale in相关的规则是检测CPU使用率小于35%:
测试scaling policy是否生效
由于第一步设置了Desired capacity为1， 所以此时只剩下1台EC2， 找到它的公网IP并登录：
登录上去后，安装压测工具：
sudo amazon-linux-extras install epel -y
sudo yum install stress -y
安装完成后，执行压测，让CPU使用率达到100%：
sudo stress --cpu 2 --timeout 600
过段时间后，查看EC2的监控，此时CPU使用率飙升：
在CloudWatch Alarm页面也触发了相应的告警：
此时 ASG会一台一台的启动新机器：
在activity history中也能查看到对应的事件：
缩容测试
将EC2上的压测脚本停止。
缩容时策略会相对生效的慢一些，因为CloudWatch Alarm对于缩容规则生效设置了15分钟：
等待15min后，发现EC2从3台重新降为1台：
