1. 测试背景

Amazon EC2 Auto Scaling 是一项完全托管的服务，可自动启动或终止 Amazon EC2 实例，以帮助确保您拥有适当数量的 Amazon EC2 实例来处理应用程序负载。Amazon EC2 Auto Scaling 通过对 EC2 实例进行队列管理，检测并替换运行状况异常的实例，并根据您定义的条件自动扩展或缩减 Amazon EC2 容量，从而帮助您保持应用程序的可用性。在需求高峰期，您可以使用 Amazon EC2 Auto Scaling 来自动增加 Amazon EC2 实例的数量以便保持性能，并在需求降低时减少容量以降低成本。

客户在使用 Amazon EC2 时会根据业务的需求选择最合适的实例类型，本次测试主要是测试 Amazon EC2 Auto Scaling 在多 AZ 部署时不同实例机型、有无工作负载的多种情况下故障转移和扩容时间，为实例机型选择提供指导。

2. 测试环境

3. 测试前提

以下步骤的耗时将会显著的影响 Amazon EC2 Auto Scaling 扩容速度，为了规避这些步骤的影响，本测试在如下前提下进行：

• 本测试使用 Amazon Linux 2023 ami-0b08bfc6ff7069aff（提升 AMI 启动速度）
• 本测试无 user-data（无开机引导脚本 user-data 执行耗时）
• 本测试使用 Nginx（减少 Web 应用启动耗时）
• 本测试无生命周期钩子（生命周期钩子可以在 EC2 开关机的不同阶段暂停实例启动流程，并执行特定脚本，然后发出继续实例启动流程的信号）
• ELB 健康检查次数为 3 次，检查间隔为 10 秒
• 无 Amazon EC2 Auto Scaling 扩缩容冷却时间（在刚完成一次扩容后需要等待的一定时间再进行第二次扩容，默认 5 分钟，本测试将不会触发冷却机制）
• 压测实例与 EC2 测试实例均在同一个 VPC
• 开启 CloudTrail 用于统计故障转移和扩容的开始、结束时间
• 其余配置使用默认设置

4. 测试架构图

5. 测试用例

5.1 集群故障转移测试用例，测试基于以下 2 种配置模式，分别测试无工作负载和有工作负载两种情况下的集群故障转移时间

5.2 集群扩容实例时间测试用例，测试基于以下 2 种配置模式，分别测试无工作负载和有工作负载两种情况下的集群扩容实例时间

6. 测试方法

6.1 安装 Nginx 以及制作测试用 AMI

1. 使用 Amazon Linux 2023（ami-0b08bfc6ff7069aff）安装 Nginx 并设置开机自动启动

sudo yum install nginx -y
sudo systemctl enable nginx
sudo systemctl start nginx

2. 将安装好 Nginx 的 EC2 制作 AMI，并制作启动模板用于后续 Amazon EC2 Auto Scaling 测试

6.2 模拟生产工作负载的方法

1. 安装 Apache ab

sudo yum install httpd-tools

2. 使用 Apache ab 产生工作负载

ab -c 1000 -n 100000000 http://<ALB-DNS>/

3. 由于 ALB 需要一定的时间扩容，一开始就施加比较大的工作负载可能会遇到如下错误

apr_socket_recv: Connection reset by peer (104)

这是由于 ALB 尚未完全扩容，请重试第 2 步，直到不再报错，并逐渐增加工作负载。为了完成本测试，需要约 1 个小时时间逐渐增加工作负载。

6.3 集群故障转移测试方法

1. 使用 EC2 控制台“实例状态 -> 终止实例”触发故障转移
2. 使用 CloudTrail 中“事件名称”为 TerminateInstances 的事件记录故障开始的时间
3. 使用 CloudTrail 中“事件名称”为 RegisterTargets 来记录 EC2 向 ELB 注册的时间

本测试中健康检查采用“间隔 10 秒、3 次成功”的规则确定 EC2 健康，因此需要额外的 30-40 秒，本测试取 35 秒的平均值。最终故障转移结束时间为“RegisterTargets 时间 + 35秒”。

6.4 无工作负载扩容测试方法

1. 点击 Amazon EC2 Auto Scaling 控制台上的“编辑”按钮

在弹出的对话框中输入新的实例数量

根据 Amazon EC2 Auto Scaling 的设计，当修改 Amazon EC2 Auto Scaling 目标数量的配置之后，不会立即增加机器数量。因为，在整个 AWS 区域中有一个统一的服务每隔 30 秒扫描并生成一系列扩容任务，并触发后续的扩容动作。因此扩容开始时间使用以下 CloudTrail 的事件发生的时间。

2. 使用 CloudTrail 中事件名称为 UpdateAutoScalingGroup 来作为扩容开始的时间
3. 使用 CloudTrail 中事件名称为 RegisterTargets 来得到 EC2 向 ELB 注册的时间

本测试中健康检查采用“间隔 10 秒、3 次成功”的规则确定 EC2 健康，因此需要额外的 30-40 秒，本测试取 35 秒的平均值。最终扩容结束时间为“RegisterTargets 时间 + 35 秒”。

6.5 有工作负载扩容测试方法

1. 使用 Apache ab 产生网络请求，设置 Amazon EC2 Auto Scaling 规则“当 EC2 CPU 达到 50% 时”增加一个实例
2. 点击 Amazon EC2 Auto Scaling 控制台“活动 -> 活动历史记录” 记录“原因”中的时间为作为扩容开始的时间
3. 使用 CloudTrail 中事件名称为 RegisterTargets 来得到 EC2 向 ELB 注册的时间

本测试中健康检查采用“间隔 10 秒、3 次成功”的规则确定 EC2 健康，因此需要额外的 30-40 秒，本测试取 35 秒的平均值。最终扩容结束时间为“RegisterTargets 时间 + 35 秒”。

7. 测试数据

7.1 故障转移时间测试数据

本测试中健康检查采用“间隔 10 秒、3 次成功”的规则确定 EC2 健康，因此需要额外的 30-40 秒，本测试取 35 秒的平均值。最终故障转移结束时间为“RegisterTargets 时间 + 35 秒”。

表格中记录的时间为 3 次测试的平均时间。上表中任意两组时间差均小于 30 秒，小于 Amazon EC2 Auto Scaling 检测变更的时间周期。因此上表数据不能体现故障转移时间与实例机型和工作负载有关。

7.2 集群扩容时间测试数据

表格中记录的时间为 3 次测试的平均时间。上表中任意两组时间差均小于 30 秒，小于 Amazon EC2 Auto Scaling 检测变更的时间周期。因此上表数据不能体现故障转移时间与实例机型和工作负载有关。

8. 测试结论

1. Amazon EC2 Auto Scaling 故障转移时间与实例机型和工作负载相关性较小，在本测试中故障转移时间分布在 1 分 27 秒 – 1 分 56 秒之间，小于官方 FAQ （https://thinkwithwp.com/cn/ec2/autoscaling/faqs/）中描述的 5 分钟。
2. Amazon EC2 Auto Scaling 的实例扩容时间与实例机型和工作负载相关性较小，在本测中扩容时间分布在 43 秒 – 53 秒之间，均小于 1 分钟。
3. 由于扩容不需要通过健康检查检测实例故障，节约了这部分时间，因此实例扩容速度快于故障转移速度。

本篇作者