本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
本节概述如何评估您的 Amazon Keyspaces 表预置容量大小是否合适。随着工作负载的演变,您应该相应地修改操作程序,尤其是在您的 Amazon Keyspaces 表以预置模式配置时,因为它们可能存在过度预置或预置不足的风险。
本节中所述的过程需要从支持您的生产应用程序的 Amazon Keyspaces 表捕获的统计信息。要了解您的应用程序行为,应该定义一个足够长的周期,以捕获应用程序的数据季节性特点。例如,如果您的应用程序表现出周模式,则不妨使用三周的周期来分析应用程序吞吐量需求。
如果您不知道从哪里开始,可根据至少一个月的使用数据来进行以下计算。
在评估容量时,对于 Amazon Keyspaces 表,您可以单独配置读取容量单位 (RCUs) 和写入容量单位 (WCU)。
如何从 Amazon Keyspaces 表中检索使用指标
要评估表容量,请监控以下 CloudWatch 指标并选择相应的维度来检索表格信息:
读取容量单位 | 写入容量单位 |
---|---|
|
|
|
|
|
|
您可以通过 AWS CLI 或来执行此操作 AWS Management Console。
在检索表格消耗指标之前,您需要先使用 CloudWatch API 捕获一些历史数据点。
首先创建两个文件:write-calc.json
和 read-calc.json
。这些文件代表表的计算。您需要更新一些字段(如下表所示)以匹配您的环境。
注意
如果表名称在账户中不是唯一的,则还必须指定键空间的名称。
字段名称 | 定义 | 示例 |
---|---|---|
<table-name> |
您要分析的表的名称 | SampleTable |
<period> |
您要用来评估利用率目标的周期(以秒为单位) | 对于 1 小时的周期,应指定:3600 |
<start-time> |
评估间隔的开始时间,以 ISO86 01 格式指定 | 2022-02-21T23:00:00 |
<end-time> |
评估间隔的结束时间,以 ISO86 01 格式指定 | 2022-02-22T06:00:00 |
写入计算文件将检索指定日期范围内的时间段中预置和使用的 WCU 数量。它还将生成可用于分析的利用率百分比。write-calc.json
文件的完整内容应类似于以下示例。
{
"MetricDataQueries": [
{
"Id": "provisionedWCU",
"MetricStat": {
"Metric": {
"Namespace": "AWS/Cassandra",
"MetricName": "ProvisionedWriteCapacityUnits",
"Dimensions": [
{
"Name": "TableName",
"Value": "<table-name>"
}
]
},
"Period": <period>,
"Stat": "Average"
},
"Label": "Provisioned",
"ReturnData": false
},
{
"Id": "consumedWCU",
"MetricStat": {
"Metric": {
"Namespace": "AWS/Cassandra",
"MetricName": "ConsumedWriteCapacityUnits",
"Dimensions": [
{
"Name": "TableName",
"Value": "<table-name>""
}
]
},
"Period": <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": "<start-time>",
"EndTime": "<end-time>",
"ScanBy": "TimestampDescending",
"MaxDatapoints": 24
}
读取计算文件使用类似的指标。此文件检索指定 RCUs日期范围内的预配置和消耗量。read-calc.json
文件的内容应类似于以下示例。
{
"MetricDataQueries": [
{
"Id": "provisionedRCU",
"MetricStat": {
"Metric": {
"Namespace": "AWS/Cassandra",
"MetricName": "ProvisionedReadCapacityUnits",
"Dimensions": [
{
"Name": "TableName",
"Value": "<table-name>"
}
]
},
"Period": <period>,
"Stat": "Average"
},
"Label": "Provisioned",
"ReturnData": false
},
{
"Id": "consumedRCU",
"MetricStat": {
"Metric": {
"Namespace": "AWS/Cassandra",
"MetricName": "ConsumedReadCapacityUnits",
"Dimensions": [
{
"Name": "TableName",
"Value": "<table-name>"
}
]
},
"Period": <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": "<start-time>",
"EndTime": "<end-time>",
"ScanBy": "TimestampDescending",
"MaxDatapoints": 24
}
创建文件后,即可开始检索利用率数据。
-
要检索写入利用率数据,请发出以下命令:
aws cloudwatch get-metric-data --cli-input-json file://write-calc.json
-
要检索读取利用率数据,请发出以下命令:
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 个数据点。
如何识别预置不足的 Amazon Keyspaces 表
对于大多数工作负载,如果一个表持续使用其预置容量超过 80%,该表将被视为预置不足。
突发容量是 Amazon Keyspaces 的一项功能,它允许客户暂时消耗WCUs 超过 RCUs最初预配置的容量(超过为表定义的每秒预配置吞吐量)。创建容量暴增的目的是应对因特殊事件或使用量高峰而突然增加的流量。这个容量暴增是有限的,要了解更多信息,请参阅在 Amazon Keyspaces 中有效使用容量爆增。一旦未使用的 RCUs 容量用完,如果您尝试消耗的容量超过预配置的容量,则可能会遇到低容量吞吐量错误事件。 WCUs 当您的应用程序流量接近 80% 的利用率时,您遇到吞出容量不足错误事件的风险就会大大增加。
80% 的利用率规则因数据的季节性和流量增长而异。考虑以下场景:
-
如果您的流量在过去 12 个月中一直稳定在大约 90% 的利用率,那么您的表容量正合适
-
如果您的应用程序流量在不到 3 个月内以每月 8% 的速度增长,那么您将达到 100% 利用率
-
如果您的应用程序流量在略长于 4 个月内以每月 5% 的速度增长,那么您仍然将达到 100% 利用率
以上查询的结果可以说明您的利用率。将它们作为指导,来进一步评估其他指标,以帮助您在需要时选择增加表容量(例如:每月或每周增长率)。与您的运营团队合作,为您的工作负载和表定义一个合适的百分比。
在有些特殊场景中,当您每天或每周进行数据分析时,会发现数据是倾斜的。例如,季节性应用程序在工作时间会出现使用量激增情况(但在工作时间之外则降至接近零),您可以使用计划 Application Auto Scaling 来指定一天中什么时间(以及一周中的星期几)增加预置容量,以及什么时间减少预置容量。即使您的季节性不那么明显,也可以利用 Amazon Keyspaces 表自动扩缩配置,而无需为了满足繁忙时段的需求而设定较高的容量。
如何识别过度预置的 Amazon Keyspaces 表
从上述脚本中获得的查询结果提供了执行某些初始分析所需的数据点。如果您的数据集在多个时间间隔内显示为利用率低于 20%,则您的表可能配置过度。要进一步定义是否需要减少 WCUs 和 RCU 的数量,应在间隔内重新查看其他读数。
当您的表包含多个低使用量间隔时,您可以使用 Application Auto Scaling 策略,计划 Application Auto Scaling 或者为表配置基于利用率的默认 Application Auto Scaling 策略。
如果您的工作负载具有低利用率与高限制比(间隔内的最大值 (ThrottleEvents) /最小 (ThrottleEvents)),则当您的工作负载非常激增,流量在特定日期(或一天中的时间)显著增加,但其他方面却持续较低时,可能会发生这种情况。在这些场景中,使用计划 Application Auto Scaling 可能很有好处。