关键字: [ 亚马逊云科技中国峰会2024, Amazon Aurora MySQL, Architecture Globale Base De Données, Migration Vers Le Cloud, Haute Disponibilité Route 53, Optimisation Coûts Visibilité, Automatisation Gestion Ressources]

本文字数: 2000, 阅读完需: 10 分钟

导读

在本次亚马逊云科技中国峰会2024 上, 王小龙分享了FreeWheel 基于Amazon Aurora 的全球数据库架构演进。他阐述了FreeWheel 将核心数据库迁移到Amazon Aurora 的历程, 以及在云上构建高可用、低延迟、安全且自动化的数据库架构的实践。演讲重点包括: 利用Aurora Global Database 实现跨区域低延迟灾备、通过Route 53 实现高可用方案、提升安全性和自动化水平、优化成本等。FreeWheel 借助亚马逊云科技服务和企业支持团队, 实现了数据库架构现代化, 满足了广告行业对数据库的高可用性、低延迟和安全性要求。

演讲精华

以下是小编为您整理的本次演讲的精华，共1700 字，阅读时间大约是8 分钟。

大家好, 我是来自FreeWheel 的王小龙, 今天带来的分享就是FreeWheel 基于Amazon Aurora 的全球数据库架构演进。在日常工作中, 大多数人都和数据库打过交道。今天的分享内容主要有两个方向, 一个是FreeWheel 核心数据库迁移上云的历程, 另一个是FreeWheel 数据库架构的演进。

首先介绍一下FreeWheel 的公司情况。FreeWheel 是一家广告技术公司, 主要为媒体公司和广告客户提供跨平台的广告管理解决方案。公司业务对数据库的要求主要有两点: 一是稳定性, 比如在重要赛事如世界杯、奥运会期间, 即使出现一分钟的数据库不可用, 也会对广告投放造成重大影响; 二是延迟可控, 即希望在指定时间内应用能读到所期望的数据, 否则也会影响客户的广告投放效果。

下面看一下迁移的过程。数据库迁移会面临很多挑战, 在迁移上云时还会有一个特殊的挑战, 就是对云产品的知识处于学习和知识累积的过程。如果在这个阶段遇到问题, 我们如何能第一时间找到专家帮助解决?FreeWheel 在这方面的实践是与亚马逊云科技的企业支持团队有着非常深入的合作。从2019 年开始, 亚马逊企业支持就为FreeWheel 的整个上云之旅提供全方位支持, 特别是为核心数据库迁移做保驾护航。

这个电影海报是2020 年的一部电影《护航者》, 讲述的是二战期间盟军军舰保护商船穿越大西洋抵抗德军潜艇攻击、为欧洲运送物资的故事。对于FreeWheel 来说, 亚马逊的企业支持就是为核心数据库迁移提供了这样的保驾护航作用。在整个迁移过程中, 亚马逊的企业支持在迁移前、迁移规划、迁移实施以及迁移后做到了全方位保障, 包括解决执行计划问题、死锁问题、数据同步技术问题等。通过亚马逊企业支持的及时解决和反馈, 整个迁移流程更加顺利。最终的迁移效果是, 在亚马逊企业支持的帮助下, 分钟级别就完成了数据库从自有数据中心到亚马逊云的迁移, 节省了对应用的影响, 同时达到了预期的可用性和性能。

接下来是FreeWheel 基于Aurora 的全球数据库架构演进。首先看一下上云前数据库运维面临的挑战。在上云前,FreeWheel 使用的是Percona XtraDB Cluster 架构, 当时有大约60 多个节点。之所以有这么多节点, 一个原因是广告行业应用的特点决定了需要大量从库支撑读流量; 另一个原因是应用流量请求的临时性特点, 可能一周只有几次流量, 但每次打到数据库的压力都很大, 因此需要单独的从库承载。

在这种架构下, 存在以下几个痛点: 首先, 架构复杂, 维护成本高; 其次, 多重库会影响性能, 随着从库增加, 延迟控制也更加困难; 再次, 整体SLA 较低, 受硬件、网络、延迟等因素影响; 扩展性受限于物理硬件; 最后, 灾备设计存在痛点, 灾备中心由于距离和延迟影响只能承载只读流量, 难以在成本和质量之间平衡。

