评估 DynamoDB 表的自动扩缩设置
本节概述如何评估 DynamoDB 表上的自动扩缩设置。Amazon DynamoDB Auto Scaling 是根据您的应用程序流量和目标利用率指标,来管理表和全局二级索引 (GSI) 吞吐量的一项功能。这将确保您的表或 GSI 具有应用程序模式所需的容量。
AWS Auto Scaling 服务将监控您当前的表利用率,并与目标利用率值作比较:TargetValue
。当需要增加或减少分配的容量时,它会通知您。
了解您的自动扩缩设置
为目标利用率、初始步骤和最终值定义正确的值是一项需要运营团队参与的活动。这允许您根据应用程序的使用历史来适当地定义值,以便触发 AWS 自动扩缩策略。利用率目标是总容量的百分比值,需要在一段时间内达到后,才会应用自动扩缩规则。
当您设置高利用率目标(大约 90%)时,意味着流量在一段时间内高于 90% 后才会触发自动扩缩策略。除非您的应用程序非常稳定且不会收到高峰流量,否则不应使用高利用率目标。
当您设置非常低的利用率目标(低于 50%)时,意味着您的应用程序需要达到预置容量的 50% 后才会触发自动扩缩策略。除非您的应用程序流量以非常激进的速度增长,否则这通常会造成未用的容量和浪费的资源。
如何识别具有低目标利用率 (<=50%) 的表
您可以使用 AWS CLI 或 AWS Management Console 来监控和识别 DynamoDB 资源中有关自动扩缩策略的 TargetValues
:
如果您的目标利用率值小于或等于 50%,则应浏览您的表利用率指标,看看这些指标是配置不足还是过度配置。
如何处理具有季节性差异的工作负载
考虑以下场景:您的应用程序大部分时间都在最低平均值下运行,但是利用率目标较低,所以您的应用程序可以对一天中特定时间发生的事件做出快速反应,并且您有足够的容量来避免节流。当您的应用程序在正常办公时间(上午 9 点到下午 5 点)非常繁忙,但在下班后处于基本工作水平时,这种场景很常见。因为一些用户会在上午 9 点前开始连接,所以应用程序使用这个低阈值来实现快速爬坡,以便在高峰时段达到所需容量。
此场景可能是这样的:
-
下午 5 点到上午 9 点之间,
ConsumedWriteCapacity
单位保持在 90 到 100 之间 -
用户在上午 9 点之前开始连接到应用程序,容量单位显著增加(您看到的最大值为 1500WCU)
-
平均下来,您的应用程序在工作时间内的使用量在 800 到 1200 之间变化
如果前面的场景适用于您,可考虑使用定时自动扩缩,在这种情况下,您的表仍可以配置应用程序自动扩缩规则,但目标利用率不那么激进,只是在您需要的特定间隔预置了额外容量。
您可以使用 AWS CLI 执行以下步骤,创建基于一天中的某个时间和一周中的星期几来执行的定时自动扩缩规则,
-
在 Application Auto Scaling 中将您的 DynamoDB 表或 GSI 注册为可扩展目标。可扩展目标是 Application Auto Scaling 可以扩大或缩小的资源。
aws application-autoscaling register-scalable-target \ --service-namespace dynamodb \ --scalable-dimension dynamodb:table:WriteCapacityUnits \ --resource-id table/<table-name> \ --min-capacity 90 \ --max-capacity 1500
-
根据您的要求设置预定操作。
我们需要两条规则来覆盖此场景:一条规则用来扩大,一条规则用来缩小。第一条规则扩大预定操作:
aws application-autoscaling put-scheduled-action \ --service-namespace dynamodb \ --scalable-dimension dynamodb:table:WriteCapacityUnits \ --resource-id table/<table-name> \ --scheduled-action-name my-8-5-scheduled-action \ --scalable-target-action MinCapacity=800,MaxCapacity=1500 \ --schedule "cron(45 8 ? * MON-FRI *)" \ --timezone "Australia/Brisbane"
第二条规则缩小预定操作:
aws application-autoscaling put-scheduled-action \ --service-namespace dynamodb \ --scalable-dimension dynamodb:table:WriteCapacityUnits \ --resource-id table/<table-name> \ --scheduled-action-name my-5-8-scheduled-down-action \ --scalable-target-action MinCapacity=90,MaxCapacity=1500 \ --schedule "cron(15 17 ? * MON-FRI *)" \ --timezone "Australia/Brisbane"
-
运行以下命令来验证两条规则是否已激活:
aws application-autoscaling describe-scheduled-actions --service-namespace dynamodb
应得到类似如下的结果:
{ "ScheduledActions": [ { "ScheduledActionName": "my-5-8-scheduled-down-action", "ScheduledActionARN": "arn:aws:autoscaling:<region>:<account>:scheduledAction:<uuid>:resource/dynamodb/table/<table-name>:scheduledActionName/my-5-8-scheduled-down-action", "ServiceNamespace": "dynamodb", "Schedule": "cron(15 17 ? * MON-FRI *)", "Timezone": "Australia/Brisbane", "ResourceId": "table/<table-name>", "ScalableDimension": "dynamodb:table:WriteCapacityUnits", "ScalableTargetAction": { "MinCapacity": 90, "MaxCapacity": 1500 }, "CreationTime": "2022-03-15T17:30:25.100000+10:00" }, { "ScheduledActionName": "my-8-5-scheduled-action", "ScheduledActionARN": "arn:aws:autoscaling:<region>:<account>:scheduledAction:<uuid>:resource/dynamodb/table/<table-name>:scheduledActionName/my-8-5-scheduled-action", "ServiceNamespace": "dynamodb", "Schedule": "cron(45 8 ? * MON-FRI *)", "Timezone": "Australia/Brisbane", "ResourceId": "table/<table-name>", "ScalableDimension": "dynamodb:table:WriteCapacityUnits", "ScalableTargetAction": { "MinCapacity": 800, "MaxCapacity": 1500 }, "CreationTime": "2022-03-15T17:28:57.816000+10:00" } ] }
下图显示了一个始终保持 70% 目标利用率的示例工作负载。请注意,自动扩缩规则仍然适用,并且吞吐量不会减少。
放大图片,我们可以看到,应用程序中有一个高峰,它触发了 70% 自动扩缩阈值,迫使自动扩缩启动,来为表提供所需的额外容量。预定的自动扩缩操作将影响最大值和最小值,设置这些值是您的责任。
如何处理具有未知模式的尖峰工作负载
在这种场景中,应用程序使用非常低的利用率目标,因为您尚不清楚应用程序的模式,而您需要确保工作负载不被节流。
可考虑改用按需容量模式。按需模式表非常适合您不知道流量模式的尖峰工作负载。在按需容量模式下,您按请求为应用程序在表上执行的数据读取和写入付费。您无需指定应用程序预计将执行多少读写吞吐量,因为 DynamoDB 会根据工作负载的增减来即时做出调整。
如何处理具有关联应用程序的工作负载
在这种场景中,应用程序依赖其他系统,例如在批处理场景中,根据应用程序逻辑中的事件,您会遇到非常大的流量尖峰。
可考虑开发自定义自动扩缩逻辑,以便对那些您可以根据自己的具体需求增加表容量和 TargetValues
的事件作出反应。您可以受益于 Amazon EventBridge,并使用像 Lambda 和 Step 函数这样的 AWS 服务组合来对特定应用程序需求作出反应。