在亚马逊 GameLift 服务器上成功启动的启动阶段步骤

当一款游戏风靡一时时，从一开始就为成功做好准备至关重要。这篇文章涵盖了在亚马逊 GameLift 服务器上启动多人游戏时需要考虑的重要领域。我们将重点关注游戏发布前 2-3 个月所需的活动。这可能是你对游戏的全面公开发布，但也可能意味着公测、抢先体验或其他有真实玩家的里程碑。

我们将回顾游戏发布的最终计划的五个关键领域：

1. 填写启动问卷并提高限额
2. 设置您的生产队伍
3. 进行负载测试并测试关键路径
4. 监控 API 限制
5. 使用新游戏服务器版本在生产环境中使用蓝/绿部署

1 — 填写启动问卷并提高限额

实现里程碑（例如公测、抢先体验以及最终的完整游戏发布）的关键因素之一是确保提高服务限额以满足您的需求。Amazon GameLift 服务器的默认服务限制是为了保护账户在早期开发过程中免遭意外扩展。当你准备好开始积极支持玩家时，你可能需要更高的限额来提供支持玩家负荷所需的基础设施。

发布问卷可以在亚马逊 GameLift Servers 控制台中找到，在资源下的左侧菜单中，选择 “准备启动”。它既涵盖了所选实例类型的实例限制，也涵盖了亚马逊 GameLift 服务器 API 的限制限制。

填写问卷时的一些关键注意事项：

1. 在发布里程碑前 2-3 个月尽早执行此操作。
2. 请记住，测试版或私人预览版仍在发布中，因此您也需要增加上限。您可以随时为下一个里程碑发送新版本。
3. 多地点舰队有主区域和其他地点。记得定义舰队的本土区域，并根据所选的本土地区申请每个地点的限额。特定地点的实例限制将分别在每个主区域级别上设置。
4. 请务必查看您正在使用的确切亚马逊 GameLift API，并增加请求限额以匹配您的预期峰值请求率。避免在游戏会话创建流程中使用 Describe API，因为这些控制平面 API 通常不是为每个玩家请求调用而设计的。如果您需要调用这些 API，可以按中心方式进行调用，如在亚马逊 GameLift 服务器上托管永久世界游戏中所述。
5. 请务必为所有必需的亚马逊网络服务 (亚马逊云科技) 账户申请限额。这可能包括生产、测试和负载测试账户。

发送问卷时，请务必将您的亚马逊云科技账户团队添加到电子邮件中（如果您已分配），以保持所有人的意见一致。

图 1 显示了在亚马逊 GameLift 服务器控制台中何处可以找到启动问卷。

图 1：亚马逊 GameLift 服务器发布问卷。

2 — 设置您的生产队伍

我们建议对亚马逊 GameLift 服务器上的生产队列进行与开发队列不同的配置。

关键注意事项：

1. 将游戏扩展保护策略设置为完全保护。这样可以确保在舰队缩小规模时，正在运行的游戏会话受到保护。
2. 启用基于目标的自动扩展策略，并确保您在发布当天有充足的缓冲区（最多 30-50%）。稍后交通稳定后，您可以随时减少此次数。
3. 对每个地区使用多地点舰队，而不是单独的舰队。这将显著简化您的运营，因为它可以为您的全球机队资源提供单一视图并降低运营复杂性。
4. 考虑您的延迟目标和玩家人数，并相应地选择地点。低延迟的第一人称射击游戏通常需要在每个大陆有多个地点。节奏较慢的游戏可以从较少的位置中受益，从而简化操作。你可以使用亚马逊 GameLift 提供的 UDP ping 信标来测量客户端的延迟。
5. 为每个位置设置扩展配置（最小值和最大值），并确保每个位置都有良好的基准（最小值），并为需求突然出现峰值（最大）留出空间。

在发布当天，我们建议提前扩大规模，将每个地点的最小值设置为足够高的基准以覆盖初始流量峰值。流量模式稳定后，您可以随时将此值设置为较低的数字，但最好为较高的初始发布峰值做好准备。

能够使用多种实例类型托管游戏服务器，验证是否准备好应对意外玩家负载。例如，这可能是您所选实例系列的 .larg e 和 .xlarge 变体，或者同一实例系列中的不同实例系列或代代。虽然大多数游戏永远不需要托管多个舰队，但大规模地选择多舰队策略可以确保你拥有所需的容量。