上云后,FreeWheel 采用了Amazon Aurora MySQL 的全球数据库架构, 主要利用了其跨区域低延迟的特性。美东作为主数据中心, 美西作为灾备中心。在主数据中心, 有一个写节点和6 个读节点, 这些读节点通过客户端组进行了分组, 并根据业务类型分配给不同的客户端组, 实现了应用隔离。

除了Aurora 读节点外,FreeWheel 还使用了EC2 实例作为只读节点承载部分只读流量。之所以使用EC2, 一个原因是可以灵活选择实例规格,Aurora MySQL 最大内存为1TB, 但某些应用依赖于InnoDB 缓冲池, 需要更大内存; 另一个原因是长事务对Aurora 的影响较大, 会造成读节点延迟和主库性能波动, 将这部分流量转移到EC2 可以避免这种影响; 第三个原因是EC2 的成本更低。

他们还使用了Route 53, 应用只需配置一个Route 53 地址,Route 53 会将流量指向Aurora 的Endpoint 或EC2 的IP 地址, 实现了应用配置与后端集群的解耦。最后, 他们使用Amazon DynamoDB 作为NoSQL 存储, 承载KV 类型的查询, 利用了DynamoDB 的高扩展性、低延迟和高可用性。

为了实现Aurora 读节点和EC2 只读节点之间的高可用,FreeWheel 设计了一个基于Lambda 、CloudWatch Metrics 和Route 53 健康检查的方案。Lambda 收集指标并推送到CloudWatch, 基于MySQL 的存活状态和延迟指标, 在Route 53 设置不同的阈值, 比如有的应用对延迟敏感, 阈值设置为10 秒, 有的延迟不敏感, 阈值设置为1 分钟。 当延迟超过阈值时, 就会触发Route 53 将流量切换到其他可用节点, 实现自动高可用切换。

上云后,FreeWheel 获得了以下收益:

1. 可用性提升。实例数量从80 多个减少到20 多个, 一方面是应用合并, 另一方面是对于周期性流量采用按需启动实例的方式, 而不是常驻实例。部分流量和数据也迁移到DynamoDB, 降低了MySQL 集群的负载。

2.SLA 提升。受益于Aurora MySQL 自身的高可用性, 可提供4 个9 的可用性; 另外也得益于基于Route 53 的高可用方案, 提升了Aurora 和EC2 之间的高可用性。

3. 实例快速恢复。一个真实案例显示, 单个实例重启的不可用时间仅1 分20 秒左右,2 分钟内可完成重启。这得益于Aurora 的存储和计算分离架构, 无需进行重做、回滚等操作。

4. 延迟降低。同区域延迟在几毫秒到几百毫秒, 跨区域延迟控制在1 秒内, 大大超出预期。之前使用Binlog 做跨区域复制时, 在高峰期延迟甚至达到16 个小时。这得益于Aurora 基于Redo Log 的复制特性, 即使写节点有大流量写入, 对延迟影响也很小。不过需注意大事务对延迟的影响, 建议监控InnoDB 历史列表。

5. 安全性提升。存储层可方便对EBS 存储加密, 并自动轮转加密密钥; 数据库层面可自动轮转SSL 证书, 无需重启数据库; 通过Amazon Secrets Manager 实现去除明文密码; 可通过VPC 和安全组做网络隔离和管控。

6. 自动化水平提高。FreeWheel 开发了资源生命周期管理服务, 可自动管理RDS 、EC2 、DB Secret 等资源; 基于标签实现了CMDB 的自动发现和监控接入。所有这些自动化都基于Amazon Web Services API 调用。去年有400 多个实例由该服务提供按需支持。

7. 灾备设计优化。基于全球数据库架构实现RPO 小于1 秒; 在灾备中心做了降配, 如实例类型和数量降低; 并开发了自动化工具实现实例扩容、客户端组创建、Route 53 切换、故障切换等流程。

8. 成本可视化。通过标签实现了整体成本设计, 可基于账号、服务等维度查看成本报表和历史变化趋势, 并根据On-Demand 和Reserved 实例的对比调整RI 购买比例。

FreeWheel 还分享了一些最佳实践建议:Aurora Serverless 适合测试环境和周期性流量;IO Optimize 功能可降低IO 成本; 使用Amazon CloudWatch 日志时需要管理Retention 策略避免 保留;RTG 机型可提供Optimize Write 功能, 提升RDS MySQL 性能。

