PCon全球产品创新大会最新日程上线,这里直达 了解详情
写点什么

使用 Amazon Aurora 升级游戏体验

  • 2019 年 10 月 12 日
  • 本文字数:3420 字

    阅读完需:约 11 分钟

使用 Amazon Aurora 升级游戏体验

Dhruv Thukral 是 Amazon Web Services 的一名解决方案架构师。


Amazon Aurora 正在快速成为全球一些大型和快速增长的游戏公司的首选关系数据库。美洲的 Zynga 和 Double-Down Interactive、亚太地区的 Grani 和 Gumi 等公司都在使用 Amazon Aurora。Aurora 既具有高端商用数据库的速度和可用性,又具有开源数据库的简单性和成本结构。


速度和成本的这种优势组合甚至让 Double-Down Interactive 等公司运行 Aurora 的成本比 MySQL 还低。Aurora 具有更高的性能,这意味着您可以经常使用比 MySQL 更少或更小的实例。如果像许多游戏公司一样运行分区式的 MySQL 环境,您潜在可以通过迁移到 Aurora 节约许多成本。此外,正如本博文后将讲到,您还可以获得两三倍的性能提升。其他潜在的优势还包括更高的可用性、更低的复制延迟和更少的分区,因为您可以整合现有的分区。


在本博文中,我们将讨论 Amazon Aurora 可以如何使用面向手机游戏的示例参考架构,帮助您构建可靠、可扩展的数据库层。此外,我们还将重点介绍已经将其现有数据库迁移到 Amazon Aurora 的游戏客户的经验。


选对数据库的价值


在设计大型应用程序的架构时,一个关键因素是数据库层。游戏负载的读取和写入负载极高,数据库层尤其重要。随着玩家的等级提升、打败敌人、收到游戏币、改变清单、解锁升级以及完成成绩等等,游戏数据在持续更新和读取。每个事件都必须写入您的数据库层,从而确保它不会丢失。在游戏中失去这一进步可能导致在 Twitter 中的负面帖子趋势,并在夜间被张贴出来。


游戏和 Web 应用程序开人员常常会将 MySQL 等开源关系数据库作为其数据库层,因为他们对它更为熟悉。查询的灵活性和游戏逻辑事务方面的 ACID 属性对许多开人员极具吸引力。扩展这一层级的传统方式,尤其是在使用 MySQL 时,是通过分区。在某些情况下,扩展也可通过将读取操作卸载到只读副本中来实现。虽然这种方法可让开发人员持续增加分区,维护这种基础设施却会带来开销。例如,如果一个分区中的存储耗尽,或者您的只读副本发生故障该怎么办? 或者,如果发生意外,您丢失了整个分区以及其中的数据该怎么办?


为什么游戏开发人员感觉 Aurora 是他们的正确选择?


1.内置 MySQL 兼容性:与 MySQL 的兼容性让游戏开发人员可以与 Aurora 集成,无需更改应用程序即可享受所有优势。他们只需修改应用程序中数据库配置的终端节点。他们可以继续使用原来使用的代码和工具。


2.无需决定要为数据库分配多少存储容量:决定要为数据库分配多少存储容量,尤其是为生产工作负载分配容量,是游戏开发人员(或者普通开发人员和数据库管理员)不想作出的决定之一。分配太少,您会在最需要的事后耗尽空间,让您不得不让游戏进入维护模式,等待升级完成。分配太多,又会浪费金钱。使用 Aurora 后,数据库存储在集群卷中,集群卷是一个使用固态磁盘 (SSD) 驱动器的单一虚拟卷。一个集群卷由跨一个区域中多个可用区的数据副本组成。Aurora 集群卷会自动随着数据库中数量的增长而增长。Aurora 集群卷可增长至 64 TB 的最大容量。表的大小受集群卷的大小限制。换言之,Aurora 数据库集群中表的最大容量为 64 TB。尽管 Aurora 集群卷最大可增长至 64 TB,但您仍只需为 Aurora 集群卷中使用的空间付费。您的起始卷容量可以低至 10 GB。


3.独特的只读副本:Aurora 的只读副本使用与主实例相同的底层集群卷。这种方法有利于减少复制延迟,即使在不同的可用区启动副本也不受影响。Aurora 最高支持 15 个副本,对写操作的性能影响极低。而 MySQL 最高仅支持 5 个副本,并且可能会影响写操作的性能,出现一些复制延迟。此外,Aurora 会自动将其副本作为故障转移目标,不会发生数据丢失。由于这些副本以同一底层存储作为主实例,它们相比主实例的延迟仅为数十毫秒,达到了近乎同步的性能。