图 2 显示了如何将两个多地点队列注册到同一个亚马逊 GameLift 服务器队列中。一个舰队使用 C6i.Larg e 实例类型，并进行了横向扩展，以应对游戏的启动。第二个队列使用 C5.larg e 实例类型，未向外扩展。通过启动问卷来处理生产流量，两种实例类型的限制均有所提高。在极少数情况下，其中一个地点的 C6i.Larg e可用性很低，拥有备用队列将允许使用不同的实例类型进行横向扩展，并继续为玩家提供服务。备份队列也可以是 C6i 系列中的另一种实例大小，例如 C6i.XLarge。

图 2：利用两支多地点舰队为大规模做好准备。

3 — 进行负载测试并测试关键路径

负载测试对于揭示基础架构中的任何瓶颈非常重要。这是为发射做准备的最重要步骤之一。

具体而言，对于亚马逊 GameLift Server 来说，负载测试可能会浮出水面：

1. 实例限制不足
2. API 限制不足（分别适用于每个 API）
3. 依赖关系问题，例如游戏服务器与之通信的后端系统

使用真实的流量模式大规模实施负载测试有助于揭露这些问题。这意味着要增加所有地点的会话放置请求，因为这些请求会带来大量的并发用户数，并确保所有系统都按预期运行。

测试在五分钟内将零并发用户扩展到500 K听起来像是一项不错的纸面测试，但是，它可能并不代表现实的流量模式。使用真实模式进行测试可以帮助您避免过分期望。上升到峰值的时间通常较长（通常超过数小时），您可以使用之前游戏的数据或工具（例如SteamDB）来查看发布的常见流量模式。

进行负载测试的关键方法有两种：

1. 可以通过直接调用 API 来测试队列的扩展和会话布局，例如StartGameSessionPlacement。可以使用 Python 或 Bash 脚本来完成，但实际客户端数量相对较少。对于您的 API 和实例限制以及扩展配置，这是一次很好的冒烟测试。
2. 测试完整的关键路径（包括您的后端）以及游戏服务器。这种方法包括实际创建账号和登录游戏，以及使用您的后端请求配对或会话投放。这是一种更全面的负载测试方法，它还可以测试后端是否存在任何瓶颈。我们建议使用游戏的无头机器人客户端（例如在 Amazon Fargate 容器上运行）或行为尽可能接近客户的脚本进行此测试。

最理想的是，在进行完整测试时，你还可以让客户端连接到游戏服务器，并像普通玩家一样通过发送动作和其他动作来玩游戏。这也将对游戏服务器的性能进行压力测试。当你让客户端玩完一个会话并注销连接下一个会话时，它还有助于测试真实的会话时长和游戏会话的轮换。

要成功监控这些测试，请使用本博客系列第一部分的监控、记录和警报部分中介绍的方法，即在Amazon GameLift Servers上成功启动的开发阶段步骤。此外，您应跟踪从亚马逊 GameLift Servers API 以及您或任何第三方管理的任何其他服务和组件收到的任何错误和限制。我们将在第 4 节 — 监控 API 限制中对此进行详细介绍。

正如Werner Vogels（亚马逊首席技术官）所说，“失败是理所当然的，随着时间的推移，一切最终都会失败”。确保您的关键路径能够正常处理任何依赖关系（Steam、主机登录、数据库等）的故障。您还应该确保可以从任何内部故障中恢复。这将帮助您为发布当天的任何惊喜做好准备。

图 3 显示了在 Amazon Fargate 上托管负载测试客户端的示例，该服务运行多个 Amazon Elastic Container Service (Amazon ECS) 任务，每个任务最多可托管 10 个独立的客户容器。负载测试客户端可以在多个亚马逊云科技区域运行，以测试延迟和玩家位置如何影响体验。这些客户端可以是实际游戏客户端的脚本化无头版本，也可以是充当游戏客户端的脚本。

图 3：关键路径负载测试。

4 — 监控 API 限制

在负载测试期间，亚马逊 GameLift 服务器 API 调用可能会超过默认的预置限制，从而导致节流错误。识别和响应受限呼叫对于运营稳定性、可用性以及确认无缝的玩家体验至关重要。

Amazon CloudTrail 为亚马逊 GameLift 服务器提供全面的 API 事件跟踪功能，因此您可以监控和审计所有 API 使用情况。

您可以有效地使用 CloudTrail 来：

• 追踪亚马逊 GameLift Servers API 活动
• 识别节流
• 针对自定义 CloudWatch 指标配置警报
• 通知运营团队请求提高限额，使其符合您的预期峰值请求率

