关键字: [ 亚马逊云科技中国峰会2024, Aurora for MySQL, 游戏平台服架构, 多区域容灾实践, 亚马逊云服务, 数据同步策略, 故障切换演练]

本文字数: 2500, 阅读完需: 12 分钟

导读

在本次亚马逊云科技中国峰会2024 上, 演讲者介绍了37Games 游戏平台服的多区域多活容灾实践。他们阐述了游戏平台服的概念及架构演进, 以及如何在亚马逊云科技上实现多区域容灾架构; 具体解释了利用亚马逊云科技服务如CloudFront 、Route 53 、Aurora for MySQL 和DynamoDB 的全球数据库/ 表功能, 实现跨区域数据同步和故障切换。该架构使37Games 能够在15 分钟内完成区域级别的故障切换, 确保业务连续性, 提高了系统的可靠性和灵活性。

演讲精华

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

大家好, 非常感谢大家来参加这个session 。我会和37Games 的运维工程师张辉一起分享关于37Games 游戏平台服在亚马逊云科技上是如何实现多区域容灾的。我主要会讲前面两个内容, 首先介绍一下游戏平台服的概念、架构及其演进, 以及在亚马逊云科技上它是如何实现多区域容灾架构。然后张辉会分享他们如何将这一架构应用到实际生产环境中, 以及该架构为他们的业务带来了哪些价值。

游戏平台服务与游戏服务的最大区别在于, 它不直接提供游戏内容, 而是负责游戏周边业务, 更像一个互联网Web 、HTTP 业务, 负责玩家注册、登录、充值等。一个平台服务可以接入多个游戏, 就像玩家使用同一个账号可以登录多款网易游戏一样, 这些游戏接入的就是同一个平台服务。

全球包括中国和海外很多游戏开发者及公司都使用亚马逊云科技服务, 其中绝大多数公司会将游戏平台服务部署在亚马逊云科技上。原因是游戏平台服务提供注册登录、充值等关键功能, 一旦这些功能不可用将影响玩家进入游戏、影响收入和游戏声誉。同时, 如果平台服务数据丢失, 玩家的账号、充值记录、游戏数据都可能丢失。因此, 那么多游戏公司选择将平台服务部署在亚马逊云科技上, 根本原因是亚马逊云科技提供了最稳定的选择。

即便已选择亚马逊云科技这么稳定的云服务商, 我们仍需讨论跨区域容灾, 这涉及亚马逊云科技的” 弹性”(Resilience) 概念, 是Well-Architected 框架中非常重要的一个支柱。弹性从架构和软件设计层面提高系统稳定性, 我们在之前的会议中已介绍过相关概念、实践和方法论。今天我将与张辉一起分享在实际业务中我们是如何实现弹性的。

在介绍弹性之前, 我先简单说明一下游戏平台服务的架构。它与大多数互联网业务架构相似, 包括接入层、应用层和数据层三层。接入层接收玩家流量, 并根据策略将流量分发到不同业务模块; 应用层负责实际业务逻辑, 如注册、登录、充值等; 数据层使用关系型数据库、非关系型数据库、内存数据库和对象存储等服务存储和缓存数据。

在实现容灾时, 我们有多种选择, 包括主备模式的备份和恢复、热备、温备等, 但我们选择了多活架构。事实上, 多活架构可以实时验证多区域业务架构的可行性, 并在切换时保证服务可用, 因为我们时刻都有真实业务流量在运行。

我们的多活架构与之前的三层架构类似, 也是一个三层架构。在接入层, 我们使用了CloudFront 和Route 53 的结合, 根据策略将不同业务流量分发到不同区域。在应用层, 只需保证不同区域部署的业务模块代码完全一致即可。最复杂的是数据层, 你需要保证不同区域的数据同步、一致性, 以及发生故障后的数据恢复。在这里, 我们使用了多种亚马逊云科技的托管服务, 包括Aurora 和DynamoDB, 它们都有多区域容灾功能, 后面我会详细介绍。

我们先看接入层的多区域容灾。主要有故障转移(Failover) 和多活(Multi-Active) 两种选择。故障转移就是在CloudFront 上配置主备Origin, 当主区域发生故障时,CloudFront 会检测到并自动将流量切换到备区域, 这是一个故障转移过程, 但备区域并非实时有流量经过。

