AWS Kinesis 支持按需 Advantage 暖吞吐缩容

客户一直使用 Amazon Kinesis Data Streams 以任意规模流式传输数据。一些客户使用按需标准模式让服务管理容量，而另一些具有可预测流量模式的客户则使用 按需优势模式和预热吞吐量 来确保流能够处理瞬间的吞吐量增长。流式工作负载很少一直以峰值容量运行：闪购活动会结束，批量迁移会完成，遥测突发会逐渐消退。然而，在突发消退后，通常需要手动干预才能缩减规模。Amazon Kinesis Data Streams 现在支持 通过预热吞吐量缩减按需优势流的摄取容量，这会通过移除多余容量来优化下游计算成本和性能。您可以通过开启按需优势模式（ODA）并设置一个等于或小于现有值的新预热吞吐量值来配置此功能。

通过此发布，您现在可以主动减少写入吞吐量容量，在优化成本的同时保持性能，并让您对流的预置拥有更多控制权。

在本文中，我们将探讨预热吞吐量缩减能力。我们将介绍它解决的问题、其工作原理、如何使用 Amazon CloudWatch 指标监控流行为，以及有效使用它的最佳实践。

挑战：流量峰值后的多余容量

Amazon Kinesis Data Streams 按需模式会自动扩展以处理数据吞吐量的增长。当您的流经历流量峰值时，Kinesis Data Streams 会拆分分片以容纳更高的数据量。这种自动扩展可帮助您的应用程序在激增期间跟上数据。

然而，许多现实世界的工作负载会经历瞬态突发，这些突发并不代表持续的吞吐量需求。设想一个处理闪购活动的零售平台、一个在迁移窗口期间摄取大量患者记录的医疗保健系统，或一个传输大批量固件更新遥测突发的物联网（IoT）设备群。在每种场景中，流都会扩展以容纳峰值，但在突发消退很久之后，升高的容量仍然存在。尽管 Kinesis 按需优势模式不会对升高的容量收费，但您的消费应用程序可能会看到更高的成本和更低的性能。

设想一个 Kinesis 数据流以 100 MB/s 的摄取吞吐量运行，需要 100 个分片。额外 50 MB/s 的流量峰值迫使按需模式将流扩展到 150 个分片。峰值在几分钟内消退，但这 150 个分片仍然存在。

如果您的 AWS Lambda 消费者使用并行化因子 2，您将从 200 个并发调用（2 × 100 个分片）变为 300 个（2 × 150 个分片）。即使摄取吞吐量已恢复到 100 MB/s，Lambda 并发执行也跃升了 50%。这些额外的 100 个 AWS Lambda 调用会消耗计算资源、计入您的并发执行配额，并在以小批量大小处理数据时增加成本。

Kinesis Client Library（KCL）消费者会产生运营开销。KCL 在 Amazon DynamoDB 中为每个分片跟踪一个租约，因此额外的 50 个分片意味着每个心跳周期要扫描、续订和检查点更多 50 个租约。结果是租约管理的 Amazon DynamoDB 开销增加，整体消费性能降低。

在此发布之前，您解决此多余容量的选择有限：

• 切换到预置模式以手动设置分片数，从而失去自动扩展的优势。
• 接受更高的容量及相关成本，直到流自行调整。

这些方法要么引入运营开销，要么导致为超出工作负载实际需求的容量付费。

解决方案：预热吞吐量缩减

通过按需容量缩减，您现在可以在按需流上设置更低或相等的预热吞吐量值来触发容量缩减。流会调整到所请求的容量或支持过去一小时内峰值数据摄取使用所需的容量，以较高者为准。此保护措施可帮助您的流保留足够的容量以应对当前流量，同时释放您不再需要的多余容量。

此功能对所有已开启 按需优势模式 的按需流免费提供。

工作原理

预热吞吐量为按需流提供双向容量管理：

• 扩展（现有能力）： 如果您预测即将发生流量事件，可以将预热吞吐量配置为更高的值，以便提前准备流，使数据到达时容量可用而不会受到限流。
• 缩减（新能力）： 如果瞬态突发导致流显著扩展到超出其稳态需求，您可以通过将预热吞吐量设置为更低的值来触发缩减。

当您在按需流上设置一个等于或低于当前值的预热吞吐量值时，Kinesis Data Streams 会根据您流的近期流量评估该请求。所得容量为以下两者中的较大者：

1. 您请求的预热吞吐量值。
2. 支持过去一小时内峰值数据摄取使用所需的容量。

此机制可防止您意外地将容量降低到低于当前工作负载所需的水平。如果缩减完成后数据流量增加，按需模式仍可通过反应式扩展来扩大流摄取容量，以避免限流。

