应用程序架构的 Auto Scaling 优势 - Amazon A EC2 uto Scaling

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

应用程序架构的 Auto Scaling 优势

将 Amazon A EC2 uto Scaling 添加到您的应用程序架构中是最大限度地发挥 AWS 云优势的一种方式。当您使用 Amazon A EC2 uto Scaling 时,您的应用程序将获得以下好处:

  • 提高容错能力。Amazon A EC2 uto Scaling 可以检测实例何时运行状况不佳,将其终止,然后启动实例来替换它。您也可以将 Amazon A EC2 uto Scaling 配置为使用多个可用区。如果一个可用区不可用,Amazon A EC2 uto Scaling 可以在另一个可用区中启动实例以进行补偿。

  • 提高可用性。Amazon A EC2 uto Scaling 有助于确保您的应用程序始终具有适当的容量来处理当前的流量需求。

  • 加强成本管理。Amazon A EC2 uto Scaling 可以根据需要动态增加和减少容量。由于您需要为所使用的EC2实例付费,因此您可以通过在需要时启动实例并在不需要时将其终止来节省资金。

示例:覆盖可变需求

要演示 Amazon A EC2 uto Scaling 的一些好处,可以考虑在上面运行一个基本的 Web 应用程序 AWS。此应用程序允许员工搜索可用于开会的会议室。每周开始和结束时段,此应用程序的使用率最低。每周中期,有更多的员工安排会议,因此对此应用程序的需求会显著提高。

下图显示此应用程序的容量在一周中的使用情况。

对应用程序的容量需求的示例。

按照传统做法,可通过两种方式为这些容量变化做好规划。第一种选择是添加足够多的服务器,以便应用程序始终具有足够的容量来满足需求。但是,这种做法的缺点是应用程序在某些天并不需要这么多容量。额外容量闲置不用,并且实际上提高了使应用程序保持运行的成本。

演示购买超过需求的容量可能导致欠缺成本效率的示例。

第二种选择是采用处理应用程序平均需求所需的容量。这种做法成本更低,因为不用购买仅仅偶尔使用的设备。然而,这样做的风险是:当对应用程序的需求超过其容量时,可能造成糟糕的客户体验。

演示购买少于需求的容量可能导致糟糕客户体验的示例。

通过将 Amazon A EC2 uto Scaling 添加到此应用程序,您就有了第三种选择。您可以仅在需要时才向应用程序添加新实例,并在不再需要这些实例时终止它们。由于 Amazon A EC2 uto Scaling 使用EC2实例,因此您只需在使用实例时为所使用的实例付费。您现在有了一个具有成本效益的架构,可在尽量减少支出的同时提供最佳客户体验。

此示例展示了 Amazon A EC2 uto Scaling 如何根据需要调整容量。

示例:Web 应用程序架构

在常见的 Web 应用程序场景中,您同时运行应用程序的多个副本来满足客户流量。您的应用程序的这些多个副本托管在相同的EC2实例(云服务器)上,每个副本都处理客户请求。

Amazon A EC2 uto Scaling 代表您管理这些EC2实例的启动和终止。您可以定义一组标准(例如 Amazon CloudWatch 警报),用于确定 Auto Scaling 组何时启动或终止EC2实例。将 Auto Scaling 组添加到网络架构有助于提高应用程序的可用性和容错能力。

具有 Auto Scaling 组的基本三层架构。

您可以根据需要创建任意数量的 Auto Scaling 组。例如,您可以为每个层创建一个 Auto Scaling 组。

要在您的 Auto Scaling 组的各实例之间分配流量,可在您的架构中引入一个负载均衡器。有关更多信息,请参阅 Elastic Load Balancing

示例:在可用区之间分配实例

可用区是给定 AWS 区域中相互隔离的站点。每个区域都有多个可用区,旨在为该区域提供高可用性。可用区相互独立,因此,设计为使用多个可用区的应用程序可以提高应用程序的可用性。有关更多信息,请参阅 Amazon EC2 Auto Scaling 中的恢复功能

可用区由 AWS 区域 代码和字母标识符进行标识(例如,us-east-1a)。如果您创建VPC和子网而不是使用默认子网VPC,则可以在每个可用区中定义一个或多个子网。每个子网都必须完全位于一个可用区之内,不能跨越多个可用区。有关更多信息,请参阅《亚马逊VPC用户指南》中的 “亚马逊VPC工作原理”。

创建 Auto Scaling 组时,必须选择要在其中部署 Auto Scaling 组的VPC和子网。Amazon A EC2 uto Scaling 在您选择的子网中创建您的实例。因此,每个实例都与 Amazon A EC2 uto Scaling 选择的特定可用区相关联。实例启动时,Amazon A EC2 uto Scaling 会尝试在各个区域之间均匀分配实例,以实现高可用性和可靠性。

下图概括演示了跨三个可用区部署的多层级架构。

跨三个可用区的典型自动扩缩组。

实例分配

Amazon A EC2 uto Scaling 会自动尝试在每个已启用的可用区域中保持相同数量的实例。Amazon A EC2 uto Scaling 通过尝试在可用区中启动实例最少的新实例来实现这一点。如果为可用区选择了多个子网,Amazon A EC2 uto Scaling 会尝试在可用区域中可用 IP 地址数量最多的子网中启动实例。但是,如果尝试失败,Amazon A EC2 uto Scaling 会尝试在另一个可用区启动实例,直到成功为止。

如果某个可用区运行状况不正常或不可用,实例在可用区之间的分布可能不再均匀。可用区恢复后,Amazon A EC2 uto Scaling 会自动重新平衡 Auto Scaling 组。为此,系统将会在具有最少实例的已启用可用区中启动实例,并在其他可用区中终止实例。

再平衡活动

再平衡活动分为两类:可用区再平衡和容量再平衡。

可用区再平衡

在某些操作发生后,Auto Scaling 组可能会在不同可用区之间变得不平衡。Amazon A EC2 uto Scaling 通过重新平衡可用区域来进行补偿。以下操作可能导致重新平衡活动:

  • 您更改了与您的自动扩缩组关联的可用区。

  • 您显式终止或分离了实例,或将实例设为待机状态,这时该组将会失衡。

  • 之前没有足够容量的某个可用区已经恢复,现在具有额外的容量。

  • 之前 Spot 价格超出您最高价的可用区现在的 Spot 价格低于您的最高价。

重新平衡时,Amazon A EC2 uto Scaling 会在终止之前的实例之前启动新实例。这样可确保重新平衡不会影响应用程序的性能或可用性。

由于 Amazon A EC2 uto Scaling 会尝试在终止之前启动新实例,因此达到或接近指定的最大容量可能会阻碍或完全停止再平衡活动。

为避免此问题,在再平衡活动期间,系统可以暂时超出组的指定最大容量。预设情况下,系统可以执行 10% 或一个实例的裕度,以两者中最大的为准。仅在该组达到或接近最大容量并且需要重新平衡时,才会提供边际。该超出状态仅持续重新平衡该组所需的时间(通常为几分钟)。

或者,您可以使用实例维护策略为自动扩缩组设定阈值,以便该组只能在该阈值范围内增加或减少容量。这样,您就可以控制该组自我重新平衡的速度。有关更多信息,请参阅 实例维护策略

容量再平衡

使用竞价型实例时,您可以为您的自动扩缩组开启容量再平衡。这样,当亚马逊EC2报告竞价型实例的中断风险较高时,Amazon A EC2 uto Scaling 就可以尝试启动竞价型实例。启动新实例后,它会终止旧实例。有关更多信息,请参阅 使用容量重新平衡来处理 Amazon EC2 竞价型实例中断