使用 Amazon EventBridge Scheduler 按计划扩展 Amazon Aurora Serverless

作者： 乔什·哈特 |

现代应用程序需要能够处理可变工作负载的关系数据库，同时保持性能和成本效益。虽然 Amazon Aurora Serverless 会根据 CPU 和内存使用率等指标自动扩展，但一些应用程序需要在特定时间进行可预测的容量调整。例如，每天上午 9 点报告的工作可能需要事先增加容量，以确保及时完成。

在这篇文章中，我们演示了如何使用 Amazon EventBridge Scheduler 为 Aurora Serverless 实现计划扩展。通过主动调整最低 Aurora 容量单位 (ACU)，您可以在高峰期实现更快的扩展速度，同时在低需求时段保持成本效率。

用例概述

此模式的一些示例用例是：

  1. 每天的特定时间（例如上午 9 点）流量激增的每日使用情况。
  2. 特定日期流量激增的特殊活动（例如电子商务平台的"闪购"）。
  3. 在应用程序中发现了系统故障，预计数据库会有额外的工作负载。
  4. 预计性能会提高的特定应用程序使用模式。

使用模式示例如下图，上午 9 点活动急剧增加：

该图显示了全天数据库的利用率以及使用率的急剧峰值

对于传统的关系数据库，这可以通过预置峰值来解决。通过为峰值进行配置，数据库将在一天中的大部分时间过度配置，从而导致资源浪费。如下图所示，所有阴影区域都是浪费的计算资源。

图表显示了预置容量的利用率，突出显示了峰值配置中未使用的计算资源

Aurora Serverless 通过动态扩展和缩减计算资源来应对不断变化的活动模式来解决这个问题。这些扩展操作会增加或减少可用的 Aurora Serverless 容量单位。在最初的升级期间，可能需要几分钟才能达到满足流量峰值所需的全部计算容量，具体取决于数据库需要扩展的程度。虽然工作负载立即开始接收额外资源，但是在所需容量得到满足之前，这些增量容量的增加可能不足以完全满足不断增长的需求。

虽然会出现这种提升，但可能会出现请求超时，或者服务质量普遍下降。

自动扩展可根据一天中波动的工作负载动态调整容量。另一方面，计划扩展允许您为预期的峰值使用时段主动设置预先确定的最小和最大容量级别。通过提前调整最小容量设置，您可以确保数据库有足够的基准容量来应对预期的工作负载增加。通过组合这些方法，您可以优化数据库性能和成本效益。下图显示了一个示例，其中利用率更接近预置的资源，因此减少了计算浪费：

该图显示使用 Aurora Serverless 的利用率比容量更低

更改 Aurora Serverless 的容量配置是一项无中断操作。你可以随时更改此设置，它不会中断你现有的工作负载或连接。这与传统的数据库部署不同，在传统数据库部署中，更改容量将至少触发到备用或副本实例的故障转移事件。

解决方案概述

该解决方案使用无服务器、事件驱动的架构在特定时间扩展 Aurora Serverless 容量。下图说明了解决方案架构。

图表显示了预置容量的利用率，突出显示了峰值配置中未使用的计算资源

该解决方案由以下关键组件组成：

  • Aurora Serverless — Aurora Serverless 会在配置的最小和最大容量范围内自动调整其容量（Aurora 容量单位 (ACU)），以响应数据库负载的变化。
  • EventBridge Scheduler — 循环计划（例如，cron 表达式）以已知的时间间隔触发事件。例如，EventBridge 计划可能会在世界标准时间每天 08:00 运行，以启动扩大规模活动。另一条规则可能会在当天晚些时候运行，以便在非高峰时段缩减容量。
  • IAM 角色 — EventBridge 计划承担了 Amazon Identity and Access Management (IAM) 角色。IAM 角色的范围是提供对 ModifyDBCluster 的访问权限。该计划使用通用目标直接使用亚马逊关系数据库服务 (Amazon RDS) API 与 Aurora 进行交互。它识别目标 Aurora 集群并调用 ModifyDBCluster API 操作，传递一个有效负载，指定所需的最小和最大容量单位。

在以下部分中，我们将逐步介绍实施此定时扩展解决方案的步骤。

先决条件

您应该具备以下先决条件：

  • 具有至少一个 Amazon Serverless 实例的 Aurora 集群 — 该解决方案需要现有的 Aurora Serverless（兼容 MySQL 或 PostgreSQL）实例。您必须知道集群标识符、所需的最小和最大容量单位，并具有修改集群的权限。
  • 亚马逊云科技 CDK — 该示例使用亚马逊云科技云开发套件 (亚马逊云科技 CDK) 进行部署。这篇文章引用了以下 GitHub 存储库中的代码和配置。

第 1 步：克隆存储库

首先克隆存储库并切换到示例目录：

git clone git@github.com:aws-samples/data-for-saas-patterns.git
cd samples/scheduled-aurora-serverless-scaling

这个亚马逊云科技 CDK 应用程序定义了基础设施组件，包括 EventBridge 计划和必要的 IAM 权限。

该 cdk.context.json 文件包含计划配置。可以使用 cron 表达式使用向上扩展计划和/或向下扩展计划进行配置。此外，dbClusterIDS 还指定要将哪些集群作为目标（这对应于集群中的 dbClusterIdentifier 参数）。

第 2 步：定义扩展计划

