评估表的自动扩缩设置 - Amazon DynamoDB
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

评估表的自动扩缩设置

本节概述如何评估 DynamoDB 表上的自动扩缩设置。Amazon DynamoDB Auto Scaling 是根据您的应用程序流量和目标利用率指标,来管理表和全局二级索引 (GSI) 吞吐量的一项功能。这将确保您的表或 GSI 具有应用程序模式所需的容量。

Amazon Auto Scaling 服务将监控您当前的表利用率,并与目标利用率值作比较:TargetValue。当需要增加或减少分配的容量时,它会通知您。

了解您的自动扩缩设置

为目标利用率、初始步骤和最终值定义正确的值是一项需要运营团队参与的活动。这允许您根据应用程序的使用历史来适当地定义值,以便触发 Amazon 自动扩缩策略。利用率目标是总容量的百分比值,需要在一段时间内达到后,才会应用自动扩缩规则。

当您设置高利用率目标(大约 90%)时,意味着流量在一段时间内高于 90% 后才会触发自动扩缩策略。除非您的应用程序非常稳定且不会收到高峰流量,否则不应使用高利用率目标。

当您设置非常低的利用率目标(低于 50%)时,意味着您的应用程序需要达到预置容量的 50% 后才会触发自动扩缩策略。除非您的应用程序流量以非常激进的速度增长,否则这通常会造成未用的容量和浪费的资源。

如何识别具有低目标利用率 (<=50%) 的表

您可以使用 Amazon CLI 或 Amazon Web Services Management Console 来监控和识别 DynamoDB 资源中有关自动扩缩策略的 TargetValues

Amazon CLI
  1. 通过运行以下命令返回整个资源列表:

    aws application-autoscaling describe-scaling-policies --service-namespace dynamodb

    此命令将返回发布给任何 DynamoDB 资源的自动扩缩策略的完整列表。如果您只想检索来自特定表的资源,则可以添加 –resource-id parameter。例如:

    aws application-autoscaling describe-scaling-policies --service-namespace dynamodb --resource-id "table/<table-name>”
  2. 通过运行以下命令仅返回特定 GSI 的自动扩缩策略

    aws application-autoscaling describe-scaling-policies --service-namespace dynamodb --resource-id "table/<table-name>/index/<gsi-name>”

    我们感兴趣的自动扩缩策略的值在下面突出显示。我们希望确保目标值大于 50%,以避免过度配置。您应该得到类似如下的结果:

    { "ScalingPolicies": [ { "PolicyARN": "arn:aws:autoscaling:<region>:<account-id>:scalingPolicy:<uuid>:resource/dynamodb/table/<table-name>/index/<index-name>:policyName/$<full-gsi-name>-scaling-policy", "PolicyName": $<full-gsi-name>”, "ServiceNamespace": "dynamodb", "ResourceId": "table/<table-name>/index/<index-name>", "ScalableDimension": "dynamodb:index:WriteCapacityUnits", "PolicyType": "TargetTrackingScaling", "TargetTrackingScalingPolicyConfiguration": { "TargetValue": 70.0, "PredefinedMetricSpecification": { "PredefinedMetricType": "DynamoDBWriteCapacityUtilization" } }, "Alarms": [ ... ], "CreationTime": "2022-03-04T16:23:48.641000+10:00" }, { "PolicyARN": "arn:aws:autoscaling:<region>:<account-id>:scalingPolicy:<uuid>:resource/dynamodb/table/<table-name>/index/<index-name>:policyName/$<full-gsi-name>-scaling-policy", "PolicyName":$<full-gsi-name>”, "ServiceNamespace": "dynamodb", "ResourceId": "table/<table-name>/index/<index-name>", "ScalableDimension": "dynamodb:index:ReadCapacityUnits", "PolicyType": "TargetTrackingScaling", "TargetTrackingScalingPolicyConfiguration": { "TargetValue": 70.0, "PredefinedMetricSpecification": { "PredefinedMetricType": "DynamoDBReadCapacityUtilization" } }, "Alarms": [ ... ], "CreationTime": "2022-03-04T16:23:47.820000+10:00" } ] }
Amazon Web Services Management Console
  1. 登录 Amazon Web Services Management Console,并导航到开始使用 Amazon Web Services Management Console的 CloudWatch 服务页面。如有必要,选择合适的 Amazon 区域。

  2. 在左侧导航栏上,选择。在页面上,选择表的名称

  3. 表详细信息页面的其他设置选项卡下,查看表的自动扩缩设置。

    对于索引,展开索引容量选项卡,查看索引的自动扩缩设置。

如果您的目标利用率值小于或等于 50%,则应浏览您的表利用率指标,看看这些指标是配置不足还是过度配置

如何处理具有季节性差异的工作负载

考虑以下场景:您的应用程序大部分时间都在最低平均值下运行,但是利用率目标较低,所以您的应用程序可以对一天中特定时间发生的事件做出快速反应,并且您有足够的容量来避免节流。当您的应用程序在正常办公时间(上午 9 点到下午 5 点)非常繁忙,但在下班后处于基本工作水平时,这种场景很常见。因为一些用户会在上午 9 点前开始连接,所以应用程序使用这个低阈值来实现快速爬坡,以便在高峰时段达到所需容量。

此场景可能是这样的:

  • 下午 5 点到上午 9 点之间,ConsumedWriteCapacity 单位保持在 90 到 100 之间

  • 用户在上午 9 点之前开始连接到应用程序,容量单位显著增加(您看到的最大值为 1500WCU)

  • 平均下来,您的应用程序在工作时间内的使用量在 800 到 1200 之间变化

如果前面的场景适用于您,可考虑使用定时自动扩缩,在这种情况下,您的表仍可以配置应用程序自动扩缩规则,但目标利用率不那么激进,只是在您需要的特定间隔预置了额外容量。

您可以使用 Amazon CLI 执行以下步骤,创建基于一天中的某个时间和一周中的星期几来执行的定时自动扩缩规则,

  1. 在 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
  2. 根据您的要求设置预定操作。

    我们需要两条规则来覆盖此场景:一条规则用来扩大,一条规则用来缩小。第一条规则扩大预定操作:

    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"
  3. 运行以下命令来验证两条规则是否已激活:

    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 函数这样的 Amazon 服务组合来对特定应用程序需求作出反应。