使用 Amazon EBS 优化实例突发功能提高应用程序性能并降低成本

2017 年，Amazon EC2 引入 C5 计算密集型实例和 M5 通用型实例。2018 年，我们通过向 EC2 C5 和 M5 实例系列添加高速、超低延迟的本地 NVMe 存储，推出了 EC2 C5d 实例和 M5d 实例。EC2 C5/C5d 和 M5/M5d 实例均以 Nitro 系统为基础构建。AWS 构建的这一软件和硬件集合可实现高性能、高可用性、高安全性以及裸机功能，以降低虚拟化开销。

在 Nitro 系统的设计过程中，我们对真实世界的工作负载进行了分析，意识到需要利用更小的实例大小来通过 Amazon EBS 卷提升性能。我们发现，多数应用程序的存储需求是突发性的，具有短而密集的 I/O 周期，而突发的需求之间存在大量空闲时间。为改善这些工作负载的体验，我们研发了适用于小型实例大小的突发功能。可在 EC2 C5/C5d 和 M5/M5d 实例上使用，该功能使 large、xlarge 和 2xlarge 大小的实例每天能够实现与 4xlarge 实例相同的性能至少 30 分钟。

对具有突增 Amazon EBS 需求的应用程序，您可以根据 CPU 和内存需求调整实例大小，同时仍可满足 EBS 经过优化的实例的性能要求。这种更高的性能还让您能够根据 EBS 经过优化的实例性能对工作流的各个部分进行加速。更快的工作流可以加快作业完成速度并提高资源利用率。这种突发功能最终可以通过调整实例大小并提高总体资源利用率来降低成本。

随着这种性能的提升，您将可以处理意外的需求高峰，且不会对应用程序的性能造成影响。现在，您可以依据历史平均趋势来调整实例大小。这种突发功能可让您在不影响客户体验的前提下，提供更佳性能以承受峰值。

利用 Amazon CloudWatch 指标监控突发使用情况

为了更好地了解性能，基于 Nitro 系统的实例提供 Amazon CloudWatch 指标，以帮助您分析使用情况。您可以依据使用情况确定满足需求的更小实例。

在这些实例中，您可以通过实例级 CloudWatch 操作指标（EBSReadOps 和 EBSWriteOps）和传输的字节（EBSReadBytes 和 EBSWriteBytes）来监控使用情况。有关这些指标的更多信息，请参见列出实例的可用 CloudWatch 指标。默认情况下，这些指标支持基本监控（五分钟一次），但您可以启用详细监控（一分钟一次），不过需要额外支付费用。有关更多信息，请参见 Amazon CloudWatch 定价。

对于 large、xlage 和 2xlarge 实例，我们还提供突发均衡指标。 EBSIOBalance% 用于监控实例的 I/O 突发存储桶，EBSByteBalance% 则用于监控实例的字节突发存储桶。这些指标提供相应突发存储桶中留存的 I/O 或字节积分百分比相关的信息。这些指标以百分比的形式表示，其中 100% 表示该实例已累计达到最大积分数。您可以设置均衡过低时触发的警报。

我们启动一个 m5.large 实例来演示这些指标。然后，为改实例附加一个带有 32000 个预配置 IOPS 的 500GB io1 Amazon EBS 卷。基于 Nitro 系统的实例中附加的 Amazon EBS 卷展示为 NVMe 设备。

首先，我们使用 fio 在 /dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol02f2f9a66c2ebfd66 中运行大型数据块 (128KiB) 测试，并监控 EBSIOBalance% 和 EBSByteBalance%。

$ sudo fio –filename= /dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol02f2f9a66c2ebfd66 –rw=randread –bs=128k –runtime=2400 –time_based=1 –iodepth=32 –ioengine=libaio –direct=1 –name=large-block-test

由于这是一项大型数据块工作负载，因此不会产生足够的 IOPS，耗尽 EBSIOBalance%，而是会耗尽 EBSByteBalance%，如下图所示。

然后我们再运行一个小型数据块测试，了解它对 EBSIOBalance% 和 EBSByteBalance% 造成的影响。

$ sudo fio –filename= /dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol02f2f9a66c2ebfd66 –rw=randread –bs=16k –runtime=2400 –time_based=1 –iodepth=32 –ioengine=libaio –direct=1 –name=small-block-test

由于这是一个小型数据块测试，会比字节/秒产生更高的 IOPS。因此，EBSIOBalance% 比 EBSByteBalance% 下降更快，如下图所示。

只要 EBSIOBalance% 和 EBSByteBalance% 高于 0%，该实例就可以产生突发性能。当实例的 I/O 活动低于基准率时，突发存储桶会重新填充。测试完成后，我们暂停实例中的所有 I/O。这段非活动时间可让实例的突发存储桶重新填充，如下图中的 EBSIOBalance% 和 EBSByteBalance% 所示。

突发存储桶的重新填充速率为基准速率和实例 I/O 活动之间的差值。例如，m5.large 的基准吞吐率为 60MB/s，基准 IOPS 速率为 3600 IOPS。假设实例的 I/O 活动为 10MB/s 和 1000 IOPS。字节存储桶会以 50MB/s（60MB/s 减 10MB/s）的速率填充。IOPS 存储桶会以 2600 IOPS（3600 IOPS 减 1000 IOPS）的速率填充。有关不同实例的基准速率，请参见 Amazon EBS 优化实例。此外，我们每 24 小时对突发存储桶进行填充，这意味着，该实例每天至少可使用 30 分钟的突发性能。

性能增强

我们持续对 Nitro 系统进行改进。通过增强功能集合，我们将 large、xlarge 和 2xlarge EC2 C5/C5d 和 M5/M5d 实例的最大突发带宽从 2.25Gbps 和 2.12Gbps 提高到了 3.5Gbps。我们还将 EC2 C5/C5d 和 M5/M5d 的最大突发 IOPS 从 16000 IOPS 分别提升到了 20000 IOPS 和 18750 IOPS。所有新的 EC2 C5/C5d 和 M5/M5d 更小型实例都可以享受这些性能提升，且无需额外费用。

有关支持这种突发功能的基于 Nitro 系统的实例列表和相应数据，请参见 Amazon EBS 优化实例。

本文转载自 AWS 技术博客。

原文链接：

https://amazonaws-china.com/cn/blogs/china/amazon-ebs-case-function-improve-cost-reduce/