了解数据库的上限非常重要。如果将最大容量设置为过低的值，则可能会中断服务。例如，如果您的数据库当前使用 128 ACU，而您的计划扩展操作将最大 ACU 降至 64，则此操作将优先。这意味着，如果您不适当地安排扩展操作的时间，工作负载可能会受到负面影响。

要确定这一点，您可以在一段时间内运行数据库，而无需执行预定的扩展操作。活动几天后，查看亚马逊云科技 CloudWatch 的无服务器数据库容量指标。该指标将允许您确定在哪里可以按计划进行扩展操作，以避免服务中断。

在 cdk.context.json 文件中，定义一个 cron 表达式以指示何时应进行缩放。例如，要在每天 08:00 UTC 向上扩展并在每天 18:00 UTC 向下扩展，请使用以下代码（注意所需的容量单位是 ACU）：

{
    "scheduleUp": "cron(0 8 * * ? *)",
    "desiredCapacityUpMin": "8",
    "desiredCapacityUpMax": "128",
    "scheduleDown": "cron(0 18 * * ? *)",
    "desiredCapacityDownMin": "0.5",
    "desiredCapacityDownMax": "8",
    "dbClusterIds": ["scalingtarget"]
}

如果您只想安排向上扩展操作并让 Aurora Serverless 自行管理向下扩展，则可以省略缩小规模计划（反之亦然）：

{
    "scheduleUp": "cron(0 8 * * ? *)",
    "desiredCapacityUpMin": "8",
    "desiredCapacityUpMax": "128",
    "dbClusterIds": ["scalingtarget"]
}

如果您想针对多个集群运行解决方案，则可以提供其他集群 ID：

{
    "scheduleUp": "cron(0 8 * * ? *)",
    "desiredCapacityUpMin": "8",
    "desiredCapacityUpMax": "128",
    "dbClusterIds": ["scalingtarget", "scalingtarget2", "scalingtarget3"]
}

第 3 步：部署解决方案

使用亚马逊云科技 CDK CLI 来构建和部署解决方案：

npm i
cdk deploy

亚马逊云科技 CDK 应用程序创建以下内容：

  • 在指定时间触发 Amazon RDS API 的 EventBridge 计划
  • 允许 EventBridge 调用 Amazon RDS API 的 IAM 角色和策略

第 4 步：测试预定扩展

部署后，您可以按如下方式验证更新后的 Aurora 容量：

aws rds describe-db-clusters --db-cluster-identifier myClusterId --query 'DBClusters[].ServerlessV2ScalingConfiguration' --output table

在输出中查找最小和最大容量以确认扩展操作成功：

--------------------------------
|      DescribeDBClusters      |
+--------------+---------------+
|  MaxCapacity |  MinCapacity  |
+--------------+---------------+
|  128.0       |  8.0          |
+--------------+---------------+

或者，您可以使用 Amazon RDS 控制台查看集群的状态和容量变化。

操作注意事项

您可以遵循一些运营注意事项，以管理 Aurora Serverless v2 计划扩展解决方案的成本、性能、可观察性和安全性。

  • 成本管理 — 定期扩展可能会在特定时间内增加 Aurora 的容量，如果将容量长期保持在更高的水平，则可能会增加成本。折衷方案是在已知峰值期间提高性能。持续审查工作负载、扩展窗口和扩展级别，以确保性价比保持优秀状态。
  • 可观察性和日志记录 — 实施强大的日志记录并根据计划中的错误指标创建 CloudWatch 警报。如果扩展事件失败，应立即通知运营商。此外，随着时间的推移，日志可以帮助完善扩展决策。例如，如果在大型任务证明不足之前的 10 分钟扩大规模，则相应地调整时间或容量。
  • 安全和监管 — 确保向 EventBridge 授予权限的角色和策略遵循最低权限原则。EventBridge 执行角色应仅允许访问指定的 Aurora 集群。使用此解决方案时，建议将 Aurora 集群的主用户存储在 Amazon Secrets Manager 中。由于修改数据库集群 API 调用允许更改主密码，因此为了避免滥用，应将其存储在外部的 Secrets Manager 中，并在执行 IAM 策略中隐式拒绝。

清理

要删除解决方案并在完成后移除所有资源，请使用 CDK destroy 命令：

cdk destroy

结论

平衡成本和性能是大规模设计和操作数据库的关键挑战。Aurora Serverless 通过根据负载调整容量提供了理想的起点。但是，可预测的需求模式通常需要更主动的扩展，以在特定时间保持优秀性能。通过集成 EventBridge，您可以为 Aurora Serverless 实现计划扩展，更好地为数据库做好准备，以应对已知的工作负载峰值，并推动更一致的最终用户体验。

在这篇文章中，我们向您展示了如何为 Aurora Serverless 的计划扩展构建可靠且可扩展的机制。通过使用基础设施即代码和无服务器亚马逊云科技服务，您可以调整和扩展解决方案以满足您的运营需求。如需更多数据库示例和模式，请查看 GitHub 上的以下 SaaS 模式数据存储库。

作者简介

乔什·哈特乔什·哈特是亚马逊云科技的首席解决方案架构师。他与英国的 ISV 客户合作，帮助他们在亚马逊云科技上构建 SaaS 应用程序并对其进行现代化改造。

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您发展海外业务和/或了解行业前沿技术选择推荐该服务。