Mindbody 如何使用 Amazon Aurora PostgreSQL 优化读取来改善查询延迟和优化成本

这篇文章由软件工程高级经理桑迪普·科普拉、Mindbody高级软件工程师拉胡尔·古普塔和亚马逊云科技数据库专家、高级解决方案架构师穆克什·阿格拉瓦尔共同撰写。

Mindbody 是健身和保健行业领先的基于云的技术平台，可帮助企业发展和繁荣。通过客户预订、日程安排、综合支付、营销和分析等创新解决方案，Mindbody 简化了运营并增强了客户参与度。健身和保健领域成千上万的企业依靠Mindbody进行多合一管理；数百万消费者通过Mindbody应用程序预订这些企业的体验。通过使用尖端的云技术，Mindbody 提供可扩展性、可靠性和持续创新。

Amazon Aurora PostgreSQL 优化读取是一项性能增强功能，专为亚马逊 Aurora PostgreSQL 兼容版设计。它专注于通过减少延迟和增加查询吞吐量来提高读取操作的效率。要了解有关此功能和用例的更多信息，请参阅适用于 Aurora PostgreSQL 的 Amazon Aurora 优化读取，I/O 密集型应用程序的查询延迟最多可提高 8 倍。

在这篇文章中，我们重点介绍了 Mindbody 因数据增长而面临的扩展和性能挑战。我们还提供了采用 Aurora Optimized Reads 的根本原因分析和建议，概述了为解决这些问题而采取的步骤。最后，我们将讨论 Mindbody 通过实施这些变更所带来的好处，包括增强查询性能、显著节省成本和提高价格可预测性。

“升级到 Aurora 优化读取为我们的运营带来了有意义的进步。尽管在过渡期间需要进行细微的调整，但亚马逊的解决方案和建议促进了平稳和低摩擦的迁移。这种转变显著简化了我们的数据库性能，缩短了查询延迟，使我们能够为客户提供更快、响应更快的服务。效率提高与成本节约相结合，这使我们能够再投资于增强客户体验和增强我们平台的可靠性。”

— Mindbody 首席技术官雅各布·米查姆

当前架构

Mindbody的电子邮件营销平台在Aurora PostgreSQL集群上运行，以支持他们的业务需求。数据库版本为 13.8，大小约为 17 TB，包括具有数十亿行的分区表。为了处理峰值工作负载，Mindbody 使用最大的 Aurora 实例，其工作负载为 80% 的读取和 20% 的写入。

下图说明了当前的架构。

当前架构

扩展和查询性能挑战

由于架构限制和不断增长的数据需求，Mindbody 的营销套件应用程序面临着巨大的扩展和性能挑战。尽管 Aurora 支持使用多达 15 个只读副本进行读取扩展，但其旧版本的应用程序堆栈 (rails) 缺少读写分离，将所有工作负载定向到写入器节点，同时仅使用读取器作为故障转移目标。复杂的动态 SQL 查询，涉及分区表中数十亿行的联接，使查询优化工作进一步复杂化。

集成数据仓库的缺失迫使人们依赖在线事务处理 (OLTP) 数据库，这给 Aurora 编写器实例增加了压力。由于垂直扩展最大值为 db.r6i.32xlarge，应用程序面临查询执行速度较慢、响应时间延长、可扩展性有限的问题。

由于这些挑战，Mindbody 寻求有关如何进一步扩展集群以提高查询性能的指导，无需经过大量的查询优化、应用程序重写或涉及分片的数据库重构过程。

根本原因分析

在查看了亚马逊云手表和亚马逊RDS性能洞察中的性能数据以及Amazon Cost Explorer的成本分析之后，我们发现了几项关键发现。

首先，CloudWatch显示平均水平BufferCacheHitRatio一直低于80％。健康的比率通常在 95% 以上，任何较低的比率都表明查询经常访问磁盘，而不是通过缓存提供服务。

