作者 | Rafal Gancarz
译者 | 刘雅梦
策划 | 丁晓昀
AWS 工程师发表了一篇论文，描述了 Amazon Aurora Serverless（无服务器）平台的资源管理和扩缩容的演变以及最新的设计。Aurora Serverless 使用不同级别的组件组合来创建一种全面的方法，用于动态扩展和资源调整，以满足客户工作负载的需求。
Amazon Aurora Serverless 自动扩缩 Amazon Aurora 数据库，以响应不断变化的客户工作负载，并提供成本优化、性能改进和简化的操作。Aurora 客户使用 Aurora 容量单位（Aurora Capacity Units，ACU）配置扩缩边界，服务根据需求动态调整资源。从客户的角度来看，这些扩缩操作不需要任何干预，也不会中断客户端连接或会话状态，但它们可能会影响延迟时间。
当前的 Aurora Serverless 产品是基于 2018 年推出的 ASv1 运维和支持经验而设计的的第二代产品。新设计侧重于就地扩缩（in-place Scaling），使用 CPU 和内存热插拔，支持跨主机的实时迁移。与 ASv1 相比，ASv2 提供了更快、更无缝的扩缩，扩缩增量更小，更具成本效益。
致力于第二代解决方案的团队必须应对许多挑战，其中最主要的挑战是对数据库工作负载进行有效的内存管理，以支持扩展和缩减事件。Linux 和数据库引擎倾向于提交所有可用的内存并保留它们。工程师更改了数据库引擎、Linux 内核和 AWS Nitro 虚拟化管理程序（hypervisor），以便为不同的工作负载提供更灵活的内存管理。
实例管理器服务（来源：Aurora Serverless 中的资源管理）Amazon Aurora 利用每个实例的管理器服务，根据物理主机上所有实例的需求趋势来控制数据库引擎的资源扩缩。优化数据库引擎在主机之间的放置和可用的资源余量，使 Aurora Serverless 能够确保主机上有足够的资源来适应动态工作负载，而无需在主机之间迁移这些资源。
Aurora Serverless 服务在最广泛的级别上管理着包含数万个计算实例的大型机群。机群管理器（Fleet Manager）服务侧重于根据所需的利用率水平并预测需求进行中长期机群的规模和容量进行调整。当主机面临“热”的风险时，使用主机之间的实时迁移来释放资源。此外，机群管理器可以在“热修复”期间对实例的最大 ACU 施加临时限制。
机群管理器服务（来源：Aurora Serverless 中的资源管理）工程师们分享了美国 AWS 地区 Aurora 机群的一些数据，指出绝大多数（99.98%）的扩缩事件不需要主机间的迁移，可以通过就地扩缩机制来满足。
论文最后总结了一些关键要点，强调了设计的简单性和一种响应式、指标驱动的资源管理方法。该团队不排除未来在解决方案中引入更多预测元素的可能性，并强调了虚拟化管理程序和操作系统内核共同演进以更好地支持数据库工作负载的进一步机会。
作者介绍
Rafal Gancarz 是一位经验丰富的技术领导者和专家。他目前正在帮助星巴克打造具有可扩展性、弹性和成本效益的商务平台。此前，Rafal 曾为思科、埃森哲、凯德、ICE、Callsign 等公司设计和构建大规模、分布式和基于云的系统。他的兴趣涵盖了架构与设计、持续交付、可观测性和可操作性，以及软件交付的社会技术和组织方面。
