使用 Amazon EBS 延迟注入测试和构建应用程序弹性

企业在构建高可用性应用程序时，必须有效预防可能导致业务中断和收入损失的系统故障。虽然完善的监控系统能主动识别问题，但混沌工程提供了一种更系统化的方法来构建弹性架构——通过主动发现潜在故障点来规避重大中断风险。

这一方法在存储基础设施领域尤为重要。以Amazon Elastic Block Store（Amazon EBS）为例，这款高性能块存储产品支撑着数据库、大数据分析和媒体处理等关键业务场景。这些对延迟高度敏感的应用一旦遭遇I/O延迟上升，就可能引发服务中断，直接影响终端用户体验。为此，企业通过混沌工程模拟存储性能下降场景，既能了解系统响应机制，又能提前部署防护措施确保持续可用。

本文将具体介绍如何利用AWS Fault Injection Service（AWS FIS）中的EBS延迟注入功能：首先演示如何在EBS卷上制造高I/O延迟以模拟真实故障；其次说明如何通过Amazon CloudWatch警报实现自动化监控与恢复。这套方案能帮助客户验证其系统在存储层性能波动时的应对能力，从而建立更强的业务连续性保障。

解决方案概述

AWS FIS 通过系统的故障注入实验支持对 Amazon EBS 故障进行受控测试。该服务有助于在托管测试环境中模拟不同类型的中断，例如停滞的 I/O 和高 I/O 延迟。AWS FIS 使用这些受控测试功能，在基于 Amazon EBS 的基础设施中潜在漏洞对生产环境造成广泛影响之前主动识别和修复这些漏洞，从而帮助提高应用程序弹性。

客户可以使用 AWS FIS 中的 Amazon EBS 延迟注入作来测试其应用程序如何应对卷 I/O 延迟的意外变化，并了解对其应用程序堆栈的不同层和最终用户的潜在影响。要快速开始延迟实验，您可以使用 Amazon EBS 和 AWS FIS 控制台提供的预配置延迟场景模板。这些方案复制了在实际案例中可以观察到的各种延迟模式。您可以通过从 AWS FIS 场景库自定义场景模板或从头开始创建模板来满足您的特定测试需求，从而根据应用程序要求调整测试。即使一小部分 I/O 性能下降，导致尾部延迟较高，工作负载也可能会中断。您可以使用 Amazon EBS 延迟作来重现这些延迟异常值，以了解您的应用程序在这些情况下的行为方式。以下摘要简要讨论了模拟此行为的四种方案中的每一种，并有助于测试卷上不同类型的速度减慢。

场景 1 – EBS：持续延迟
此场景呈现了一种延迟模式，在实验期间，您观察到 50% 的读取 I/O作和 100% 的写入 I/O作的持续延迟为 500 毫秒。您可以使用此方案为应用程序建立性能基线，并确定延迟何时在较长时间内偏离可接受的水平，以指示任何潜在问题。

场景 2 – EBS：间歇性延迟
此场景呈现了一种延迟模式，在 0.1% 的 I/O作上，您会观察到长达 30 秒的急剧短期峰值，延迟峰值之间有恢复期。可以使用此方案来测试极端的零星尾部延迟。此外，您还可以看到这些短暂的不一致延迟如何影响应用程序的性能，并由于不可预测的模式而对最终用户造成中断。

场景 3 – EBS：增加延迟
此场景呈现一种延迟模式，在实验期间，您观察到 10% 的读取 I/O作和 25% 的写入 I/O作的延迟从 50 毫秒逐渐增加到 15 秒。可以使用此方案来测试系统是否可以及早检测到问题。此外，您可以在问题严重影响应用程序性能并导致用户停机之前主动采取措施解决问题。

场景 4 – EBS：减少延迟
此场景呈现了一种延迟模式，在实验期间，您观察到 10% 的读写 I/O作的延迟从 20 秒逐渐减少到 40 毫秒。您可以使用此方案来确定系统在何时停止警报，以及应用程序如何响应这种形式的降级，以便可以测试故障恢复机制。

