我们如何使 Roblox 的基础设施更加高效、更有弹性 - Roblox 博客

由柏拉图重新发布

关注： 0

随着 Roblox 在过去 16 年多的时间里不断发展，支持数百万沉浸式 3D 联合体验的技术基础设施的规模和复杂性也在不断增长。过去两年里，我们支持的机器数量增加了两倍多，从截至 36,000 年 30 月 2021 日的约 145,000 台增加到今天的近 1,000 台。为世界各地的人们提供这些始终在线的体验需要 XNUMX 多个内部服务。为了帮助我们控制成本和网络延迟，我们将这些机器作为主要在本地运行的定制混合私有云基础设施的一部分进行部署和管理。

我们的基础设施目前支持全球超过 70 万每日活跃用户，其中包括依赖 Roblox 的创作者经济为了他们的生意。所有这些数百万人都期望获得非常高水平的可靠性。鉴于我们体验的沉浸式本质，对滞后或延迟的容忍度极低，更不用说中断了。 Roblox 是一个沟通和联系的平台，人们可以在沉浸式 3D 体验中聚集在一起。当人们在沉浸式空间中以化身进行交流时，即使是微小的延迟或故障也比在文本线程或电话会议中更明显。

2021 年 73 月，我们经历了一次全系统中断。事情一开始很小，一个数据中心的一个组件出现了问题。但在我们调查过程中，它迅速蔓延，最终导致了 XNUMX 小时的停电。当时我们俩共享有关所发生事件的详细信息以及我们从这个问题中得到的一些早期经验。从那时起，我们一直在研究这些经验教训，并努力提高基础设施的弹性，以应对所有大型系统中由于极端流量高峰、天气、硬件故障、软件错误等因素而发生的故障类型。人类会犯错误。当发生这些故障时，我们如何确保单个组件或组件组中的问题不会蔓延到整个系统？这个问题一直是我们过去两年关注的焦点，虽然工作仍在进行中，但我们迄今为止所做的一切已经得到了回报。例如，与 2023 年上半年相比，125 年上半年我们每月节省了 2022 亿小时的参与时间。今天，我们将分享我们已经完成的工作，以及我们构建更具弹性的基础设施系统。

建立一个后挡板

在大型基础设施系统中，小规模故障每天会发生多次。如果一台机器出现问题并且必须停止服务，这是可以管理的，因为大多数公司都维护其后端服务的多个实例。因此，当单个实例发生故障时，其他实例会承担工作负载。为了解决这些频繁失败的问题，请求通常设置为在出现错误时自动重试。

当系统或人员过于积极地重试时，这就变得具有挑战性，这可能成为这些小规模故障在整个基础设施中传播到其他服务和系统的一种方式。如果网络或用户足够持续地重试，它最终将使该服务的每个实例以及全球范围内的其他系统过载。我们 2021 年的停机是由大型系统中相当常见的情况造成的：故障从小处开始，然后在整个系统中传播，规模如此之快，以至于在一切都崩溃之前很难解决。

在停电时，我们有一个活动数据中心（其中的组件充当备份）。当出现问题导致现有数据中心瘫痪时，我们需要能够手动故障转移到新数据中心。我们的首要任务是确保 Roblox 的备份部署，因此我们在位于不同地理区域的新数据中心构建了该备份。这增加了对最坏情况的保护：中断蔓延到数据中心内足够多的组件，导致数据中心完全无法运行。我们现在有一个数据中心处理工作负载（主动），还有一个备用数据中心作为备份（被动）。我们的长期目标是从主动-被动配置转向主动-主动配置，其中两个数据中心都处理工作负载，并使用负载均衡器根据延迟、容量和运行状况在它们之间分配请求。一旦到位，我们希望所有 Roblox 都具有更高的可靠性，并且能够几乎立即进行故障转移，而不是几个小时。

转向蜂窝基础设施