因此我们采用了多活架构, 在CloudFront 后面又加了一个Route 53 。与之前不同的是,CloudFront 的Origin 配置不是真实的业务负载均衡器, 而是一个域名。我们再在Route 53 上, 将这个中间域名根据策略如来源IP 地址或权重, 分发到不同区域的负载均衡器上。这就是我们接入层的多活策略。

应用层相对简单, 只需在CI/CD 流程中保证两个区域的代码部署一致即可, 我们直接看最复杂的数据层。

在数据层, 我们会存储交易数据、会话数据等, 交易数据通常使用关系型数据库。我们使用的是Aurora for MySQL, 这是亚马逊云科技久负盛名的关系型数据库, 采用存算分离架构, 可以很好地扩展计算节点而不增加存储成本。

Aurora for MySQL 有一个全球数据库功能, 可以在全球不同区域备份相同的数据。比如在美东设为主区域, 美西或新加坡为备区域, 它可以有一个主区域和多个备区域。主区域数据落盘后, 会通过存储复制而不是日志重放的方式将数据同步到备区域, 以达到更快的同步效果。

除了主区域同步到备区域, 备区域也可以将写操作直接写入本地端点, 然后通过Aurora 的写转发功能转发到主区域落盘。我在这里列出了一些关于全球数据库和写转发的参数, 大家在实际使用时可以关注这些参数。

除了关系型数据库, 我们还会使用非关系型数据库存储如会话数据等非交易数据, 这里我们使用DynamoDB 。DynamoDB 最初应用于亚马逊电商业务, 后来发布成云服务, 是一个完全托管的无服务器数据库服务, 你只需对表进行读写操作。

DynamoDB 有一个全局表功能, 支持在全球任何区域读写同一张表。如果不同区域同时读写,DynamoDB 采用” 后写入为准” 的方式解决数据冲突。因此, 如果要避免数据冲突, 开发者可以为不同区域数据加不同的前缀。

前面我们讲了多区域容灾的架构策略、使用的服务及其特性, 但这一整套架构是否真的可行? 所有从事过开发和运维的人都知道, 如果没有在实际生产环境中实践过, 它就不是一个真正可用的容灾策略。接下来我把时间交给张辉, 他将介绍37Games 是如何将这套架构应用到生产环境的。

好的, 我是来自37Games 的张辉。王瑞老师已经讲了技术实现原理, 我主要负责讲一下我们是如何在37Games 落地的。无论是37Games 网游、手游还是亚马逊云科技业务线, 我们对故障快速恢复的要求都是一致的, 任何故障都必须在15 分钟内恢复。要在这么短的时间内从故障发现到解决, 除了全面监控和自动化恢复措施外, 最重要的一个手段就是使用多区域双活架构。

这是我们实际的简化架构图。为了验证双活架构的可用性, 也就是当故障发生时, 备节点可以接手业务, 我们会在正常业务中通过Route 53 将部分流量如加拿大、墨西哥地区或按权重1% 的流量引导到备节点。其余99% 流量则进入主节点。

正常情况下, 主节点新加坡的用户写入会直接在那里落盘, 然后通过复制同步到美国备节点。备节点美国的用户写入, 会通过Aurora 的写转发功能先写到新加坡主节点落盘, 再同步回美国。这里会有200 到800 毫秒的延迟, 因此我们只放了1% 的流量在备节点验证其可用性。

由于通过Route 53 分发, 用户请求同一域名时可能会在主备节点之间漂移, 会出现用户状态不一致的情况。因此我们使用了DynamoDB 的全局表功能, 当用户在任一节点登录时, 会将会话数据写入全局表, 及时同步到对方节点, 从而避免漂移导致的状态不一致。

这就是我们的简单架构介绍。除了日常1% 流量验证外, 我们还制定了策略, 每个季度都会做一次100% 流量切换的演练, 只有经过真实演练, 才能确保备节点是可用的。

我们是如何进行演练的呢? 首先, 按照演练流程, 我们会将所有流量切换到备节点。由于备节点的写入需先转发到主节点再同步回来, 大量写请求会导致延迟升高, 对业务是不可用的。因此, 我们必须同步进行数据库切换演练。

对于数据库切换, 操作步骤相对简单。首先, 我们会阻断主区域新加坡的写入, 防止与备区域同时写入导致数据不一致, 这不影响主备区域间的同步。同步完成后, 我们在控制台或通过自动化脚本, 调用Aurora 的故障转移API, 将备区域美国的Aurora 重启, 重启过程持续约42 秒。

