亚马逊AWS官方博客
使用 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 是他们的正确选择？
- 内置 MySQL 兼容性：与 MySQL 的兼容性让游戏开发人员可以与 Aurora 集成，无需更改应用程序即可享受所有优势。他们只需修改应用程序中数据库配置的终端节点。他们可以继续使用原来使用的代码和工具。
- 无需决定要为数据库分配多少存储容量：决定要为数据库分配多少存储容量，尤其是为生产工作负载分配容量，是游戏开发人员（或者普通开发人员和数据库管理员）不想作出的决定之一。分配太少，您会在最需要的事后耗尽空间，让您不得不让游戏进入维护模式，等待升级完成。分配太多，又会浪费金钱。使用 Aurora 后，数据库存储在集群卷中，集群卷是一个使用固态磁盘 (SSD) 驱动器的单一虚拟卷。一个集群卷由跨一个区域中多个可用区的数据副本组成。Aurora 集群卷会自动随着数据库中数量的增长而增长。Aurora 集群卷可增长至 64 TB 的最大容量。表的大小受集群卷的大小限制。换言之，Aurora 数据库集群中表的最大容量为 64 TB。尽管 Aurora 集群卷最大可增长至 64 TB，但您仍只需为 Aurora 集群卷中使用的空间付费。您的起始卷容量可以低至 10 GB。
- 独特的只读副本：Aurora 的只读副本使用与主实例相同的底层集群卷。这种方法有利于减少复制延迟，即使在不同的可用区启动副本也不受影响。Aurora 最高支持 15 个副本，对写操作的性能影响极低。而 MySQL 最高仅支持 5 个副本，并且可能会影响写操作的性能，出现一些复制延迟。此外，Aurora 会自动将其副本作为故障转移目标，不会发生数据丢失。由于这些副本以同一底层存储作为主实例，它们相比主实例的延迟仅为数十毫秒，达到了近乎同步的性能。
- Amazon 为您管理数据库：游戏开发人员关心的是构建伟大的游戏，而不是处理维护和运行问题。Amazon Aurora 是一种托管服务，包含了运营支持和跨多个数据中心的高可用性。您无需担心软件安装或硬件故障问题。
- 性能提升：游戏客户已经报告在迁移到 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 的自动化机制让我们的选项包得到一次巨大的补充，并且在此案中，问题在几分钟之内就解决了，而不是几小时。”
资源
此文详细介绍了您可以如何简化 Aurora 中的 MySQL 环境：Reduce Resource Consumption by Consolidating Your Sharded System into Aurora。
您还可以在此数据库博客文章中了解 Aurora 如何处理存储层扩展问题的详细信息：Introducing the Aurora Storage Engine。