在本演练中，我们将使用示例测试工作负载探讨如何使用这些延迟方案进行测试。在这些测试中，我们在配置为 16 IOPS 和 16000 MB/s 吞吐量的 GP3 卷上运行具有 16000 KiB IO 大小的随机工作负载，用于读取和写入。我们还演示了如何运行自己的自定义实验。此外，我们还讨论了如何有效监控这些延迟并主动实施必要的恢复机制，以在应用程序性能下降成为面向用户的问题之前识别和修复它。

先决条件

您必须设置一个具有足够权限的 AWS 账户 才能使用 Amazon EBS、AWS FIS 和 Amazon CloudWatch。此外，在使用 AWS FIS 时，它会自动为实验配置 AWS Identity and Access Management （IAM） 角色。AWS FIS 会对系统中的真实 AWS 资源进行真正的中断。在生产环境中运行试验之前，强烈建议完成规划阶段，并在预生产/测试环境中运行试验。

演练

若要开始进行延迟注入试验，必须执行以下步骤。

第 1 步：登录 AWS 管理控制台并导航到 Amazon EC2 服务控制台

1. 登录 AWS 管理控制台并选择适当的 AWS 区域。
2. 导航到 Amazon Elastic Compute Cloud （Amazon EC2） 控制台。
3. 要更改区域，请使用页面右上角的区域选择器。

第 2 步：从左侧导航窗格中选择 Elastic Block Store 下的 Volumes

1. 从 Elastic Block Store 下的左侧导航窗格中选择 Volumes（卷）选择要用于此实验的卷 ID，然后选择 Actions（作）。选择弹性测试>注入卷 I/O 延迟。

第 3 步：测试实验设置下列出的各种 Amazon EBS 延迟场景，并使用 CloudWatch 监控延迟

在此步骤中，我们将介绍如何运行解决方案概述中描述的四种场景中的每一种，并使用 CloudWatch 指标观察 EBS 卷上遇到的延迟。

场景 1：持续

1.1. 从实验设置中选择持续。
1.2. 在EBS卷下，确保指定的卷ID正确无误。
1.3. 您可以选择具有为 Amazon EBS 执行此特定 AWS Resilience Hub 场景所需的权限的现有 IAM 角色，也可以创建一个新角色。
1.4. 请注意定价估算以运行此实验。您需要根据作处于活动状态的持续时间付费。该实验持续 15 分钟。
1.5. 选择“开始实验”。

您可以通过名为 VolumeAvgReadLatency 和 VolumeAvgWriteLatency 的 CloudWatch 指标来监控这一点，这些指标是显示平均 I/O 延迟的每分钟指标。可以观察到，读取 I/O作的平均读取延迟为 250 毫秒，写入 I/O作的平均写入延迟为 500 毫秒，如方案 1 中所定义的解决方案概述下的持续延迟。这是因为只有 50% 的读取作注入了延迟，而写入作的延迟为 100%。

场景 2：间歇性

2.1. 从实验设置中选择间歇性。

2.2. 然后，按照场景 1 中的步骤 1.2 到 1.5 开始此实验。

注入的延迟仅占 I/O 的极小百分比 （0.1%）;因此，观察到的平均延迟实际上低于实验中的延迟值

场景 3：增加

3.1. 从实验设置中选择增加。
3.2. 然后，按照场景 1 中的步骤 1.2 到 1.5 开始这个实验。

当您查看 CloudWatch 指标时，您可以看到平均读取延迟在峰值时从 5 毫秒增加到 100 毫秒再到 2200 毫秒，而写入延迟在峰值时从 15 毫秒增加到 125 毫秒再到 3500 毫秒。这是因为你为实验中受影响的读取 （10%） 和写入 （25%） I/O 指定了不同的百分比。

场景 4：递减

4.1. 从实验设置中选择递减。
4.2. 然后，按照场景 1 中的步骤 1.2 到 1.5 开始此实验。

当您查看 CloudWatch 指标时，您可以看到平均读取延迟从大约 2500 毫秒的峰值减少到 470 毫秒到 5 毫秒。