总的来说, 通过与亚马逊云科技企业支持团队的深入合作,FreeWheel 成功将核心数据库从60 多个节点的Percona 架构迁移到亚马逊云科技的Aurora 全球数据库架构, 获得了更高的可用性、性能、安全性和自动化水平, 实例数量减少到20 多个,SLA 提升到4 个9, 实例重启时间缩短到1 分20 秒, 同区域延迟控制在几毫秒到几百毫秒, 跨区域延迟控制在1 秒内, 并优化了整体架构和运维实践, 为业务发展提供了有力支撑。在迁移过程中, 他们利用了亚马逊云科技企业支持的全方位服务; 在新架构中, 充分利用了亚马逊云科技的多项产品和服务, 如Aurora 全球数据库、EC2 、Route 53 、DynamoDB 、Lambda 、CloudWatch 等; 在安全、自动化、成本可视化等方面也广泛采用了亚马逊云科技的相关能力, 全面提升了系统的可用性、性能、安全性和运维效率。

下面是一些演讲现场的精彩瞬间：

演讲者询问在场观众是否在日常工作中使用过数据库, 并鼓励大家举手回应。

亚马逊云科技中国峰会2024:Aurora 基于Redo Log 的复制特性实现了低延迟, 跨地区延迟也得到显著提升

亚马逊云科技通过基于标签的自动发现和监控提升了CMDB 功能, 实现了资源自动注册和监控接入, 大大提高了自动化效率。

亚马逊云科技中国峰会2024 上, 演讲者强调了亚马逊云科技在不同地区之间进行扩展或迁移的便利性, 以及提供一致的基础设施和服务体验。

亚马逊云科技中国峰会2024 上, 亚马逊云科技专家解释了Amazon RDS for MySQL 的优势, 包括开箱即用、与社区版本高度兼容、存储和计算分离等, 方便客户快速上手测试和使用。

亚马逊云科技中国峰会2024 上, 演讲者强调亚马逊云科技从一开始就秉持” 开箱即用” 的理念, 旨在以最简单快速的方式帮助客户搭建基础设施, 无需担心底层维护工作。

总结

亚马逊云科技中国峰会2024 上，FreeWheel 分享了基于Amazon Aurora 的全球数据库架构演进经验。他们从自建数据中心迁移到亚马逊云科技云端后, 通过Aurora MySQL 的Global Database 特性, 实现了低延迟、高可用的跨区域数据库架构。同时, 借助亚马逊云科技的企业支持、Route 53 、Lambda 等服务, 构建了自动化运维和高可用方案, 提升了可用性、安全性和自动化水平。此外, 他们还分享了Aurora 带来的成本优化、灾备设计和数据归档等实践经验。

Aurora MySQL 与社区版本高度兼容, 几乎无需代码修改即可迁移。对于中小企业, 亚马逊云科技提供开箱即用的云服务, 可快速上手试用。FreeWheel 的分享为企业上云提供了宝贵的架构演进经验, 展现了亚马逊云科技在数据库领域的创新实践。

Aurora 的低延迟、高可用、自动化运维等优势, 为广告行业提供了高性能、可靠的数据库解决方案。通过与亚马逊云科技深度合作,FreeWheel 实现了核心数据库的顺利云迁移, 并持续优化架构, 满足业务快速发展的需求。

FreeWheel 呼吁企业密切关注云产品的版本选择和支持周期, 提前做好规划。同时, 需要根据业务特点验证云服务的适用性, 快速试错迭代。亚马逊云科技将继续与合作伙伴携手, 为企业数字化转型提供创新的云端解决方案。

2024 年 5 月 29 日，亚马逊云科技中国峰会在上海召开。峰会期间，亚马逊全球副总裁、亚马逊云科技大中华区总裁储瑞松全面阐述了亚马逊云科技如何利用在算力、模型、以及应用层面丰富的产品和服务，成为企业构建和应用生成式 AI 的首选。此外，活动还详细介绍了亚马逊云科技秉承客户至尚的原则，通过与本地合作伙伴一起支持行业客户数字化转型和创新，提供安全、稳定、可信赖的服务，以及持续深耕本地、链接全球，助力客户在中国和全球化发展的道路上取得成功。