我们的下一个优先事项是在每个数据中心内部创建坚固的防爆墙，以减少整个数据中心发生故障的可能性。单元（一些公司称之为集群）本质上是一组机器，也是我们创建这些墙的方式。我们在单元内部和单元之间复制服务以增加冗余。最终，我们希望 Roblox 的所有服务都在单元中运行，这样它们就可以从坚固的防爆墙和冗余中受益。如果某个单元不再发挥作用，可以安全地将其停用。跨单元的复制使服务能够在单元修复时继续运行。在某些情况下，细胞修复可能意味着细胞的完全重新配置。在整个行业中，擦除和重新配置一台单独的机器或一小组机器相当常见，但对包含约 1,400 台机器的整个单元执行此操作则不然。

为了实现这一点，这些单元需要在很大程度上保持一致，这样我们就可以快速有效地将工作负载从一个单元转移到另一个单元。我们设置了服务在单元中运行之前需要满足的某些要求。例如，服务必须容器化，这使得它们更加可移植，并防止任何人在操作系统级别进行配置更改。我们对单元采用了基础设施即代码的理念：在我们的源代码存储库中，我们包含单元中所有内容的定义，以便我们可以使用自动化工具从头开始快速重建它。

目前，并非所有服务都满足这些要求，因此我们一直致力于帮助服务所有者尽可能满足这些要求，并且我们构建了新工具，以便在准备就绪时可以轻松地将服务迁移到单元中。例如，我们的新部署工具自动跨单元“条带化”服务部署，因此服务所有者不必考虑复制策略。这种严格程度使得迁移过程更具挑战性和耗时，但长期回报将是一个系统：

遏制故障并防止其扩散到其他单元要容易得多；
我们的基础设施工程师可以更加高效、行动更加迅速；和
构建最终部署在单元中的产品级服务的工程师不需要知道或担心他们的服务在哪些单元中运行。

解决更大的挑战

与防火门用于遏制火焰的方式类似，单元在我们的基础设施中充当坚固的防爆墙，以帮助遏制在单个单元内触发故障的任何问题。最终，构成 Roblox 的所有服务都将在单元内部和单元之间进行冗余部署。一旦这项工作完成，问题仍然可能传播得足够广，导致整个单元无法运行，但问题很难传播到该单元之外。如果我们成功地使细胞可以互换，恢复速度将会显着加快因为我们将能够故障转移到不同的单元并防止问题影响最终用户。

棘手的地方在于将这些单元分开，以减少传播错误的机会，同时保持性能和功能。在复杂的基础设施系统中，服务需要相互通信以共享查询、信息、工作负载等。当我们将这些服务复制到单元中时，我们需要考虑如何管理交叉通信。在理想的世界中，我们将流量从一个不健康的细胞重定向到其他健康的细胞。但我们如何应对“死亡询问”—— 造成细胞不健康？如果我们将该查询重定向到另一个单元，则可能会导致该单元以我们试图避免的方式变得不健康。我们需要找到机制来转移不健康细胞的“良好”流量，同时检测和抑制导致细胞变得不健康的流量。

短期内，我们已将计算服务的副本部署到每个计算单元，以便单个单元可以满足对数据中心的大多数请求。我们还在单元之间对流量进行负载平衡。展望未来，我们已经开始构建下一代服务发现流程，该流程将由服务网格利用，我们希望在 2024 年完成。这将使我们能够实施复杂的策略，仅在以下情况下才允许跨单元通信：它不会对故障转移单元产生负面影响。 2024 年还将推出一种将相关请求定向到同一小区中的服务版本的方法，这将最大限度地减少跨小区流量，从而降低跨小区传播故障的风险。

在高峰期，我们超过 70% 的后端服务流量是在单元外提供服务的，我们已经了解了很多有关如何创建单元的知识，但随着我们在 2024 年继续迁移我们的服务，我们预计会进行更多的研究和测试。超过。随着我们的进步，这些防爆墙将变得越来越坚固。

迁移始终在线的基础架构