步骤 4：创建自定义实验

由于不同的应用程序对延迟的敏感性不同，因此还可以创建自定义试验来策划特定于应用程序需求的测试。下面是自定义实验的示例。

1. 在 AWS Resilience Hub 的 Resilience testing （弹性测试） 下，从左窗格中选择 Experiment templates （实验模板），然后选择创建实验模板。

1. 提供描述和名称 - 可选。 在实验类型下选择此 AWS 账户。然后，选择
2. 在指定作和目标下，提供以下配置：
   3.1。在“作”选项卡下：添加作：选择 EBS > aws：ebs：volume：io：latency。
   3.2. 名称：为此自定义实验
   3.3 提供您选择的名称。描述 - 可选：这是可选的
   3.4。开始时间 - 可选：如果您希望此实验在某些作后开始，则可以从下拉列表中进行选择。这是可选的，并且不是本实验所必需的，因此不要选择任何内容。
   3.5. 目标：保留默认值。
   3.6. 动作参数：

• 期间： 这是在删除添加的 I/O 延迟之前等待的时间。将其设置为 15 分钟。
• I/O 延迟模式：从这里您可以选择要测试的延迟。从下拉列表中选择“只读”。
• 读取 I/O 延迟毫秒 – 可选：这是为 I/O作设置的最小读取延迟，以毫秒为单位。将此值设置为 100。
• 读取 I/O 百分比 – 可选：这是要损害的读取 I/O作的百分比。默认值为 100%。将此值设置为 50%。

3.7.选择救。

3.8. 在“目标”选项卡下>添加目标。
3.9.名称：提供此目标的名称。
3.10. 资源类型：选择aws：ec2：ebs-volume。
3.11.目标方法： 选择资源 ID。
3.12.在“资源 ID”下：选择要运行此测试的卷 ID。选择模式： 都。
3.13. 选择救。

对于 Experiment options > 在 Empty target resolution mode 下拉菜单下，选择 Then，选择下一个。

在配置服务访问权限页面上，选择为实验模板创建新角色或使用现有 IAM 角色。在这篇文章中，选择创建一个新角色。然后，选择下一步。

1. 在“配置可选设置”页上，将所有内容保留为默认值，然后选择
2. 同样，在“查看和创建”页面上，验证所有配置，向下滚动，然后选择“创建实验模板”。 键入“create”，然后再次选择“创建试验模板”进行确认。
3. 要开始实验，请选择开始实验

如果要提供实验标签，请选择添加新标签并提供标签值。然后，选择“开始试验”并键入“开始”进行确认。

与之前的实验类似，这可以通过 CloudWatch 指标进行监控：VolumeAvgReadLatency 和 VolumeAvgWriteLatency。50% 的读取 I/O 延迟为 100 毫秒的实验模板配置与 50 毫秒的读取延迟一致，这在以下 CloudWatch 指标控制面板中也可见。我们在实验中只指定了读取延迟，因此写入延迟保持在 gp3 卷的预期值范围内，如下图所示。

清理

如果您不再需要测试设置，请删除 CloudWatch 警报。此外，请检查您是否专门为此测试设置创建了任何新的 EBS 卷，并删除该卷以避免产生其他费用。

结论

由于各种原因，您的应用程序可能会遇到延迟，无论根本原因是什么，它们都必须承受这些中断。AWS FIS 中的 Amazon EBS 卷 I/O 延迟注入作可帮助您测试系统对 Amazon EBS 延迟增加的响应。您可以使用此工具模拟不同的延迟场景，设置适当的超时和警报，并验证恢复过程。对于全面的测试，您可以将其与暂停卷 I/O作结合使用，以测试可能影响应用程序的不同类型的存储中断。此外，您可以将这些测试集成到您的游戏日和混沌工程实验中，以建立信心，即您的应用程序实际上能够适应您设计的故障模式。我们还建议将这些测试纳入您的持续自动化测试例程中，以保持持续的系统弹性。

原文链接：https://aws.amazon.com/cn/blogs/storage/test-and-build-application-resilience-using-amazon-ebs-latency-injection/