热云数据启用 Aurora I/O 优化特性实现降本 40%

1. 概述

本文介绍了热云数据如何通过 Amazon Aurora MySQL 3.0 I/O-Optimized 新特性实现 40% 数据库成本优化，以及升级前中后的相关经验与注意事项，期望能对拥有类似 I/O 密集型场景的客户有所帮助。

2. 热云数据及 AdsDesk 业务介绍

热云数据（北京热云科技有限公司）隶属于广州汇量网络科技股份有限公司，是一家第三方移动数据监测和营销科技平台，旗下产品覆盖智能营销技术平台、移动广告效果监测、用户行为分析、广告素材洞察等，为行业客户提供流畅、安全、高效、便捷的数据分析及决策服务，助力企业加速数字化转型，赋能数据创造出更高的价值。

AdsDesk 是热云数据旗下国内一站式智能投放平台，深入对接巨量、腾讯、快手、百度等国内主流媒体 Marketing API，助力各行业投放团队实现智能投放管理、投放效率提高、投放效果提升，提供全面、智能、高效的一站式广告投放管理服务。服务客户涵盖游戏、小说、网服、教育、金融、电商等行业，合作广告主、代理商超过千家。

3. Aurora 使用场景

Amazon Aurora 是专为云构建的一种兼容 MySQL 和 PostgreSQL 的关系数据库，它具有传统企业数据库的性能和可用性，和开源数据库的精简性和成本效益。Aurora 支持全局数据库（Amazon Aurora Global Database），全局数据库跨越多个亚马逊云科技区域，可实现低延迟的全局读取，并可从可能影响整个亚马逊云科技区域的罕见停机事件中快速恢复，为您的全球化业务提供低访问延迟的数据库服务支持。自 2014 年发布以来，Aurora 已经成为亚马逊云科技客户运行业务应用的主要数据库选择。

Aurora 采用一种有容错能力并且可以自我修复的分布式存储系统，与计算资源分离并可以把每个数据库实例自动扩展到最高 128 TiB，存储数据的集群卷自动跨三个可用区进行复制，为您的业务提供高可用性。

Aurora 分布式存储架构参见下图：

热云数据 AdsDesk 使用 Amazon Aurora for MySQL 存放广告投放服务后端的事实表和维度表。后端服务会实时从各投放目标平台获取投放计划相关状态更新，写入到 Aurora 数据库。同步服务会解析 Binlog 将更新的数据同步到 Redis 缓存及 Kafka 集群，通过 Amazon EMR 托管的 Flink/Spark 对数据进行 ETL 处理，之后会将数据保存到 Amazon S3 数据湖和 Redshift 数据仓库中，以提供后续进行离线和在线数据分析/BI 报表服务等。因其业务特性，Aurora 承担的操作请求以写入为主，占总体请求约 80%。作为写入为主的 I/O 密集型应用，I/O 操作的费用占 Aurora 数据库总体成本的比重持续居高，甚至超过 50%。

因此，优化 I/O 操作费用成本成为客户关注的重要方向。

AdsDesk 使用 Aurora 数据库的业务架构参考下图（简化版本，仅供示意）：

亚马逊云科技团队与热云数据一起 Review 数据库架构、配置、数据特征等，针对性给出了一些优化建议，例如：

移除重复或未使用的索引；
对大表使用表分区，清理老旧分区；
对历史数据和表及时进行归档和清理；
业务层面增加限制逻辑，避免对大表频繁扫描；等等

热云数据采取了相应措施来尝试降低 I/O 成本，因为持续密集的数据写入是业务常规需求，这些措施对于 I/O 成本的整体优化尚不能达到理想的效果。因此亚马逊云科技团队向热云数据介绍了 Amazon Aurora IO-Optimized 新功能，其适用于高 I/O 负载的计费模式得到了客户的认可。

4. Aurora I/O-Optimized 功能介绍

在 Aurora 的 Standard 定价模式下，客户需要为 I/O 读写操作支付费用。在某些 I/O 密集型的应用程序中，I/O 操作的费用支出可能会在数据库总体成本中占较高比重，成为客户成本优化工作中重点关注的方面。