监控限制的位置以及以下eventSource任gamelift.amazonaws.com一errorCode或errorMessage将应用于 CloudTrail 记录：

• errorCode是 ThrottlingException
• errorCode是 RequestLimitExceeded
• errorMessage是 RateExceeded

为了提高运营可见性，请在 CloudTrail 中创建新跟踪并启用 CloudWatch 日志。确保您拥有正确的 Amazon Identity and Access Management (IAM) 权限，可以将日志写入 CloudWatch 日志。指定 CloudWatch 日志组来捕获亚马逊 GameLift 事件。配置完成后，您将在CloudWatch日志中看到所有Amazon GameLift API调用和相关的限制错误。

在 CloudWatch 日志中，选择 CloudTrail 用来写入日志的日志组，然后创建自定义指标筛选器来识别限制模式。您应该分配一个命名空间并成功创建自定义指标，该指标每当出现限制时都会递增。

以下是过滤器模式的示例：

{ ($.eventSource = “gamelift.amazonaws.com”) && ($.errorCode = “ThrottlingException”) }

现在，有了自定义指标，就可以配置 CloudWatch 警报以监控节流阈值。例如，如果在五分钟内出现超过 10 个限制请求，则触发警报。将创建的警报附加到向您的运营团队发送电子邮件、短信服务 (SMS) 或聊天通知的亚马逊简单通知服务 (Amazon SNS) 主题。然后，他们可以审查 API 的使用情况并采取相应的措施。

要在请求增加限额之前尽量减少限制，请执行以下操作：

• 通过亚马逊 GameLift Servers API 调用实现指数回退
• 从 Amazon GameLift Servers API 检索大型数据集时使用分页和筛选
• 缓存经常访问的数据，例如舰队信息，以避免重复调用 API
• 尽可能进行批量操作以降低 API 调用频率

5 — 在新游戏服务器版本的生产环境中使用蓝/绿部署

成功进入制作阶段后，你需要在开始时相对频繁地对游戏服务器进行补丁，并在游戏添加功能和改进时持续进行补丁。在亚马逊 GameLift 服务器上进行更新的推荐方法是蓝/绿部署。

通过这种方法，你可以使用新的游戏服务器版本或容器镜像来建立一个全新的生产队列。一旦你准备好了新的舰队并且监控效果良好，你可以再做一个步骤，通过几个游戏环节对其进行烟雾测试。之后，通过切换您的亚马逊 GameLift 服务器队列来进行机上更新，将会话放置路由到新队列而不是旧队列。新会话将开始在新版本上创建，但是在旧队列上运行会话可以不受干扰地运行。

如果一切顺利，你可以在旧舰队的会话耗尽后将其终止。如果您需要回滚到先前版本，则可以通过切换队列目标切换回旧版本。这是蓝/绿部署的关键优势之一。

如果您不使用队列进行会话放置，则可以以类似的方式使用别名资源。亚马逊 GameLift 服务器工具包中有一个 python 脚本可以展示如何实现这种方法。

图 4 显示了蓝/绿部署，其中队列后面的队列被替换为新的队列，而先前队列上的旧会话被耗尽。

图 4：蓝/绿部署。

结论

我们介绍了如何确保扩大服务限制，以便在亚马逊 GameLift 服务器上成功推出量产。然后，我们讨论了设置生产车队的关键注意事项。我们还介绍了负载测试如何帮助您为发射做好准备，以及进行负载测试的常用方法有哪些。最后，我们讨论了蓝/绿部署如何帮助您管理生产环境中的动态服务器版本更新。

该系列涵盖了为在亚马逊 GameLift Servers 上成功发布游戏做好运营和架构准备的各个方面。立即开始使用用于多人游戏服务器托管的亚马逊 GameLift 服务器。联系亚马逊云科技代表，了解我们如何帮助加速您的业务。

进一步阅读

• 为游戏的发布做准备
• 亚马逊 GameLift 每款游戏实现了 1 亿并发连接用户
• 在亚马逊 GameLift 服务器上托管永久世界游戏

Juho Jantunen

Juho Jantunen 是亚马逊云科技游戏团队的全球首席解决方案架构师，专注于游戏后端和游戏服务器托管解决方案。他拥有游戏行业和云技术背景，曾在亚马逊云科技上为拥有数百万玩家的多款游戏构建和运营游戏后端。

Sushil Ranganathan

苏希尔·兰加纳森是亚马逊网络服务的高级技术客户经理。他拥有超过 12 年的行业经验，热衷于帮助战略行业的客户在亚马逊云科技云中构建和运营企业级解决方案。