如何 ktown4u 利用 Amazon Aurora 混合配置集群构建定制的自动扩展架构以应对突发流量

关键要点

在本文中，我们将探讨 ktown4u 如何使用 Amazon Aurora 的混合配置集群构建自定义的自动扩展架构，以有效应对突发流量。以下是文章重点内容： ktown4u 面临的流量挑战与传统 Aurora 自动扩展的局限性 通过新增 Serverless 实例和优化云监控指标提升服务性能与可靠性 如何利用 AWS API 简化自动扩展逻辑以及减低运营成本

Ktown4u 是一家全球销售 KPop 及韩流产品的电商公司。自 2002 年成立以来，该公司已经发展到拥有超过 500 万会员和 5000 个粉丝俱乐部，覆盖 200 个国家并提供六种语言服务。在 2021 年，其销售额超过了 2000 亿韩元。随着从 B2B 向 B2C 转型，业务在短时间内增长了 15 倍。

ktown4u 开发并运营相关的用户服务、操作系统及物流管理系统，这些系统都基于云进行部署。为了应对流量高峰，ktown4u 在 2022 年进行了多项系统改进，旨在解决常见故障。到 2023 年，该公司正在努力优化产品结构、升级物流以及用微服务架构取代庞大的单体遗留系统。

在这篇文章中，我们将分享 ktown4u 如何利用 Amazon Aurora 混合配置集群来应对突发流量。

突发流量挑战

在市场推广活动中，如知名 Kpop 艺人新专辑的发布，ktown4u 常常会接到数倍于平时的流量。尽管已积极利用 Amazon ElastiCache 降低延迟并保持服务的可靠性，但多项实时数据库查询的 API 依然对数据库架构造成负担。为了解决突发流量带来的问题，ktown4u 积极利用 Aurora Auto Scaling。

在流量突增时，ktown4u 通过 Aurora Auto Scaling 扩展 Aurora 副本的数量，或主动增加多个只读实例来应对流量激增。然而，ktown4u 仍面临若干挑战：

挑战说明服务中断由于流量负载突增导致的服务 disruptions。发现与整合延迟只读实例的整合过程可能需要 56 分钟。财务方面考量需要提前规划只读实例的配置。流量预测困难难以精确评估即将到来的事件规模，容易造成资源浪费。

为了满足这些商业需求，有效应对不可预测的流量波动，同时简化与 Aurora Auto Scaling 有关的时间和财务投资，ktown4u 需要制定独特的解决方案。

改进思路

如果有额外的 Amazon Aurora 实例能在创建只读实例的 56 分钟内处理流量，就可以解决服务故障问题。为此，可以设置一个仅在只读实例创建期间处理流量的额外实例，并只在接收流量时收费。该配置还将通过减少创建只读实例的数量来实现成本优化。

解决方案概览

ktown4u 的自定义 Aurora 自动扩展架构遵循以下逻辑处理数据库负载：

新增的 Aurora Serverless v2 只读实例在正常时期的权重为零0，因此不会在平时接收流量。当现有 Aurora 集群的只读实例 CPU 平均负载超过阈值时，将触发警报。当警报被触发时，调整流量分配到 Aurora Serverless v2 实例。扩展现有 Aurora 集群并新增预配置的只读实例以应对流量激增。持续监控额外只读实例的状态，并调整流量分配。

最终，ktown4u 成功实现了有效且可靠的数据库使用。

Amazon Aurora 混合配置集群

Amazon Aurora 数据库集群由两种类型的数据库实例组成： 主数据库实例：支持读写操作，对集群卷进行数据更改。 Aurora 副本只读实例：仅连接到主数据库实例的同一存储卷，支持读操作。

根据 Aurora 架构，计算与存储是分开的，这使得根据数据库中的数据量自动调整存储成为可能。这一点在 Aurora Serverless v2 中得到扩展，能够无缝地自动根据使用情况调整计算资源。

实现步骤

添加一个 Aurora Serverless v2 只读实例并配置自定义终端节点。收集高分辨率指标并创建 CloudWatch 自定义指标。使用 AWS Step Functions 调整 Route 53 的权重记录。设置 Aurora 自动扩展与 CloudWatch 自定义指标。

最大的优势在于，无论突发流量的性质如何，ktown4u 的混合配置集群都能高效应对，并迅速调整资源配置。通过以上方法，ktown4u 显著提高了系统可靠性与性能，实现了自动扩展的快速响应。

在未来，通过 Aurora Serverless v2 和该优化架构，ktown4u 将能够更有效地处理流量波动与业务需求的变化，持续推动商业成功。

迅猛兔机场