2023 年 5 月（中国区上线时间为 2023 年 7 月），亚马逊云科技宣布推出 Amazon Aurora IO-Optimized。使用 Aurora I/O-Optimized，读取和写入 I/O 操作的费用为零，只需为使用的数据库实例和存储付费，因此可以节省 I/O 费用以及预测数据库支出。

您现在可以预测 I/O 密集型工作负载的成本，当您的 I/O 支出超过当前 Aurora 数据库支出的 25% 时，可节省高达 40% 的成本。如果您正在使用保留实例（Reserved Instances），您将看到更大的成本节约。您可以灵活地在称为 Aurora Standard 的现有配置（这是现有的按请求付费定价模式，对于低到中度 I/O 使用率的应用程序具有成本效益）或适用于 I/O 密集型应用程序的 Aurora I/O-Optimized 新配置之间进行选择。

开始使用 Aurora I/O-Optimized

您可以使用 Aurora I/O-Optimized 配置创建新数据库集群，或修改现有数据库集群，通过亚马逊云科技管理控制台、CLI 命令行工具或 SDKs。

对于 Aurora MySQL 兼容版本和 Aurora PostgreSQL 兼容版本，可以选择 Aurora Standard 或 Aurora I/O-Optimized 配置。

在现有的 Aurora 集群中，您每 30 天可以将存储配置切换为 Aurora I/O-Optimized 一次，或者可在任意时间切换回 Aurora Standard。您只能在集群级别修改集群存储配置，更改会应用到集群中所有实例。更改配置后，您无需重新启动集群中的数据库实例。

现已推出

Aurora I/O-Optimized 在所有亚马逊云科技区域中可用于以下 Amazon Aurora 版本：

Aurora MySQL 版本 3.03.1 及更高版本
Aurora PostgreSQL 版本 15.2 及更高版本、14.7 及更高版本和 13.10 及更高版本

此配置支持基于英特尔的 Aurora 数据库实例类型，如 t3、r5 和 r6i，基于 Graviton 的数据库实例类型，如 t4g、r6g、r7g 和 x2g，Aurora Serverless v2，Aurora 全局数据库，按需 Aurora 数据库实例和保留实例。Amazon Aurora 的 r7g 实例由最新一代亚马逊云科技 Graviton3 处理器提供支持，与 r6g 实例相比，为 Aurora 提供了高达 30% 的性能提升和 20% 的性价比提升。

查看定价示例，访问 Aurora 定价页面。了解更多，请阅读亚马逊云科技文档中的 Amazon Aurora 存储和可靠性章节。

5. Aurora 2.11.2 到 3.03.1 升级——方案选择、验证与实施

热云数据升级前使用 Aurora 2.11.2 版本，计划升级到 3.03.1 版本，既涉及 Aurora 大版本的升级，也涉及到 MySQL5.7 到 8.0 的升级。涉及较大的变化，须进行充分的验证和测试。在推进版本升级的过程中，主要包含以下几部分工作：

收集业务痛点，介绍新功能与收益，确认升级意向
升级计划的沟通与确认
升级方案的选择与测试
业务兼容性与性能测试、问题处理
升级实施与技术支持
升级后观察

本文会介绍其中需重点关注的几个方面。

升级方案

常用的升级方案有原地升级/快照恢复/蓝绿部署（自动、手动）几种方式，因热云的 Aurora 数据库数据量级较大，使用快照恢复或原地升级会面临业务无法接受的较长停机时间。因此热云选择了 RDS 自带的自动蓝绿部署功能，以达到简化升级流程、缩短停机时间的目的。

自动蓝绿部署会创建一个复制生产环境的暂存环境。蓝色环境是当前的生产环境。绿色环境是暂存环境。暂存环境使用逻辑复制与当前生产环境保持同步。准备就绪后，您可以切换环境，以将绿色环境提升为新的生产环境。蓝绿部署切换后数据库集群的访问端点不会发生变化，切换通常需要不到一分钟，不会丢失数据，也无需更改应用程序。蓝绿部署降低了数据库更新（例如主要或次要引擎版本升级）的风险和减少了停机时间。

蓝绿部署的架构示意图如下：

使用自动蓝绿部署的注意事项