开始使用

先决条件

要跟随操作，您需要以下内容：

1. 一个处于按需模式的现有 Kinesis 数据流。
2. 已开启按需优势模式。
3. 已安装并配置 AWS Command Line Interface（AWS CLI）。
4. 具有 kinesis:UpdateStreamMode 的 AWS Identity and Access Management（IAM）权限。

要触发缩减，请使用 AWS CLI 在您的按需流上设置更低的预热吞吐量值：

aws kinesis update-stream-mode \
--stream-arn arn:aws:kinesis:us-east-1:111122223333:stream/my-stream/my-stream \
--warm-throughput-in-mb 50

使用 Amazon CloudWatch 监控流行为

要观察缩减操作的效果并了解您的流的容量和分片数，Amazon CloudWatch 提供了多个关键指标。监控这些指标有助于您在何时缩减以及缩减多少方面做出明智的决策。

要监控的关键指标

下表总结了与预热吞吐量缩减最相关的 CloudWatch 指标：

在缩减期间观察分片数行为

要跟踪缩减导致的分片数变化，请使用 DescribeStreamSummary API，它会在响应中返回 OpenShardCount 字段。请注意，OpenShardCount 不是 CloudWatch 指标。它可通过 API 获取，也会显示在 Kinesis Data Streams 控制台上。您可以定期轮询此值，或使用 AWS Lambda 函数构建自定义 CloudWatch 指标来跟踪分片数随时间的变化。

以下是您可以预期的流行为：

1. 突发之前： 您的流以稳态运行，其基准分片数适合您的正常流量。例如，处理 20 MiB/s 写入吞吐量的流可能大约有 67 个开放分片。
2. 突发期间： 随着流量激增，Kinesis Data Streams 会自动拆分分片以应对增加的负载。OpenShardCount 上升，IncomingBytes 相应增加。
3. 突发之后（缩减之前）： 流量恢复到基线，但 OpenShardCount 仍保持较高水平，因为流会保留高达最近观测峰值两倍的容量。
4. 触发缩减之后： 在您设置较低的预热吞吐量后，OpenShardCount 会随着 Kinesis Data Streams 合并分片以匹配请求的容量而下降（受一小时峰值保护机制约束）。您可以通过轮询 DescribeStreamSummary 或在 Kinesis 控制台上观察此转变。

图 1：在缩减事件期间 Amazon Kinesis Data Streams 分片数随时间的变化，展示了传入数据激增以及由此导致的分片数变化

最佳实践

使用预热吞吐量缩减时，请考虑以下建议：

1. 在缩减之前分析流量模式。 在设置较低的预热吞吐量值之前，至少查看 24 小时的 IncomingBytes 和 IncomingRecords CloudWatch 指标，以了解您的基线吞吐量。这有助于避免将容量设置得低于您的实际稳态需求。
2. 将预热吞吐量设置在观测到的稳态峰值之上。由于按需流可容纳高达观测峰值两倍的流量，请将您的目标预热吞吐量设置为您典型峰值或更高，而不是平均水平。这样可保持余量以应对正常流量波动而不至于限流。
3. 缩减后监控限流情况。 在缩减后的数小时内密切关注 WriteProvisionedThroughputExceeded。如果发生限流，请提高预热吞吐量值。流会自动重新扩展，但主动监控可缩短任何影响的持续时间。
4. 在已知的临时事件之后使用缩减。 当您能够确认流量激增是暂时的时，此功能最为有效，例如在计划内的批量迁移、营销活动或计划内的数据回填之后。避免在流量不确定或增长的时期进行缩减。
5. 使用一小时保护机制。 系统不会将容量降低到低于服务过去一小时峰值摄取所需的水平。如果您不确定合适的目标值，可以设置较低的预热吞吐量值，并依赖此保护机制来防止对活动流量配置不足。

结论

Amazon Kinesis Data Streams 现在支持使用预热吞吐量缩减摄取容量，让您可以弹性控制 On-demand Advantage 流的容量。借助此功能，您可以在临时流量突发后释放多余容量，提高成本效率，同时保持按需模式的自动扩展优势。

要开始使用，请为您的流开启 On-demand Advantage 模式，并使用预热吞吐量设置来管理容量。使用 DescribeStreamSummary 跟踪分片数以观察容量变化，并确认您的流为工作负载保留了适当的余量。立即在 Amazon Kinesis 控制台 中试用预热吞吐量缩减，如需了解更多信息，请参阅开发者指南中的 Amazon Kinesis Data Streams 按需容量模式。