通过查看热门等待事件，可以在性能见解中验证这一点IO:DataFileRead。当连接等待后端进程从存储中读取所需页面时，就会发生此事件，因为该页面在共享内存中不可用。当所需的数据不在内存中时，Aurora 会从存储中提取这些数据，从而增加数据库实例 CPU 和网络利用率的负载，导致更高的查询延迟，并产生 I/O 成本。为了减轻从 Aurora 存储中读取数据页面所涉及的网络 I/O 延迟的影响，Mindbody 配置了更大的实例 db.r6i.32xlarge，其内存与其工作数据集相匹配，以满足其业务服务级别协议。

Mindbody 对为满足内存需求而设计的超额配置实例所产生的成本影响表示担忧。下图重点介绍了CPUutilization指标，显示主写入器实例的平均 CPU 利用率保持在 20% 以下，偶尔会出现峰值。

在 Cost Explorer 中，我们发现 Mindbody Aurora 集群表现出显著的读取 I/O 强度。该集群的每月平均输入/输出成本约占Aurora总支出的48％（我们在文章后面提供了一张成本分析图，对此进行了说明）。

选择 Aurora 优化读取的原因

基于上述根本原因分析，Mindbody 选择采用 Aurora 优化读取有三个关键原因：

它提供了开箱即用的分层缓存功能，通过使用本地 NVMe 存储扩展数据库实例缓存容量。
它提供了开箱即用的临时对象功能。借助此功能，临时对象将托管在 NVMe 存储中。这为排序、加入或合并大量无法容纳在为这些操作配置的内存中的数据的查询提供了更好的延迟和吞吐量。
考虑到 I/O 密集型工作负载，Aurora I/O 优化功能可帮助他们实现更好的性价比。

过渡到 Aurora PostgreSQL 优化读取

启用 Aurora 优化读取需要将数据库集群从 13.8 版本升级到 14.9 或更高版本。Mindbody 团队意识到技术复杂性以及对严格高可用性的需求，在生产集群中实施变更之前，在概念验证环境中进行了全面测试，收集了关键业务查询的关键性能指标。

为了最大限度地减少生产中断，Mindbody 使用了蓝/绿部署，并遵循了推荐的升级路径——首先将集群更新到最新的次要版本，然后继续进行主要版本升级。

要详细了解蓝/绿部署的限制和注意事项，请参阅蓝/绿部署的限制和注意事项。

创建概念验证环境遵循的流程

创建生产规模的概念验证环境有两个目标：

进行全面的测试以证明其好处，并为在生产环境中复制该过程制定详细的运行手册。
为了评估影响，Mindbody 团队确定了一组具有代表性的关键业务查询，并在概念验证环境中运行了这些查询，从而实现了并排的性能比较。

下图说明了创建概念验证环境的工作流程。

最重要的关键业务查询在蓝色（非优化读取）和绿色（优化读取）Aurora 集群上并排运行，以捕获运行时间。下表对运行时进行了比较。

在此阶段，Mindbody 团队已经收集了必要的指标，可以放心地继续采用Aurora Optimized Reads进行生产迁移，并准备了一份详细的运行手册以在生产环境中复制这些步骤。

切换到 Aurora PostgreSQL 优化读取的好处

按照概念验证期间准备的运行手册，Mindbody团队首先将次要版本从13.8升级到13.12（上图中的步骤2），然后使用Aurora蓝/绿色部署将主要版本升级到14.9（步骤3）。切换到绿色环境后，Aurora 集群的存储配置随后被修改为 Aurora I/O 优化配置（步骤 4）。这是一项在线操作，不需要停机。

在此阶段，Aurora 集群实例已准备好进行修改，以替换为与 Optimized Reads 兼容的实例（此操作需要停机）。为了最大限度地减少干扰，该团队首先将读取器实例修改为与优化的 Reads 兼容实例 db.r6id.32xlarge（步骤 5）。在此阶段，Aurora 主写入器实例仍在非优化读取实例上，读取器实例已修改为优化读取实例类型。