使用自动蓝绿部署进行升级需要充分测试，过程中如遇到报错，建议将报错信息通过开通 Case 等方式反馈至亚马逊云科技 Support 支持工程师，后台处理或给出解决方案后继续完成蓝绿部署流程。热云在测试过程中遇到旧版本升级后遗留存储过程导致蓝绿部署过程中控制台报错的情况，通过亚马逊云科技 Support 工程师协助处理后得到解决；
自动蓝绿部署需要开启 Binlog；
切换前建议停止业务访问数据库，以避免长事务可能导致的长时间等待或失败；
对于 Aurora，蓝绿切换前绿色环境是可写的，要防止人为发生双写；
一个蓝色环境只能创建一个绿色环境；
切换后的蓝色环境是 read_only 的，如果要配置反向复制，需要关闭 read_only；
删除蓝绿环境时，如果不勾选删除绿色环境，绿色环境会自动变成蓝色环境的读副本。对于 Aurora，删除绿色环境时需要先 promote 成单独的集群，再进行删除；

业务兼容性和性能测试

关于业务兼容性和性能测试有如下建议：

从 Aurora 2 到 Aurora 3 大版本升级，也涉及 MySQL 5.7 到 8.0 的升级，变化点较多，需要充分进行业务的兼容性测试，对于发现的问题及早进行介入和解决；
同理，数据库的大版本升级，针对不同工作负载的性能影响可能有不同表现，建议在测试过程中做充分的性能测试，保障升级后的性能在业务可接受范围内；
可以借助 pre-check 工具进行预检查，辅助找出潜在的风险点；
确保 clients/drivers 兼容新版本；

MySQL 8.0 主要变化点

8.0 的默认字符集变动：MySQL 8.0 的默认字符集 utf8mb4，要避免新旧对象字符集不一致的情况。5.6/5.7 的默认字符集是 latin1，默认校验规则是 latin1_swedish_ci；
8.0 的 Lower_case_table_names 数据库启动后不能后续进行更改：MySQL 8.0 启动使用的 lower_case_table_names 值必须跟初始化时使用的一致。使用不同的设置重新启动服务器会引入与标识符的排序和比较方式不一致的问题。如果源库的 lower_case_table_names 值为 0，无需担心，因为 5.7 和 8.0 默认值为 0；
8.0 移除了一些 SQL_MODE 的支持。Aurora 3（8.0）与 Aurora 1 （5.6）和 Aurora 2（5.7）相比，去掉了一些 SQL_MODE 的支持。包括 NO_AUTO_CREATE_USER，NO_FIELD_OPTIONS，NO_KEY_OPTIONS和NO_TABLE_OPTIONS；
更多可参考博客文章《保驾护航 – Amazon RDS for MySQL 5.7 到 8.0 升级前置检查》或 MySQL 官方文档；

Aurora 3 主要变化点

在 Aurora MySQL 版本 3 中，要配置 innodb_flush_log_at_trx_commit 参数为非 1 值，需要先将 innodb_trx_commit_allow_data_loss 设置为 1，需关注这会面临数据丢失风险；
移除 query cache 功能；
支持 Aurora Serverless V2；
移除了一些旧实例类型支持；
更多可参考《比较 Aurora MySQL 版本 2 和 Aurora MySQL 版本 3》

升级前中后注意事项

升级前

确认和验证升级方案；
完成业务功能和性能测试；
升级前执行手工快照，备份 slow_log 等内容避免升级后被清空；
创建目标版本的自定义参数组，参考源集群配置；
与业务方确认适合的维护停机窗口，预留异常处理时间；

升级中

停止数据写入和查询任务，避免大量连接或长事务导致的切换超时或失败；
新绿色集群选择提前创建的自定义参数组，避免使用默认参数组增加后续重启操作；
如果业务重要性高或升级规模较大，可以提前联系亚马逊云科技支持工程师申请资源支持升级操作，保障顺利切换；
如果遇到切换等待时间过长，可以查询 CloudWatch 中的 AuroraBinlogReplicaLag、DatabaseConnections、ActiveTransactions 指标，定位和排除影响因素；

升级后

持续监测业务使用情况，保障业务功能和性能符合预期；
utf8mb4 相对 utf8mb3 会有更好的性能表现，建议优先使用；
Aurora 3 支持的 Enhanced binary log 可以在 Binlog 开启的情况下降低计算资源消耗，有助于优化性能；
升级完成后验证备份/恢复，DR 功能正常；

