本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 优化 Amazon Keyspaces 表的成本 本节介绍有关如何优化现有 Amazon Keyspaces 表的成本的最佳实践。您应该查看以下策略，看看哪种成本优化策略最适合您的需求，并以迭代方式处理它们。每个策略都概述了可能影响成本的因素、如何寻找优化成本的机会，以及有关如何实施这些最佳实践以帮助您节省成本的规范性指导。 **Topics** + [在表级别评估您的成本](CostOptimization_TableLevelCostAnalysis.md) + [评估表的容量模式](CostOptimization_TableCapacityMode.md) + [评估表的 Application Auto Scaling 设置](CostOptimization_AutoScalingSettings.md) + [在 Amazon Keyspaces 中找到未使用的资源以优化成本](CostOptimization_UnusedResources.md) + [评估您的表使用模式来优化性能和成本](CostOptimization_TableUsagePatterns.md) + [评估预置容量大小是否合适](CostOptimization_RightSizedProvisioning.md) # 在表级别评估您的成本 中的Cost Explorer工具 AWS 管理控制台 允许您查看按类型细分的成本，例如读取、写入、存储和备份费用。您还可以查看按时段（例如月或日）汇总的这些成本。 Cost Explorer 的一个常见挑战是，您无法轻松地只查看一个特定表的成本，因为 Cost Explorer 不允许您按特定表的成本进行筛选或分组。您可以在 Amazon Keyspaces 控制台的**监控**选项卡上查看每个表的**可计费表大小(字节)** 指标。如果您需要每个表的更多成本相关信息，本节将向您展示如何在 Cost Explorer 中使用[标签](tagging-keyspaces.md)执行单个表的成本分析。 **Topics** + [如何查看单个 Amazon Keyspaces 表的成本](#CostOptimization_TableLevelCostAnalysis_ViewInfo) + [Cost Explorer 的默认视图](#CostOptimization_TableLevelCostAnalysis_CostExplorer) + [如何在 Cost Explorer 中使用和应用表标签](#CostOptimization_TableLevelCostAnalysis_Tagging) ## 如何查看单个 Amazon Keyspaces 表的成本 您可以在控制台中查看有关 Amazon Keyspaces 表的基本信息，包括主键架构、计费表大小以及与容量相关的指标。您可以使用表的大小来计算表的每月存储成本。例如，美国东部（弗吉尼亚北部） AWS 区域每 GB 0.25 美元。 如果表使用预置容量模式，则还会返回当前读取容量单位 (RCU) 和写入容量单位 (WCU) 设置。您可以使用此信息来计算表当前的读取和写入成本。请注意，这些成本可能会发生变化，特别是如果您已为表配置 Amazon Keyspaces 自动扩缩。 ## Cost Explorer 的默认视图 Cost Explorer 的默认视图提供显示已用资源（例如吞吐量和存储）的成本的图表。您可以选择按时段对这些成本进行分组，例如按月或按日列出总值。存储、读取、写入和其他类别的成本也可以进行细分和比较。 ![\[图中显示 Cost Explorer 视图中的使用资源成本。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/CostOptimization/CostExplorerView.png) ## 如何在 Cost Explorer 中使用和应用表标签 默认情况下，Cost Explorer 不会提供任何一个特定表的成本汇总，因为它会将多个表的成本合并为一个总额。不过，您可以使用 [AWS 资源标记](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)，通过元数据标签来标识各个表。标签是可用于多种用途的键值对，例如标识属于某个项目或部门的所有资源。有关更多信息，请参阅 [对 Amazon Keyspaces 资源使用标签和标注](tagging-keyspaces.md)。 在这个例子中，我们使用一个名为的表**MyTable**。 1. 使用密钥为 t **able\$1name** 和值设置标签。**MyTable** 1. [在 Cost Explorer 中激活标签](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)，然后筛选标签值，以便更清楚地了解每个表的成本。 **注意** 标签可能需要一两天的时间才会开始显示在 Cost Explorer 中 您可以在控制台中自己设置元数据标签，也可以使用 CQL、或 SDK 以编程方式设置元数据标签。 AWS CLI AWS 考虑一下，在您组织的新表创建流程中要求设置 **table\$1name** 标签。有关更多信息，请参阅 [使用标签为 Amazon Keyspaces 创建成本分配报告](CostAllocationReports.md)。 # 评估表的容量模式 本节概述如何为 Amazon Keyspaces 表选择合适的容量模式。每种模式都经过优化，以满足不同工作负载对吞吐量变化的响应能力以及使用量计费方式的需求。在制定决策时，您必须平衡这些因素。 **Topics** + [有哪些表容量模式可用](#CostOptimization_TableCapacityMode_Overview) + [何时选择按需容量模式](#CostOptimization_TableCapacityMode_OnDemand) + [何时选择预置容量模式](#CostOptimization_TableCapacityMode_Provisioned) + [选择表容量模式时需要考虑的其他因素](#CostOptimization_TableCapacityMode_AdditionalFactors) ## 有哪些表容量模式可用 创建 Amazon Keyspaces 表时，您必须选择按需容量模式或预置容量模式。有关更多信息，请参阅 [在 Amazon Keyspaces 中配置 read/write 容量模式](ReadWriteCapacityMode.md)。 **按需容量模式** 按需容量模式用于消除规划或预置 Amazon Keyspaces 表容量的需求。在此模式下，您的表会即时适应请求数，无需扩展或缩减任何资源（最高为表之前峰值吞吐量的两倍）。 按需容量表通过计算表的实际请求数进行计费，因此您只需按实际使用量付费，而不是按预置容量付费。 **预置容量模式** 预置容量模式是一种更为传统的模式，在这种模式下，您可以直接定义可供表用于处理请求的容量，也可以借助 Application Auto Scaling 来定义。由于在任何给定时间表都预置了具体容量，因此基于预置容量而不是请求数量进行计费。而且，如果请求数超出分配的容量，就会导致表拒绝请求，降低应用程序用户的体验。 预置容量模式要求既不过度预置表容量，也不让表容量预置不足，以降低吞出容量不足错误出现的可能性和优化成本。 ## 何时选择按需容量模式 在优化成本时，如果您有类似于下图的不可预测工作负载，则按需模式是您的最佳选择。 以下因素会导致此类工作负载： + 不可预测的请求时机（导致流量峰值） + 请求数量变动（由批量工作负载导致） + 某个时段内降至零或低于峰值的 18%（由开发或测试环境导致） ![\[图中显示了具有随机流量峰值的尖峰工作负载。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeOnDemand.png) 对于具有上述特征的工作负载，使用 Application Auto Scaling 来保持足够的容量以供表应对流量激增可能会导致不良后果。要么表过度预置，成本超出必要范围，要么表预置不足，请求导致了不必要的吞出容量不足错误。在这种情况下，按需容量表是更好的选择。 由于按需容量表按请求进行计费，您无需在表级别执行任何其他操作来优化成本。您应该定期评估按需容量表，以验证工作负载是否仍然具备上述特征。如果工作负载已经稳定，则可考虑改为预置模式以保持成本优化。 ## 何时选择预置容量模式 适合预置容量模式的工作负载应该是具有可预测使用模式的工作负载，如下图所示。 以下因素有助于实现可预测的工作负载： + 给定时段或一天内的可预测/周期性流量 + 短期内流量爆发有限 ![\[图中显示了易于预测且峰值流量有限的工作负载。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeProvisioned.png) 由于给定时段或一天内的流量更加稳定，您可以将预置容量设置为相对接近于表的实际使用量。预置容量表的成本优化过程归根到底是一个练习的过程，即在不增加表的 `ThrottledRequests` 事件的情况下，让预置容量（蓝线）尽可能靠近使用容量（橙线）。两条线之间的空间既是容量浪费，又是避免吞出容量不足错误导致用户体验欠佳的保障。 Amazon Keyspaces 为预置容量表提供 Application Auto Scaling，该功能会自动为您实现均衡。您可以跟踪全天使用的容量，并根据一些变量来配置表的预置容量。 **最小容量单位** 您可以设置表的最小容量来限制吞出容量不足错误的发生，但这不会降低表的成本。如果您的表有一段时间使用量较低，然后突然出现高使用量，那么设置最小值可以防止 Application Auto Scaling 将表容量设置得过低。 **最大容量单位** 您可以设置表的最大容量，以限制将表扩大到超出预期值。对于无需大规模负载测试的开发或测试表，可考虑应用最大值。您可以为任意表设置最大值，但在生产环境中使用该表时，请务必定期根据表的使用基准评估此设置，以防止意外出现吞出容量不足错误。 **目标利用率** 对于预置容量表，设置表的目标利用率是优化其成本的主要方法。将此值设置为较低的百分比会提高表的过度预置程度，进而增加成本，但可以降低出现吞出容量不足错误的风险。将此值设置为较高的百分比可以降低表的过度预置程度，但会提高出现吞出容量不足错误的风险。 ## 选择表容量模式时需要考虑的其他因素 在两种容量模式之间做出选择时，还需要考虑另外一些因素。 在两种表模式之间做出选择时，请考虑这种额外折扣对表的成本有多大的影响。在许多情况下，在过度预置的预置容量表上，即使是相对不可预测的工作负载，采用预留容量也可能更经济。 **提高工作负载的可预测性** 在某些情况下，工作负载可能会同时具有可预测和不可预测的模式。虽然按需容量表可以轻松支持这种模式，但如果能够改善工作负载中不可预测的模式，则可能会降低成本。 造成这种模式的最常见原因之一是批量导入。这种类型的流量通常会超过表的基准容量，以至于在运行表时出现吞出容量不足错误。要在预置容量表上确保此类工作负载的运行，请考虑以下选项： + 如果批处理按照预定时间进行，则可以在运行之前，计划增加应用程序自动扩缩容量。 + 如果批处理随机进行，则可以考虑尝试延长运行所需的时间，而不是尽快执行。 + 为导入操作添加一个加速期，在此期间，开始时导入的速度较慢，但会在几分钟内缓慢加快，直到 Application Auto Scaling 有机会开始调整表容量。 # 评估表的 Application Auto Scaling 设置 本节概述如何评估 Amazon Keyspaces 表的 Application Auto Scaling 设置。[Amazon Keyspaces Application Auto Scaling](autoscaling.md) 是一项功能，用于根据您的应用程序流量和目标利用率指标来管理表吞吐量。这可以确保您的表具有应用程序模式所需的容量。 Application Auto Scaling 服务将监控您当前的表利用率，并与目标利用率值 `TargetValue` 作比较。当需要增加或减少分配的容量时，它会通知您。 **Topics** + [了解 Application Auto Scaling 设置](#CostOptimization_AutoScalingSettings_UnderProvisionedTables) + [如何识别具有低目标利用率 (<=50%) 的表](#CostOptimization_AutoScalingSettings_IdentifyLowUtilization) + [如何处理具有季节性差异的工作负载](#CostOptimization_AutoScalingSettings_SeasonalVariance) + [如何处理具有未知模式的尖峰工作负载](#CostOptimization_AutoScalingSettings_UnknownPatterns) + [如何处理具有关联应用程序的工作负载](#CostOptimization_AutoScalingSettings_BetweenRanges) ## 了解 Application Auto Scaling 设置 为目标利用率、初始步骤和最终值定义正确的值是一项需要运营团队参与的活动。这让您可以根据应用程序的历史使用量来适当地定义值，以便触发 Application Auto Scaling 策略。利用率目标是总容量的百分比值，需要在一段时间内达到后，才会应用 Application Auto Scaling 规则。 当您设置**高利用率目标（大约 90%）**时，意味着流量在一段时间内高于 90% 后才会激活 Application Auto Scaling。除非您的应用程序非常稳定且不会收到高峰流量，否则不应使用高利用率目标。 当您设置非常**低的利用率目标（低于 50%）**时，意味着您的应用程序需要达到预置容量的 50% 后才会触发 Application Auto Scaling 策略。除非您的应用程序流量以非常激进的速度增长，否则这通常会造成未用的容量和浪费的资源。 ## 如何识别具有低目标利用率 (<=50%) 的表 您可以使用 AWS CLI 或 AWS 管理控制台 在 Amazon Keyspaces 资源`TargetValues`中监控和识别您的应用程序 Auto Scaling 策略。 **注意** 当您在预置容量模式下结合使用多区域表和 Amazon Keyspaces 自动扩缩时，请务必使用 Amazon Keyspaces API 操作来配置自动扩缩。Amazon Keyspaces 代表您调用的底层 Application Auto Scaling API 操作不具有多区域功能。有关更多信息，请参阅 [在 Amazon Keyspaces 中查看多区域表的预置容量和自动扩缩设置](tables-mrr-view.md)。 ------ #### [ AWS CLI ] 1. 通过运行以下命令返回整个资源列表： ``` aws application-autoscaling describe-scaling-policies --service-namespace cassandra ``` 此命令将返回发给任何 Amazon Keyspaces 资源的 Application Auto Scaling 策略的完整列表。如果您只想检索来自特定表的资源，则可以添加 `–resource-id parameter`。例如： ``` aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name” ``` 1. 通过运行以下命令仅返回特定表的自动扩缩策略 ``` aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name” ``` Application Auto Scaling 策略的值在下面突出显示。您需要确保目标值大于 50%，以避免过度预置。您应该得到类似如下的结果： ``` { "ScalingPolicies": [ { "PolicyARN": "arn:aws:autoscaling:us-east-1:111122223333:scalingPolicy::resource/keyspaces/table/table-name-scaling-policy", "PolicyName": $”, "ServiceNamespace": "cassandra", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:WriteCapacityUnits", "PolicyType": "TargetTrackingScaling", "TargetTrackingScalingPolicyConfiguration": { "TargetValue": 70.0, "PredefinedMetricSpecification": { "PredefinedMetricType": "KeyspacesWriteCapacityUtilization" } }, "Alarms": [ ... ], "CreationTime": "2022-03-04T16:23:48.641000+10:00" }, { "PolicyARN": "arn:aws:autoscaling:us-east-1:111122223333:scalingPolicy::resource/keyspaces/table/table-name-scaling-policy", "PolicyName":$”, "ServiceNamespace": "cassandra", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:ReadCapacityUnits", "PolicyType": "TargetTrackingScaling", "TargetTrackingScalingPolicyConfiguration": { "TargetValue": 70.0, "PredefinedMetricSpecification": { "PredefinedMetricType": "KeyspacesReadCapacityUtilization" } }, "Alarms": [ ... ], "CreationTime": "2022-03-04T16:23:47.820000+10:00" } ] } ``` ------ #### [ AWS 管理控制台 ] 1. 登录 AWS 管理控制台 并导航到 “入[门” 中的 CloudWatch ](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html)服务页面 AWS 管理控制台。如有必 AWS 区域 要，请选择相应的。 1. 在左侧导航栏上，选择**表**。在**表**页面上，选择表的**名称**。 1. 在**表详细信息**页面的**容量**选项卡上，查看表的 Application Auto Scaling 设置。 ------ 如果您的目标利用率值小于或等于 50%，则应浏览您的表利用率指标，看看这些指标是[配置不足还是过度配置](CostOptimization_RightSizedProvisioning.md)。 ## 如何处理具有季节性差异的工作负载 考虑以下场景：您的应用程序大部分时间都在最低平均值下运行，但是利用率目标较低，所以您的应用程序可以对一天中特定时间发生的事件做出快速反应，并且您有足够的容量来避免节流。当您的应用程序在正常办公时间（上午 9 点到下午 5 点）非常繁忙，但在下班后处于基本工作水平时，这种场景很常见。因为一些用户会在上午 9 点前开始连接，所以应用程序使用这个低阈值来实现快速提高，以便在高峰时段达到*所需*容量。 此场景可能是这样的： + 下午 5 点到上午 9 点之间，`ConsumedWriteCapacityUnits` 单位保持在 90 到 100 之间 + 用户在上午 9 点之前开始连接到应用程序，容量单位显著增加（您看到的最大值为 1500WCU） + 平均下来，您的应用程序在工作时间内的使用量在 800 到 1200 之间变化 如果前面的场景适合您的应用程序，可考虑使用[计划 Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html)，在这种情况下，您的表仍可以配置 Application Auto Scaling 规则，但目标利用率不那么激进，只是在您需要的特定间隔预置了额外容量。 您可以使用执行以下步骤 AWS CLI 来创建根据一天中的时间和一周中的某一天执行的定时自动缩放规则。 1. 使用 Application Auto Scaling将您的 Amazon Keyspaces 表注册为可扩展目标。可扩展目标是 Application Auto Scaling 可以扩大或缩小的资源。 ``` aws application-autoscaling register-scalable-target \ --service-namespace cassandra \ --scalable-dimension cassandra:table:WriteCapacityUnits \ --resource-id keyspace/keyspace-name/table/table-name \ --min-capacity 90 \ --max-capacity 1500 ``` 1. 根据您的要求设置预定操作。 在此场景中，您需要两条规则：一条规则用来扩展，一条规则用来缩减。用来扩展预定操作的第一条规则如下面的示例所示。 ``` aws application-autoscaling put-scheduled-action \ --service-namespace cassandra \ --scalable-dimension cassandra:table:WriteCapacityUnits \ --resource-id keyspace/keyspace-name/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 cassandra \ --scalable-dimension cassandra:table:WriteCapacityUnits \ --resource-id keyspace/keyspace-name/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" ``` 1. 运行以下命令来验证两条规则是否已激活： ``` aws application-autoscaling describe-scheduled-actions --service-namespace cassandra ``` 应得到类似如下的结果： ``` { "ScheduledActions": [ { "ScheduledActionName": "my-5-8-scheduled-down-action", "ScheduledActionARN": "arn:aws:autoscaling:us-east-1:111122223333:scheduledAction::resource/keyspaces/table/table-name:scheduledActionName/my-5-8-scheduled-down-action", "ServiceNamespace": "cassandra", "Schedule": "cron(15 17 ? * MON-FRI *)", "Timezone": "Australia/Brisbane", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra: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:us-east-1:111122223333:scheduledAction::resource/keyspaces/table/table-name:scheduledActionName/my-8-5-scheduled-action", "ServiceNamespace": "cassandra", "Schedule": "cron(45 8 ? * MON-FRI *)", "Timezone": "Australia/Brisbane", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:WriteCapacityUnits", "ScalableTargetAction": { "MinCapacity": 800, "MaxCapacity": 1500 }, "CreationTime": "2022-03-15T17:28:57.816000+10:00" } ] } ``` 下图显示了一个始终保持 70% 目标利用率的示例工作负载。请注意观察，如何做到自动扩缩规则仍在应用，而吞吐量不会降低。 ![\[显示写入使用情况（每秒单位数）的图表，将一天内的预置容量与消耗容量进行比较。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings3.png) 放大图片，我们可以看到，应用程序中有一个高峰，它触发了 70% 自动扩缩阈值，迫使自动扩缩启动，来为表提供所需的额外容量。预定的自动扩缩操作将影响最大值和最小值，需要由您来设置这些值。 ![\[以更详细的视图呈现其中显示写入使用情况（每秒单位数）的图表，将预置容量与消耗容量进行比较，在特定时间放大。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings4.png) ![\[以更详细的视图呈现其中显示写入使用情况（每秒单位数）的图表，将一天内的预置容量与消耗容量进行比较。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings5.png) ## 如何处理具有未知模式的尖峰工作负载 在这种场景中，应用程序使用非常低的利用率目标，因为您尚不清楚应用程序的模式，需要确保工作负载不遇到吞出容量不足错误。 可考虑改用[按需容量模式](ReadWriteCapacityMode.OnDemand.md)。按需模式表非常适合您不知道流量模式的尖峰工作负载。在按需容量模式下，您按请求为应用程序在表上执行的数据读取和写入付费。您无需指定应用程序预计将执行多少读取和写入吞吐量，因为 Amazon Keyspaces 会根据工作负载的增减来即时做出调整。 ## 如何处理具有关联应用程序的工作负载 在这种场景中，应用程序依赖其他系统，例如在批处理场景中，根据应用程序逻辑中的事件，您会遇到非常大的流量尖峰。 可考虑开发自定义 Application Auto Scaling 逻辑，以便对那些您可以根据自己的具体需求增加表容量和 `TargetValues` 的事件作出反应。您可以从 λ Amazon EventBridge 和 Step Functi AWS ons 等服务组合中受益并使用这些服务来满足您的特定应用需求。 # 在 Amazon Keyspaces 中找到未使用的资源以优化成本 本部分概述如何定期评估未使用资源。随着应用程序需求的演变，您应确保没有未使用的资源，并且不会导致不必要的 Amazon Keyspaces 成本。下述程序使用 Amazon CloudWatch 指标来识别未使用的资源并采取措施降低成本。 您可以使用监控 Amazon Keyspaces CloudWatch，它收集来自亚马逊密钥空间的原始数据并将其处理为可读的、近乎实时的指标。这些统计数据会保留一段时间，这样您便可以访问历史信息，更好地了解使用情况。默认情况下，Amazon Keyspaces 指标数据会自动发送到。 CloudWatch 有关更多信息，请参阅[什么是亚马逊 CloudWatch？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 以及《*亚马逊 CloudWatch 用户指南*》中的[指标保留率](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#metrics-retention)。 **Topics** + [如何确定未使用的资源](#CostOptimization_UnusedResources_Identifying) + [确定未使用的表资源](#CostOptimization_UnusedResources_Tables) + [清理未使用的表资源](#CostOptimization_UnusedResources_Tables_Cleanup) + [清理未使用的 point-in-time恢复 (PITR) 备份](#CostOptimization_UnusedResources_Backups) ## 如何确定未使用的资源 要识别未使用的表，您可以在 30 天内查看以下 CloudWatch 指标，以了解特定表上是否存在任何活跃的读取或写入操作： **`ConsumedReadCapacityUnits`** 在指定时间段内使用的读取容量单位数，这样便可以跟踪您在已占用容量中使用的容量。您可以检索表已使用的总读取容量。 **`ConsumedWriteCapacityUnits`** 在指定时间段内使用的写入容量单位数，这样便可以跟踪您在已占用容量中使用的容量。您可以检索表使用的总写入容量。 ## 确定未使用的表资源 Amazon CloudWatch 是一项监控和可观察性服务，它提供 Amazon Keyspaces 表指标，您可以用来识别未使用的资源。 CloudWatch 可以通过， AWS 管理控制台 也可以通过查看指标 AWS Command Line Interface。 ------ #### [ AWS Command Line Interface ] 要通过查看您的表格指标 AWS Command Line Interface，您可以使用以下命令。 1. 首先，评估您的表的读取数： **注意** 如果表名称在账户中不是唯一的，则还必须指定键空间的名称。 ``` aws cloudwatch get-metric-statistics --metric-name ConsumedReadCapacityUnits --start-time --end-time --period --namespace AWS/Cassandra --statistics Sum -- dimensions Name=TableName,Value= ``` 为了避免错误地将表标识为未使用，请评估较长时段内的指标。选择合适的开始时间和结束时间范围（如 **30 天**）以及合适的时间段（如 **86400**）。 在返回的数据中，任何大于 **0** 的 **Sum**（合计）都表示您所评估的表在该时间段内收到了读取流量。 以下结果显示表在评估时段内收到了读取流量： ``` { "Timestamp": "2022-08-25T19:40:00Z", "Sum": 36023355.0, "Unit": "Count" }, { "Timestamp": "2022-08-12T19:40:00Z", "Sum": 38025777.5, "Unit": "Count" }, ``` 以下结果显示表在评估时段内未收到读取流量： ``` { "Timestamp": "2022-08-01T19:50:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-20T19:50:00Z", "Sum": 0.0, "Unit": "Count" }, ``` 1. 接下来，评估表的写入数量： ``` aws cloudwatch get-metric-statistics --metric-name ConsumedWriteCapacityUnits --start-time --end-time --period --namespace AWS/Cassandra --statistics Sum -- dimensions Name=TableName,Value= ``` 为了避免错误地将表标识为未使用，您需要评估较长时段内的指标。选择合适的开始时间和结束时间范围（例如 **30 天**）以及合适的时间段，例如 **86400**。 在返回的数据中，任何大于 **0** 的 **Sum**（合计）都表示您所评估的表在该时间段内收到了读取流量。 以下结果显示表在评估时段内收到了写入流量： ``` { "Timestamp": "2022-08-19T20:15:00Z", "Sum": 41014457.0, "Unit": "Count" }, { "Timestamp": "2022-08-18T20:15:00Z", "Sum": 40048531.0, "Unit": "Count" }, ``` 以下结果显示表在评估时段内未收到写入流量： ``` { "Timestamp": "2022-07-31T20:15:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-19T20:15:00Z", "Sum": 0.0, "Unit": "Count" }, ``` ------ #### [ AWS 管理控制台 ] 您可以按照以下步骤，通过 AWS 管理控制台评估资源利用率。 1. 登录 AWS 管理控制台 并导航到 CloudWatch 服务页面，网址为[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)。如有必要 AWS 区域 ，请在控制台右上角选择相应的选项。 1. 在左侧导航栏中，找到**指标**部分，然后选择**所有指标**。 1. 以上操作将打开一个控制面板，其中包含两个面板。在顶部面板中，您可以看到当前绘成图表的指标。在底部，您可以选择用于绘制图表的指标。在底部面板中选择“Amazon Keyspaces”。 1. 在 Amazon Keyspaces 指标选择面板中，选择**表指标**类别以显示当前区域中表的指标。 1. 向下滚动菜单，找到您的表名称，然后选择表的指标 `ConsumedReadCapacityUnits` 和 `ConsumedWriteCapacityUnits`。 1. 选择**绘成图表的指标 (2)** 选项卡，然后将**统计数据**列调整为**总计**。 1. 为了避免错误地将表标识为未使用，请评估较长时段内的表指标。在图表面板顶部选择相应的时间范围（如 1 个月）来评估表。选择**自定义**，在下拉菜单中选择 **1 个月**，然后选择**应用**。 1. 评估您的表的绘成图表的指标，以确定是否使用了该表。大于 **0** 的指标表示在评估时间段内使用了表。读取和写入均为 **0** 的空白图表表示表未使用。 ------ ## 清理未使用的表资源 如果您已确定未使用的表资源，则可以通过以下方式降低其持续成本。 **注意** 如果您已确定未使用的表，但仍希望将其保持可用状态，以防将来需要访问该表，请考虑将其切换到按需模式。否则，您可以考虑删除该表。 **容量模式** Amazon Keyspaces 对读取、写入和存储 Amazon Keyspaces 表中的数据收费。 Amazon Keyspaces 具有按需和预置这[两种容量模式](ReadWriteCapacityMode.md)，它们对表上的读取和写入处理采用特定的计费方式。 read/write 容量模式控制您如何为读取和写入吞吐量收费，以及如何管理容量。 对于按需模式表，您无需指定预期应用程序执行的读写吞吐量。Amazon Keyspaces 按照读取请求单位和写入请求单位对应用程序在表上执行的读取和写入操作收费。如果表上没有活动，则您无需为吞吐量付费，但仍会产生存储费用。 **删除表** 如果您发现了一个未使用的表并想将其删除，可考虑先备份或导出数据。 完成的备份 AWS Backup 可以利用冷存储分层，从而进一步降低成本。有关如何使用生命周期将备份移动到冷存储的信息，请参阅[管理备份计划](https://docs.aws.amazon.com/aws-backup/latest/devguide/about-backup-plans)文档。 备份表后，您可以选择通过 AWS 管理控制台 或通过 AWS Command Line Interface将其删除。 ## 清理未使用的 point-in-time恢复 (PITR) 备份 Amazon Keyspaces 提供 Point-in-time恢复功能，可提供 35 天的连续备份，以帮助您防止意外写入或删除。PITR 备份会产生相关成本。 请参阅文档 [使用 Amazon Keyspaces 的 point-in-time恢复功能备份和还原数据](PointInTimeRecovery.md)，确定您的表是否启用了可能不再需要的备份。 # 评估您的表使用模式来优化性能和成本 本节概述如何评估您是否高效地使用 Amazon Keyspaces 表。有些使用模式对于 Amazon Keyspaces 来说不是最佳的，在性能和成本方面还有优化的空间。 **Topics** + [执行更少的强一致性读取操作](#CostOptimization_TableUsagePatterns_StronglyConsistentReads) + [启用生存时间（TTL）](#CostOptimization_TableUsagePatterns_TTL) ## 执行更少的强一致性读取操作 Amazon Keyspaces 允许您根据每个请求来配置[读取一致性](consistency.md#ReadConsistency)。默认情况下，读取请求为最终一致性的。最终一致性读取的收费标准是 4KB 及以下数据量为 0.5 个 RCU。 大多数分布式工作负载具有灵活性，能够容许最终一致性。但是，也有一些访问模式需要强一致性读取。强一致性读取的收费标准是 4KB 及以下数据量为 1 个 RCU，读取成本基本上翻了一倍。Amazon Keyspaces 让您能够灵活地在同一个表上使用这两种一致性模式。 您可以评估一下您的工作负载和应用程序代码，确认是否只在需要时才使用强一致性读取。 ## 启用生存时间（TTL） [存活时间 (TTL)](TTL.md) 通过自动使表中的数据过期，来帮助您简化应用程序逻辑和优化存储价格。系统会根据您设置的“存活时间”值自动从表中删除不再需要的数据。 # 评估预置容量大小是否合适 本节概述如何评估您的 Amazon Keyspaces 表预置容量大小是否合适。随着工作负载的演变，您应该相应地修改操作程序，尤其是在您的 Amazon Keyspaces 表以预置模式配置时，因为它们可能存在过度预置或预置不足的风险。 本节中所述的过程需要从支持您的生产应用程序的 Amazon Keyspaces 表捕获的统计信息。要了解您的应用程序行为，应该定义一个足够长的周期，以捕获应用程序的数据季节性特点。例如，如果您的应用程序表现出周模式，则不妨使用三周的周期来分析应用程序吞吐量需求。 如果您不知道从哪里开始，可根据至少一个月的使用数据来进行以下计算。 在评估容量时，对于 Amazon Keyspaces 表，您可以单独配置**读取容量单位 (RCUs)** 和**写入容量单位 (WCU**)。 **Topics** + [如何从 Amazon Keyspaces 表中检索使用指标](#CostOptimization_RightSizedProvisioning_ConsumptionMetrics) + [如何识别预置不足的 Amazon Keyspaces 表](#CostOptimization_RightSizedProvisioning_UnderProvisionedTables) + [如何识别过度预置的 Amazon Keyspaces 表](#CostOptimization_RightSizedProvisioning_OverProvisionedTables) ## 如何从 Amazon Keyspaces 表中检索使用指标 要评估表容量，请监控以下 CloudWatch 指标并选择相应的维度来检索表格信息： | 读取容量单位 | 写入容量单位 | | --- | --- | | `ConsumedReadCapacityUnits` | `ConsumedWriteCapacityUnits` | | `ProvisionedReadCapacityUnits` | `ProvisionedWriteCapacityUnits` | | `ReadThrottleEvents` | `WriteThrottleEvents` | 您可以通过 AWS CLI 或来执行此操作 AWS 管理控制台。 ------ #### [ AWS CLI ] 在检索表格消耗指标之前，您需要先使用 CloudWatch API 捕获一些历史数据点。 首先创建两个文件：`write-calc.json` 和 `read-calc.json`。这些文件代表表的计算。您需要更新一些字段（如下表所示）以匹配您的环境。 **注意** 如果表名称在账户中不是唯一的，则还必须指定键空间的名称。 | 字段名称 | 定义 | 示例 | | --- | --- | --- | | | 您要分析的表的名称 | SampleTable | | | 您要用来评估利用率目标的周期（以秒为单位） | 对于 1 小时的周期，应指定：3600 | | | 评估间隔的起始时间，以 ISO8601格式指定 | 2022-02-21T23:00:00 | | | 评估间隔的结束时间，以 ISO8601 格式指定 | 2022-02-22T06:00:00 | 写入计算文件将检索指定日期范围内的时间段中预置和使用的 WCU 数量。它还将生成可用于分析的利用率百分比。`write-calc.json` 文件的完整内容应类似于以下示例。 ``` { "MetricDataQueries": [ { "Id": "provisionedWCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ProvisionedWriteCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Average" }, "Label": "Provisioned", "ReturnData": false }, { "Id": "consumedWCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ConsumedWriteCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": """ } ] }, "Period": , "Stat": "Sum" }, "Label": "", "ReturnData": false }, { "Id": "m1", "Expression": "consumedWCU/PERIOD(consumedWCU)", "Label": "Consumed WCUs", "ReturnData": false }, { "Id": "utilizationPercentage", "Expression": "100*(m1/provisionedWCU)", "Label": "Utilization Percentage", "ReturnData": true } ], "StartTime": "", "EndTime": "", "ScanBy": "TimestampDescending", "MaxDatapoints": 24 } ``` 读取计算文件使用类似的指标。此文件检索指定 RCUs日期范围内的预配置和消耗量。`read-calc.json` 文件的内容应类似于以下示例。 ``` { "MetricDataQueries": [ { "Id": "provisionedRCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ProvisionedReadCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Average" }, "Label": "Provisioned", "ReturnData": false }, { "Id": "consumedRCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ConsumedReadCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Sum" }, "Label": "", "ReturnData": false }, { "Id": "m1", "Expression": "consumedRCU/PERIOD(consumedRCU)", "Label": "Consumed RCUs", "ReturnData": false }, { "Id": "utilizationPercentage", "Expression": "100*(m1/provisionedRCU)", "Label": "Utilization Percentage", "ReturnData": true } ], "StartTime": "", "EndTime": "", "ScanBy": "TimestampDescending", "MaxDatapoints": 24 } ``` 创建文件后，即可开始检索利用率数据。 1. 要检索写入利用率数据，请发出以下命令： ``` aws cloudwatch get-metric-data --cli-input-json file://write-calc.json ``` 1. 要检索读取利用率数据，请发出以下命令： ``` aws cloudwatch get-metric-data --cli-input-json file://read-calc.json ``` 这两个查询的结果都是一系列 JSON 格式的数据点，可用于分析。您的结果取决于您指定的数据点数量、周期和您自己的特定工作负载数据。它可能类似于以下示例。 ``` { "MetricDataResults": [ { "Id": "utilizationPercentage", "Label": "Utilization Percentage", "Timestamps": [ "2022-02-22T05:00:00+00:00", "2022-02-22T04:00:00+00:00", "2022-02-22T03:00:00+00:00", "2022-02-22T02:00:00+00:00", "2022-02-22T01:00:00+00:00", "2022-02-22T00:00:00+00:00", "2022-02-21T23:00:00+00:00" ], "Values": [ 91.55364583333333, 55.066631944444445, 2.6114930555555556, 24.9496875, 40.94725694444445, 25.61819444444444, 0.0 ], "StatusCode": "Complete" } ], "Messages": [] } ``` **注意** 如果您指定了短周期和长时间范围，则可能需要修改 `MaxDatapoints` 值，该值在脚本中默认设置为 24。这表示每小时一个数据点，每天 24 个数据点。 ------ #### [ AWS 管理控制台 ] 1. 登录 AWS 管理控制台 并导航到 “入[门” 中的 CloudWatch ](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html)服务页面 AWS 管理控制台。如有必 AWS 区域 要，请选择相应的。 1. 在左侧导航栏中，找到“指标”部分，然后选择**所有指标**。 1. 这将打开一个控制面板，其中包含两个面板。顶部面板显示图表，底部面板显示要绘成图表的指标。选择“Amazon Keyspaces”面板。 1. 从子面板中选择**表指标**类别。这会显示当前表格 AWS 区域。 1. 识别您的表名，方法是向下滚动菜单并选择写入操作指标：`ConsumedWriteCapacityUnits` 和 `ProvisionedWriteCapacityUnits`。 **注意** 本例中使用了写入操作指标，但您也可以使用这些步骤绘制读取操作指标图。 1. 选择**绘成图表的指标(2)** 选项卡来修改公式。默认情况下，为图表 CloudWatch 选择统计函数 “**平均值**”。 1. 选中两个图表化指标（左侧的复选框）后，选择菜单**添加数学函数**，然后选择**常用**，再选择 **Percentage** 函数。重复该过程两次。 第一次选择 **Percentage** 函数。 第二次选择 **Percentage** 函数。 1. 此时，底部菜单中应该有四个指标。我们来进行 `ConsumedWriteCapacityUnits` 计算。为了保持一致，您需要将名称与您在本 AWS CLI 节中使用的名称相匹配。单击 **m1 ID** 并将此值更改为 **consumedWCU**。 1. 将统计函数从 **Average** 改为 **Sum**。此操作将自动创建另一个名为 **ANOMALY\$1DETECTION\$1BAND** 的指标。在此过程中，您可以通过删除新生成的 **ad1 指标**上的复选框来忽略它。 1. 重复步骤 8，将 **m2 ID** 重命名为 **provisionedWCU**。保留统计函数设置为 **Average**。 1. **选择 **Expression1** 标签并将该值更新为 **m1**，将标签更新为 “已消费”。 WCUs** **注意** 确保您只选择了 **m1**（左侧的复选框）和 **provisionedWCU** 以正确可视化数据。更新公式，方法是单击**详细信息**并将公式更改为 **consumedWCU/PERIOD(consumedWCU)**。这一步还可能生成另一个 **ANOMALY\$1DETECTION\$1BAND** 指标，但在此过程中，您可以忽略它。 1. 现在，您应该有两个图形：一个表示您在表 WCUs上的预配置，另一个表示已消耗 WCUs的资源。 1. 通过选择 Expression2 图形 (**e2**) 来更新百分比公式。将标签和重命名为 “ IDs **利用率百分比**”。重命名公式，以匹配 **100\$1(m1/provisionedWCU)**。 1. 清除除 **utilizationPercentage** 之外的所有指标的复选框，以可视化您的利用率模式。默认间隔设置为 1 分钟，但您可以根据需要随意修改。 您获得的结果取决于您的工作负载中的实际数据。利用率超过 100% 的间隔容易导致吞出容量不足错误事件。Amazon Keyspaces 提供[容量暴增](throughput-bursting.md)，但一旦这些容量耗尽，任何超过 100% 的使用都会遇到吞出容量不足错误事件。 ------ ## 如何识别预置不足的 Amazon Keyspaces 表 对于大多数工作负载，如果一个表持续使用其预置容量超过 80%，该表将被视为预置不足。 [突发容量](throughput-bursting.md)是 Amazon Keyspaces 的一项功能，允许客户暂时消耗 RCUs/WCUs 超过最初预配置的容量（超过为表定义的每秒预配置吞吐量）。创建容量暴增的目的是应对因特殊事件或使用量高峰而突然增加的流量。这个容量暴增是有限的，要了解更多信息，请参阅[在 Amazon Keyspaces 中有效使用容量爆增](throughput-bursting.md)。一旦未使用的 RCUs 容量用完，如果您尝试消耗的容量超过预配置的容量，则可能会遇到低容量吞吐量错误事件。 WCUs 当您的应用程序流量接近 80% 的利用率时，您遇到吞出容量不足错误事件的风险就会大大增加。 80% 的利用率规则因数据的季节性和流量增长而异。考虑以下场景： + 如果您的流量在过去 12 个月中一直**稳定**在大约 90% 的利用率，那么您的表容量正合适 + 如果您的应用程序流量在不到 3 个月内以每月 8% 的速度**增长**，那么您将达到 100% 利用率 + 如果您的应用程序流量在略长于 4 个月内以每月 5% 的速度**增长**，那么您仍然将达到 100% 利用率 以上查询的结果可以说明您的利用率。将它们作为指导，来进一步评估其他指标，以帮助您在需要时选择增加表容量（例如：每月或每周增长率）。与您的运营团队合作，为您的工作负载和表定义一个合适的百分比。 在有些特殊场景中，当您每天或每周进行数据分析时，会发现数据是倾斜的。例如，季节性应用程序在工作时间会出现使用量激增情况（但在工作时间之外则降至接近零），您可以使用[计划 Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html) 来指定一天中什么时间（以及一周中的星期几）增加预置容量，以及什么时间减少预置容量。即使您的季节性不那么明显，也可以利用 [Amazon Keyspaces 表自动扩缩](autoscaling.md)配置，而无需为了满足繁忙时段的需求而设定较高的容量。 ## 如何识别过度预置的 Amazon Keyspaces 表 从上述脚本中获得的查询结果提供了执行某些初始分析所需的数据点。如果您的数据集在多个时间间隔内显示为利用率低于 20%，则您的表可能配置过度。要进一步定义是否需要减少 WCUs 和 RCU 的数量，应在间隔内重新查看其他读数。 当您的表包含多个低使用量间隔时，您可以使用 Application Auto Scaling 策略，计划 Application Auto Scaling 或者为表配置基于利用率的默认 Application Auto Scaling 策略。 如果您的工作负载具有低利用率与高限制比（间隔内**的最大值 (ThrottleEvents) /最小 (ThrottleEvents)）**，则当您的工作负载非常激增，流量在特定日期（或一天中的时间）显著增加，但其他方面却持续较低时，可能会发生这种情况。在这些场景中，使用[计划 Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html) 可能很有好处。