6月21日，Mindbody进行了手动故障转移，交换了作者和读者实例的角色。此操作成功将 Aurora 集群的主（写入器）实例过渡到兼容 Optimized Reads 的配置。在意识到好处后，Mindbody将新的阅读器（或旧写入器）实例修改为与优化阅读兼容的db.r6id.32xlarge实例。

在本节中，我们将讨论 Mindbody 团队在过渡到 Aurora PostgreSQL 优化读取后实现的关键性能改进和成本节约。

关键性能改进

以下是写入器实例开始在兼容 Optimized Reads 的 Aurora 实例上运行后收集的关键指标：

Mindbody报告说，他们的顶级模块的运行时间有了显著改善。这种改进减少了获取自动化和活动联系人时的总体失败次数。

在以下屏幕截图中，我们观察到，CloudWatch的平均CPUUtilization指标显示CPU（优化读取）为6％，而CPU（未优化读取）为12％。平均每日CPUUtilization减少了50％。

在以下屏幕截图中，我们观察到，与未优化读取相比，CloudWatch ReadIOPS 指标显示优化读取减少了90％。

在以下屏幕截图中，我们观察到，与没有优化读取（7.79）相比，性能洞察IO:DataFileRead指标显示优化读取（0.81）显著减少。

Aurora 的 AuroraOptimizedReadsCacheHitRatio CloudWatch 指标显示，平均有 85% 的读取请求由 Aurora 优化读取缓存提供服务。

成本收益

Aurora服务的详细成本明细可在成本分析中查看，从而深入了解Mindbody在使用Aurora时实现的切实成本节省和价格可预测性。

Mindbody 于 6 月 21 日过渡到优化阅读。Cost Explorer 图表显示了 6 个月内（向优化读取过渡前 3 个月和过渡后 3 个月）按使用类型划分的 Aurora 每月成本，显示从 6 月开始成本降低了大约 23%。值得注意Aurora:StorageIOUsage的是，这在三月至六月期间很明显。相比之下，从7月起，没有了Aurora:StorageIOUsage，因此，尽管成本大幅增加，但总体成本结构还是更可预测的。InstanceUsageIOOptimized:db.r6id.32xlarge

减少了50％之后CPUUtilization，Mindbody现在有机会将其Aurora实例的大小从db.r6id.32xlarge缩小到db.r6id.24xlarge。这种调整可以节省更多成本，从而在保持优秀性能的同时提高资源利用率。

结论

Mindbody 有效地使用 Aurora Optimized Reads 来克服性能挑战并提高其管理大型数据集的延迟敏感型应用程序的成本效率。这使得 Mindbody 能够更有效地满足其性能服务级别协议，同时降低成本。这篇文章重点介绍了 Aurora PostgreSQL 优化读取如何为需要低延迟的读取密集型应用程序提供显著的性能改进和经济优势。

您可以立即开始使用优化读取功能，方法是访问 Amazon RDS 控制台并启动支持的 Aurora 实例。有关更多信息，请参阅使用 Aurora 优化读取提高 Aurora PostgreSQL 的查询性能。

作者简介

桑迪普·科普拉是Mindbody的高级工程负责人，拥有超过18年的IT经验，包括7年的技术架构工作和8年的技术管理经验。他专门在健身与健康服务、电子邮件营销、金融科技、PropTech、LMS/LXP、电子商务、娱乐行业薪资和信用局等不同领域架构、设计、开发和部署复杂、高容量和可扩展的企业应用程序。

拉胡尔·古普塔是Mindbody的高级软件工程师，在全栈开发和云技术方面拥有超过8年的经验。他为构建可扩展系统、提高应用程序性能和优化工作流程做出了贡献。拉胡尔精通ReactJS、Redux、Ruby on Rails、PostgreSQL和亚马逊云科技，曾支持诸如使Mindbody每年交付超过十亿封电子邮件和短信等举措。