4.Amazon 为您管理数据库:游戏开发人员关心的是构建伟大的游戏,而不是处理维护和运行问题。Amazon Aurora 是一种托管服务,包含了运营支持和跨多个数据中心的高可用性。您无需担心软件安装或硬件故障问题。


5.性能提升:游戏客户已经报告在迁移到 Amazon Aurora 后,与现有的开源数据库相比,性能提升了两三倍。日本领先的社交游戏出版商 Grani 将其 MySQL 数据库迁移到了 Aurora 并分享了如下结果。第一段显示了他们原有系统的平均 Web 事务响应时间,按照总体堆栈中不同层级细分。



按照之前的架构,Grani 在 Amazon RDS 中 r3.4xl 实例类型上运行 MySQL 并启用了多可用区模式。他们的总数据库响应时间介于 15-22 毫秒之间,总体响应时间约为 50 毫秒。下图显示了迁移到 Amazon Aurora 后的结果。



他们迁移到一个类似的 r3.4xl 节点,含有一个主实例和一个只读副本。他们的总体响应时间降至 5.5 毫秒。下图显示了他们的平台数据库迁移前后的总体响应时间的完整情况。



Amazon Aurora 快速入门


为我们在 AWS 上运行的手机游戏和在线游戏更新旧版示例参考架构时,我们认识到像游戏客户推荐 Aurora 的重要性。下图为更新后的异步在线游戏参考架构,它演示了如何使用 AWS 来为大型手机游戏和在线游戏构建服务后端。此类工作负载天然适合在 AWS 上运行,因为其流量模式具有不可预期性,请求率要求极高。AWS 提供了极佳的灵活性,可以从小规模起步,然后根据玩家的需求扩展架构。架构可以向上扩展也可以向下收缩,从而确保您只需为推动游戏最佳体验的资源付费。使用我们针对流行缓存和数据库技术的托管服务,并借助当今在 AWS 上运行的大型游戏最佳实践的架构。



前述架构建议您在多个可用区部署 Aurora,建议的起始节点大小为 R3.2XL 和三个只读副本。我们建议采用这种配置,是因为我们假设您的游戏的读取操作要高于写入操作,可以从额外的只读副本中受益。此外,当您将 Aurora 副本作为故障转移的目标数据库时,您还可以受益于固有的高可用性优势。


在参考前述架构时要注意以下几点:


  • 分区配置:前述架构采用单一分区配置,拥有一个主实例和三个副本。为了平衡成本和高可用性,如果您的环境拥有多个分区,您可以将前述配置修改为每个分区一个 Aurora 主实例和两个只读副本。这种方法将允许您在发生故障转移事件时仍然有一个主实例和一个只读副本。

  • 重试逻辑:如果发生主实例故障,一个 Aurora 副本将会晋升为主实例。这时将发生短暂的中断,在此期间向主实例提出的读取和写入请求将因异常而失败。确保您的游戏可以从容处理这种情形,并且游戏客户端中拥有内置的重试逻辑,或有恰当的异常处理功能。

  • 连接池:假设您使用 c3p0、HikariCP、Apache DBCP 等流行的连接池库,并且希望支持大型连接池;如果属于这种情况,请注意 Aurora 线程池的工作原理与 MySQL 不同。Aurora 的线程池采用多重连接等功能,并且能够处理超过 5000 个并发会话,可扩展性远远高于 MySQL 线程池。同样,我们建议您对工作负载进行测试,以确保您获得游戏要求的性能。

  • 客户案例:Zynga


在使用 Amazon Aurora 前,Zynga 使用的是 RDS for MySQL。Zynga 当时在考虑将现有使用 Amazon EBS 卷的分区环境迁移到使用本地 SSD 的 i2 实例,以满足极高的 IOPS 需求。在他们考虑使用自我管理的 i2 实例时,他们在推出一项新服务前也开始平行测试 Aurora。经过八个月的生产运行后,Aurora 的表现超过了他们的预期。最繁忙的实例是一个 r3.2xl 实例,高峰时期它每秒要为一个 150 GB 的数据集处理大约 9000 条选择。Zynga 对 Aurora 实现了必要的性能但没有发生运行 MySQL 的开销这一事实非常满意。