6. 升级 I/O-Optimized 的收益与注意事项

如前文介绍，在 Aurora I/O-Optimized 模式下，读取和写入 I/O 操作的费用为零，计算费用上浮 30%，存储费用上浮 125%，其他计费项目保持不变。计费方式变化见下图：

按此规则，我们通过一组示例数据（非真实数据，仅用作计算成本对比）来观察切换 Aurora I/O-Optimized 模式后带来的成本变化。假设某集群在 Standard 模式的成本构成为：计算 ¥20k，存储 ¥1k，I/O ¥21k，其他组成 ¥0.2k，切换 I/O-Optimized 后，虽然计算和存储费用略有上涨，但因为 I/O 费用变为零，整体成本下降超过 30%。同理在 I/O 费用占比更高的业务场景，会带来更高比例的成本节约。对比示例见下图：

热云数据的 Aurora 计费中 I/O 费用占比高，升级到 I/O Optimized 模式带来的成本效益更好，成本节约达到了40%。

关于 RDS 保留实例（RI）的重要提示

Amazon Aurora 使用 RDS 保留实例（RI）降低计算成本。

升级 Aurora I/O-Optimized 需要注意的一个关键点是，由于 I/O-Optimized 的计算成本更高，保留实例的成本也更高——实际上浮 30%。您需要购买更多的 RI 来支付增加的 Aurora 计算成本。如下是简单示例：

如果您拥有 RDS RI 覆盖的 10 个 db.r6g.large 实例，并且切换到 Aurora I/O-Optimized，那么您需要 10 x 1.3 = 13 RI 来实现相同的覆盖范围（即使您的实例数量没有变化）。更多信息请参考 Aurora 定价页面。

Aurora I/O-Optimized 的其他注意事项：

Aurora I/O-Optimized 只能在集群层面配置；
从 Stardard 模式切换为 I/O-Optimized 每月只能操作一次，切回则没有限制；
需要 Aurora MySQL 版本为 3.03.1 以上；
兼容特定数据库实例机型和 Aurora Serverless V2；
Aurora 全局数据库的主集群和副本集群可以在 Standard 和 I/O-Optimized 之间选择不同的存储配置；
使用更新的机型如 r7g 会带来更好的性能表现；
建议客户进行充分测试和评估以确定性能表现是否符合预期；

7. 总结与展望

热云数据与亚马逊云科技团队配合经过充分的业务兼容性验证与升级测试，Aurora I/O-Optimized 在亚马逊云科技中国区上线的第一时间，即顺利完成了 Amazon Aurora 的大版本升级和 I/O-Optimized 功能的升级。保障了业务的平稳运行，同时利用新发布的产品功能获得了 40% 的成本节约。

除了成本效益，升级到 Amazon Aurora 3 版本之后，客户还可以享受到一些新增的特性：

Aurora Serverless V2（Aurora MySQL版本 3.02.0 及更高版本，视区域而定）

容量会根据应用程序需求自动调整，对于多租户数据库、分布式数据库、开发和测试系统以及其他具有高度可变且不可预测工作负载的环境尤为重要，可以获得更优的成本效益和资源弹性。参考文档：

https://aws.amazon.com/cn/blogs/china/amazon-rds-for-mysql-5-7-to-8-0-upgrade-advantages/

https://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html

与 Amazon Redshift 的 zero-ETL 集成（Aurora MySQL 版本 3.05.0 以上）

数据在被写入 Aurora 后的几秒钟内，即可用在 Amazon Redshift 中，因此您不必构建和维护复杂的数据管道来执行提取、转换和加载（ETL）操作。将 OLTP 和 OLAP 数据和系统更好的整合在一起。参考文档：

https://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/zero-etl.html

架构示意：

其他新特性

Binary log 多线程复制（MTR）、复制过滤、事务压缩；公用表表达式（CTE）；窗口函数；扩展的并行查询支持（分区表、聚合和 BLOBS）；降序和不可见索引类型；基于角色的访问控制等。

后续热云数据将探索在更多的业务场景应用 Amazon Aurora 数据库产品，利用云原生产品能力，与亚马逊云科技团队一起持续优化服务与架构，助力业务成功。

亚马逊AWS官方博客