Roblox 是一个支持世界各地用户的全球平台，因此我们无法在非高峰或“停机时间”期间移动服务，这使得将我们所有机器迁移到单元以及在这些单元中运行的服务的过程进一步复杂化。我们有数以百万计的永远在线的体验，需要继续得到支持，即使我们移动它们运行的机器和支持它们的服务。当我们开始这个过程时，我们并没有数以万计的机器闲置未使用且可用于迁移这些工作负载。

然而，我们确实购买了少量额外的机器，以应对未来的增长。首先，我们使用这些机器构建新的单元，然后将工作负载迁移到它们。我们重视效率和可靠性，因此，一旦我们用完“备用”机器，我们不会出去购买更多机器，而是通过擦除和重新配置我们迁移的机器来构建更多单元。然后，我们将工作负载迁移到这些重新配置的机器上，并重新开始该过程。这个过程很复杂——当机器被替换并被释放到细胞中时，它们并没有以理想、有序的方式释放。它们在物理上分散在数据大厅中，使我们能够以零碎的方式配置它们，这需要硬件级碎片整理过程来保持硬件位置与大规模物理故障域保持一致。

我们基础设施工程团队的一部分致力于将现有工作负载从我们的遗留或“前单元”环境迁移到单元中。这项工作将继续下去，直到我们将数千个不同的基础设施服务和数千个后端服务迁移到新建的单元中。由于一些复杂的因素，我们预计这将需要明年一整年，甚至可能持续到 2025 年。首先，这项工作需要构建强大的工具。例如，当我们部署新单元时，我们需要工具来自动重新平衡大量服务，而不影响我们的用户。我们还看到了根据我们的基础设施假设构建的服务。我们需要修改这些服务，以便它们不依赖于未来当我们进入细胞时可能发生变化的事情。我们还实现了一种搜索无法与蜂窝架构很好地配合的已知设计模式的方法，以及针对每个迁移的服务的系统测试流程。这些流程帮助我们避免因服务与单元不兼容而导致的任何用户面临的问题。

如今，近 30,000 台机器由单元管理。它只占我们机队总数的一小部分，但到目前为止，过渡非常顺利，没有对玩家产生负面影响。我们的最终目标是让我们的系统每月实现 99.99% 的用户正常运行时间，这意味着我们不会中断超过 0.01% 的参与时间。在整个行业范围内，停机时间无法完全消除，但我们的目标是将 Roblox 停机时间减少到几乎无法察觉的程度。

随着我们规模的扩大，面向未来

虽然我们的早期努力被证明是成功的，但我们在细胞方面的工作还远未完成。随着 Roblox 的不断扩展，我们将继续努力通过这项技术和其他技术来提高系统的效率和弹性。随着我们的发展，平台对问题的弹性将越来越大，发生的任何问题对于我们平台上的人们来说都应该逐渐变得不那么明显和具有破坏性。

总而言之，迄今为止，我们已经：

建设第二个数据中心并成功实现主被动状态。
在我们的主动和被动数据中心创建单元，并成功将超过 70% 的后端服务流量迁移到这些单元。
设置我们需要遵循的要求和最佳实践，以在我们继续迁移基础设施的其余部分时保持所有单元的统一。
开始了在细胞之间建造更坚固的“防爆墙”的连续过程。

随着这些电池的互换性越来越强，电池之间的串扰将会减少。这为我们带来了一些非常有趣的机会，可以提高监控、故障排除甚至自动转移工作负载的自动化程度。

九月，我们还开始在我们的数据中心运行主动/主动实验。这是我们正在测试的另一种机制，旨在提高可靠性并最大限度地减少故障转移时间。这些实验帮助确定了许多系统设计模式，主要围绕数据访问，在我们推动完全主动-主动的过程中，我们需要重新设计这些模式。总体而言，该实验非常成功，足以让它针对有限数量的用户的流量运行。

我们很高兴能够继续推动这项工作，为平台带来更高的效率和弹性。这项在蜂窝和主动-主动基础设施方面的工作，以及我们的其他努力，将使我们能够成长为一个为数百万人服务的可靠、高性能的公用事业公司，并在我们努力将十亿人真正连接起来的过程中继续扩大规模。时间。