此外,这种自动化机制让 Zynga 可以极高的敏捷性来应对运营事故。如果流量模式发生变化,导致某个 Aurora 实例的负载巨额突增,该实例将能够继续处理流量,尽管 CPU 利用率达到了 100%。此外,它们甚至还提高了吞吐量,将只读副本扩展为一个比原来大四倍的实例。然后它们通过故障转移切换到副本,然后观察它处理四倍的流量,所有这一切都只需在 RDS 控制台中进行几次点击。几天后,在他们发布防止事故再次发生的补丁后,他们使用同一流程缩减回较小的实例。


Zynga 的架构师 Chris Broglie 说:“在使用 Aurora 以前,我们必须让一位数据库管理员在线手动预置、复制和故障转移到较大的实例,或者尝试发出某个代码补丁以减少数据库的负载。手动更改一般更慢,风险更大,因为 Aurora 的自动化机制让我们的选项包得到一次巨大的补充,并且在此案中,问题在几分钟之内就解决了,而不是几小时。”


本文转载自 AWS 技术博客。


原文链接:


https://amazonaws-china.com/cn/blogs/china/level-up-your-games-with-amazon-aurora-2/


2019 年 10 月 12 日 13:22264
用户头像

发布了 1422 篇内容, 共 45.9 次阅读, 收获喜欢 53 次。

关注

欲了解 AWS 的更多信息,请访问【AWS 技术专区】

评论

发布
暂无评论
发现更多内容

小企业面对大数据如何破局,高并发与海量数据技术又如何操作?

守护石

大数据 分布式架构 高并发系统设计 战略思考

今日学习小结

Nydia

学习

Flutter开发:Gridview的使用

三掌柜

5月日更

TcaplusDBx 王者荣耀|五五开黑节与其背后的数据库

数据人er

数据库 nosql tencentdb TcaplusDB

花一周整理!Python全系列学习资料,全是干货

Python研究者

今天被问微服务,这几点,让面试官刮目相看

Damon

面试 微服务 5月日更

c++的并发操作(多线程)

赖猫

c++ Linux 多线程 服务端 并发

JavaScript 进阶——井字棋游戏智能AI搭建

空城机

JavaScript 大前端 5月日更 web游戏

JS中every()和some()的对比使用

三掌柜

5月日更 领航计划

APP透露的焦虑

wgc

杂谈

Netty整体架构学习笔记

风翱

Netty 5月日更

音视频同步!RTCP协议解析及代码实现

明儿

c++ 音视频 协议 Wireshark 流媒体

就这?腾讯云高工熬夜手写'Java微服务学习笔记'也就让我月薪涨3k

Java 编程 程序员 架构 面试

API网关关键技术

lenka

5月日更

《互联网人的英语私教课》复习

IT蜗壳-Tango

5月日更

TcaplusDBx 王者荣耀|五五开黑节背后的数据存储挑战

TcaplusDB

nosql 分布式 存储 TcaplusDB

为什么突然谁都能造车了?

白洞计划

C++ & Linux 后端:进BAT的学习路线

赖猫

c++ Linux 后端 服务器端开发

网络攻防学习笔记 Day14

穿过生命散发芬芳

5月日更 网络攻防

数据挖掘从入门到放弃(一):线性回归和逻辑回归

数据社

机器学习 5月日更

Golang library source file 库源码文件

escray

学习 极客时间 Go 语言 5月日更

5G Capital一年,“首都标准”初现

脑极体

不是会员不让复制粘贴?看我“三板斧”!

liuzhen007

使用技巧 5月日更

学生管理系统考试试卷存储方案

Simon

架构实战营

服务调用链相关基础知识

luojiahu

调用链

这个世界不会欺负诚实的人,也绝对不会亏待努力的人

小天同学

5月日更 真诚 诚信 努力

谈谈企业的成本

石云升

创业 职场经验 5月日更

声网2020实时大会后的弱网对抗实践

Fenngton

音视频 网络环境 视频编解码 声网 弱网下的极限实时视频通信

数据续谈

顿晓

数据 5月日更

腾讯云TcaplusDB与华为鲲鹏完成兼容性认证

数据人er

数据库 nosql tencentdb TcaplusDB 华为鲲鹏

5分钟速读之Rust权威指南(二)

码生笔谈

rust

ShadowRealm 与微前端沙箱

ShadowRealm 与微前端沙箱

使用 Amazon Aurora 升级游戏体验-InfoQ