在这42 秒内, 整个业务会短暂中断, 这是符合我们预期的。重启完成后, 美国节点被提升为主节点, 由于Web 流量和数据库都已切换到美国, 业务就恢复了, 演练基本结束。

最后,Aurora 会将原主区域新加坡从集群中剔除, 并新建一个备库, 进行数据同步。以我们一个300GB 的业务为例, 重建备库需约2.5 小时。如果数据量更大, 重建时间会更长, 会影响到下次主备切换的时间, 因为在此期间不能进行切换。

重建完成后, 我们就可以按相同流程将业务切换回新加坡, 完成一次完整的演练。通过这种方式, 我们实现了日常1% 流量验证备节点可用性, 并每季度100% 流量切换真实演练, 从而保障了业务的双活可用性。

该架构实施以来, 除了代码问题导致的不稳定外, 我们基本上没有遇到由基础设施引起的重大故障。如果哪天新加坡整个地区不可用, 我们可以在15 分钟内将业务切换到美国, 提供给用户正常访问, 这是该架构最大的价值。

另外, 通过Route 53 的区域解析, 我们可以灵活调整不同区域的流量分配权重。为了节省成本, 我们目前美国只保持一个小规模集群, 但我们已经容器化了, 可以快速扩容。

最后, 对于一些海外企业可能遇到的数据合规问题, 我们也可以直接将业务全部迁移到美国, 与新加坡区域隔离, 提升了合规能力。

总之, 该多区域多活架构利用了亚马逊云科技的多种服务和功能, 实现了我们15 分钟内故障恢复的目标, 提高了业务连续性, 也增强了合规能力, 对需要高可用性的游戏及其他业务都有借鉴意义。

简要总结一下, 该案例分享了37Games 如何在亚马逊云科技上构建游戏平台服务的多区域多活容灾架构, 利用了CloudFront 、Route 53 、Aurora 全球数据库、DynamoDB 全局表等服务, 通过日常1% 流量验证和每季度全量流量切换演练, 实现了15 分钟内故障恢复、提高了业务连续性, 也增强了合规能力, 是一个成功的容灾实践案例。

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

亚马逊云科技中国峰会2024 上, 演讲者介绍了游戏平台服的架构及其在亚马逊云科技上实现多区域容灾的方案, 并分享了该架构在实际生产环境中的应用及价值。

亚马逊云科技中国峰会2024: 介绍了CloudFront 和Route 53 实现多区域容灾failover 的架构设计。

亚马逊云科技Aurora for MySQL 的Global Database 功能确保了您可以在全球不同地区拥有相同的数据备份, 实现高效的数据同步和写操作转发。

亚马逊云科技中国峰会2024:DynamoDB 是一个完全托管的数据库服务, 支持全球任何地区读写同一张表, 采用Last Write Wins 策略解决数据冲突问题。

张辉分享了山西互娱如何利用亚马逊云科技多区域双活架构实现15 分钟内故障恢复的目标

亚马逊云科技中国峰会2024 上, 演讲者详细解释了Aurora 全球数据库的不同一致性级别及其对应的性能和延迟特点。

总结

亚马逊云科技为游戏行业提供了稳定可靠的多区域容灾解决方案。游戏平台服务是游戏公司的核心业务, 负责玩家注册、登录和充值等关键功能。为确保业务连续性,37Games 游戏平台采用了多活架构, 利用亚马逊云科技服务如CloudFront 、Route 53 、Aurora for MySQL 和DynamoDB 实现跨区域数据同步和故障切换。

在正常情况下, 主节点( 新加坡) 处理99% 的流量,1% 流量引导至重叠节点( 美国) 进行实时验证。一旦主节点发生故障, 可在15 分钟内将全部流量切换至重叠节点, 确保业务连续运行。该架构不仅提供了区域级别的多活容灾能力, 还增强了合规性, 满足了游戏公司对高可用性和数据安全的需求。

通过与亚马逊云科技紧密合作,37Games 成功构建了高度可靠的多区域容灾架构, 为玩家提供了稳定的游戏体验, 同时保护了关键业务数据, 充分展现了亚马逊云科技在游戏行业的卓越解决方案。

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