管理 Parameter Store 吞吐量
Parameter Store 吞吐量定义了 Systems Manager 每秒可处理的 API 事务数（TPS）。吞吐量设置适用于整个 Parameter Store，而非单个 API。默认情况下，Parameter Store 配置了通常适用于中低数量工作负载的标准吞吐量配额。您可以为更高数量的工作负载启用更高的吞吐量，从而提高您的账户和区域支持的最大每秒事务数。您可以根据需要启用和禁用更高的吞吐量。
Parameter Store 中的吞吐量配额
下表列出了对于不同的 API 类别，使用默认吞吐量和更高吞吐量的事务数限制。API 操作包括使用 AWS 控制台、AWS CLI 命令和应用程序读取。有关配额和速率限制的更多信息，请参阅 AWS Systems Manager endpoints and quotas。
| API 操作 | 默认吞吐量 | 提高吞吐量 |
|---|---|---|
| GetParameter、GetParameters 和 GetParametersByPath | 40 TPS，所有这三个 API 操作共享 |
GetParameter：10,000 TPS；GetParameters：1,000 TPS；GetParametersByPath：100 TPS |
| DeleteParameter 和 DeleteParameters | 3 TPS |
5 TPS |
| DescribeParameters、GetParameterHistory、LabelParameterVersion、UnlabelParameterVersion 和 PutParameter | 3 TPS |
10 TPS |
在本文中，一个事务是指在单个区域中一个账户内的一个 API 操作。例如，以下命令会创建单个事务。
aws ssm get-parameter --name "/myapp/prod/log-level"
API 操作可能会分布于若干应用程序中。例如，以下每种场景都会达到 40 TPS 的默认吞吐量上限：
-
1 个应用程序每秒发出 40 个
GetParameter调用。 -
10 个应用程序每秒发出 4 个
GetParameter调用。 -
40 个应用程序每秒发出 1 个
GetParameter调用。
吞吐量限制适用于一个类别中的所有 API。例如，下文所述一个应用程序的同时参数调用合计会达到参数检索 API 的默认限制（40 TPS）：
-
GetParameter每秒发出 25 次调用。 -
GetParameters每秒发出 10 次调用。 -
GetParameterByPath每秒发出 5 次调用。
DescribeParameters 调用有单独的吞吐量限制。应用程序在进行上述调用的同时，还可以每秒发出 3 个 DescribeParameters 调用，而不会超过标准吞吐量的总体限制。
如果生产请求在标准操作或计划高流量期间超过吞吐量限制，请使用以下优化技术。
优化 Parameter Store 中的吞吐量
当 Parameter Store 在较短的间隔时间内收到多个参数请求时，您的应用程序可能会被实施节流。例如，CloudWatch Logs 或您的应用程序日志会显示 SDK 在调用 GetParameter、GetParameters 或 GetParametersByPath 时引发的 ThrottlingException 或 RateExceeded 错误。对于其他情况，应用程序逻辑会成功重试 API 调用，但应用程序延迟会增加。结果可能导致应用程序中断、用户体验不佳、部署失败、变通方法复杂以及开发人员时间浪费。
多种因素都可能导致应用程序达到 Parameter Store 配额限制，包括：
-
应用程序因流量峰值快速横向扩展。例如，您的应用程序通常在 5 个 Amazon EC2 实例上运行。当流量突然增加时，Amazon EC2 Auto Scaling 会另外启动 50 个实例。如果每个实例在启动时都读取参数，则合计请求数可能会超过默认的请求限制。
-
容器服务同时启动许多任务。例如，Amazon ECS 服务可能会在更新期间启动许多替换任务，并且每个任务可能会在启动时读取 Parameter Store 中的设置。
-
Lambda 函数同时接收许多请求。例如，Lambda 可能会启动许多函数环境来处理增加的流量。每个函数环境在启动时都可能会读取参数。
-
构建或发布进程会在很短的间隔时间内读取许多参数。例如，某个构建作业可能会读取多个应用程序或环境的设置。
-
应用程序按路径读取许多参数。例如，您的应用程序重复读取
/myapp/prod/下的所有参数，而不是只读取所需的特定参数。这些重复的请求可能会超过默认的请求限制。
可以通过以下补充方式解决 Parameter Store 节流问题：
-
降低吞吐量
应用程序检索的数据量可能超过需要，或者检索方式效率低下。
-
启用更高的吞吐量
可以通过增加指定区域和账户的吞吐量配额来提高应用程序韧性。对于高流量时段，可以随时启用和禁用更高的吞吐量设置。对于经常产生节流错误的生产工作负载，请考虑永久启用该设置。
在 Parameter Store 中降低吞吐量
无论是使用标准吞吐量还是更高的吞吐量，都应检查对 Parameter Store 的调用频率和类型。对于某些场景，可以在不更改参数的情况下减少请求数。由于成本取决于使用量而不是订阅或等级模式，因此可减少计费类 API 交互。
-
在应用程序中缓存参数值，而不是在每个请求中读取相同的值。
例如，假设您的应用程序每分钟多次读取
/myapp/prod/log-level，则该应用程序可以读取该值一次并在短时间内重复使用该值。这一方法可减少对 Parameter Store 的重复调用。为经常更改的值选择较短的重用周期，并为很少更改的值选择较长的重用周期。 -
当知道多个参数的名称，请使用 GetParameters。
例如，可以在单个
GetParameters请求中检索参数/myapp/prod/database/host、/myapp/prod/log-level和/myapp/prod/vendor/merchant-id的列表，而不是分别为这些参数调用 GetParameter。 -
避免读取的参数数量超过应用程序的需要。
如果应用程序只需少数几个已知的参数，请使用
GetParameter或GetParameters，而不是重复读取整个路径（例如/myapp/prod/）。当应用程序需要某个路径下的一组参数时，请使用 GetParametersByPath。使用更高的吞吐量时，GetParameter的配额为GetParametersByPath配额的 100 倍。 -
在同时启动许多资源时分散参数读取操作。
例如，假设在更新期间会启动许多 Amazon EC2 实例或 Amazon ECS 任务，请避免让所有资源恰好在同一时间读取参数。配额按秒计算。如果可能，应一次读取参数并将参数值缓存到应用程序中，或者增加一点延迟来确保请求就不会在同一秒内全部发生。
-
对于 Lambda 函数，请考虑使用 AWS 参数和密钥 Lambda 扩展。
该扩展可以将参数值存储在本地以供函数重复使用。此方法不仅可以减少对 Parameter Store 的调用次数，此外还可以缩短检索参数值所需的时间。有关此方法的示例演练，请参阅 Using the AWS Parameter and Secrets Lambda extension to cache parameters and secrets
。
提高 吞吐量
对于更大数量的工作负载，您可以启用更高的吞吐量。此设置可增加您的账户和区域支持的最大每秒事务数，但会产生费用。对于以下场景，应考虑提高吞吐量：
-
应用程序临时需要更高的吞吐量。
例如，在周末促销期间，网店可能会更频繁地读取参数。可以在促销开始前启用更高的吞吐量，然后在促销结束后恢复到标准吞吐量。您可以随时从 Parameter Store 设置页面或使用 AWS CLI 启用或禁用更高的吞吐量。
-
生产应用程序经常并发检索参数，并遇到节流问题。
当多个实例、容器、函数或构建作业同时从 Parameter Store 读取参数时，可能会发生并发检索。示例包括：
-
应用程序快速横向扩展。例如，您的应用程序通常在 5 个 Amazon EC2 实例上运行。当流量突然增加时，Amazon EC2 Auto Scaling 会另外启动 50 个实例。如果每个实例在启动时都读取参数，则合计请求数可能会超过默认的请求限制。
-
容器服务同时启动许多任务。例如，Amazon ECS 服务可能会在更新期间启动许多替换任务，并且每个任务可能会在启动时读取 Parameter Store 中的设置。
-
Lambda 函数同时接收许多请求。例如，Lambda 可能会启动许多函数环境来处理增加的流量。每个函数环境在启动时都可能会读取参数。
-
构建或发布进程会在很短的间隔时间内读取许多参数。例如，某个构建作业可能会读取多个应用程序或环境的设置。
-
使用更高吞吐量时的成本注意事项
使用更高的吞吐量选项时将会产生额外的费用。有关当前 Parameter Store API 定价和示例，请参阅 AWS Systems Manager 定价
费用按 Parameter Store API 交互数计算。一次 API 交互是指一个 API 请求与单个参数之间的一次交互。例如，假设单个 GetParameter 请求返回 10 个参数，则在计费时此请求将计为 10 次 Parameter Store API 交互。
假设一个需要在流量增加的较短时间内切换到更高吞吐量的场景，例如您的网店举办周末促销活动，并在促销期间进行了 1,000,000 Parameter Store 次 API 交互。如果此例中使用更高吞吐量的成本为每 10,000 次 API 交互 $0.05，则额外增加的总成本约为 $5。您可以在促销结束时切换回标准吞吐量，并停止产生成本。
将吞吐量和参数层级结合使用
吞吐量独立于参数层级。参数层级用于控制存储限制和功能可用性，而吞吐量设置用于控制请求量。为满足性能和规模需求，您可以同时使用层级和吞吐量。
例如，为支持简单的低负载应用程序，您可以使用具有默认吞吐量的标准参数。为支持大规模、高频的访问模式，您可以将高级参数与更高的吞吐量结合使用。通常，无论使用哪个参数层，当应用程序超过默认 TPS 限制时（例如，在并发读取或写入激增期间），都需要增加吞吐量。
有关最大吞吐量及其他 Parameter Store 配额的更多信息，请参阅 AWS Systems Manager 端点和配额。
更改 Parameter Store 中的吞吐量设置
以下过程介绍了如何使用 Systems Manager 更改 Parameter Store 在当前 AWS 账户和 AWS 区域中每秒能够处理的事务数。您可以随时更改此设置。
