# Amazon EC2 Auto Scaling

# 问题引入

当我们做一个大规模,高并发网站时。一个核心问题是,我们有多少用户,我们需要提供多少资源来满足到我们的客户。

我们是无法准确评估用户的使用数量的。

其实,大部分网站的访问流量都是有周期性的,动态变换的。存在波峰和波谷。如果,我们根据波峰对流量做一个猜测,猜测往往是不准的,会造成大量的资源浪费。如果,根据波谷对流量做一个猜测,往往又无法满足实际的需求。这样的话,就对我们的资源使用提出了一个新的需求及 弹性收缩

# 弹性收缩

用户量大时提供多的资源,用户量小时提供少的资源。尽量避免资源的浪费,同时又满足实际的流量请求。不需要再根据流量猜测资源。

# Auto Scaling

  • 可以动态的帮你增加,收缩 Amazon EC2 资源
  • 非常适合周期性流量波动的应用程序。
  • 无需额外付费

# Auto Scaling 和 Amazon ELB 配合工作

弹性伸缩三剑客

Auto Scaling GroupAmazon ELB 要想一起工作,还需要搭载 CloudWatch 监控服务一起配合使用。

Amazon ELB 可以把一些延迟数据或计算资源的CPU等使用数据收集到 CloudWatch 上面。

CloudWatch 可以对这些收集到的数据做一个警报,可以根据你设置的阈值,自动给出告警。当达到阈值时,就会给出一个警报,会把警报发送给 Auto Scaling Group 弹性伸缩组服务。

Auto Scaling Group 收到警报后,会根据本身已经定义的一个 模板,启动一个计算节点。把计算资源启动好,然后就可以把计算资源注册到 Amazon ELB 负载均衡服务里面。这个时候就 Scale Out 横向扩展了。

同样的当计算资源访问量下来的时候,与上面的过程一样,只不过是 Auto Scaling Group 把这个计算资源关闭。

上面三个服务,也称为 AWS 弹性伸缩三剑客。

更新时间: 6/16/2020, 5:11:40 PM