暴雪娱乐正在努力寻求一劳永逸地消除缩放复杂性。
暴雪娱乐是一家位于加利福尼亚州的软件公司，专注于为美洲、欧洲、亚洲和澳大利亚的客户创造和开发游戏娱乐。 6 月下旬，该公司的两位工程主管 Colin Cashin 和 Erik Andersson 在 OpenDev 虚拟活动中与开源社区讨论了他们的云战略和扩展挑战，重点是开放基础设施的大规模使用。
暴雪采用多云策略。 该公司使用亚马逊、谷歌和阿里巴巴的公共云，自2016年以来还拥有并运营着一个基于OpenStack的广泛的全球私有云平台。暴雪目前在OpenStack上有12,000 个计算节点分布在全球，甚至在去年成功地一次升级了五个版本以开始使用Rocky。暴雪的团队也致力于为上游做出贡献。
总而言之，暴雪重视简单胜过复杂，并通过解决四大扩展挑战来不断努力应对复杂性。
扩展挑战 #1：
暴雪面临的第一个扩展挑战是使用NUMA固定的Nova调度。 NUMA pinning确保来宾虚拟机不会在双插槽计算节点上跨NUMA区域进行调度，从而避免了在CPU上tarversing oversubscribed总线互连的惩罚。 对于高性能游戏服务器工作负载，这是出色和不出色的玩家体验之间的区别。2016年，他们决定在调度期间实施NUMA pinning以防止这些问题，赶在暴雪推出第一款基于团队的第一人称射击游戏(FPS)守望先锋之前。 在规模上，这个决定造成了很多痛苦。 NUMA调度非常昂贵，需要重新调用Nova DB，从而影响该过程的周转时间。 在特别大的部署期间，他们经常遇到调度失败的竞争条件，并最终通过配置调整解决了这个问题，将调度程序的目标池从1个计算节点增加到20个计算节点。NUMA pinning的另一个副作用是破坏了实时迁移，这个障碍现在已在Train的Nova版本中修复。
要点：对于大型环境，NUMA pinning应该以经过测试和控制的方式实施，并且使用 NUMA 分析的实时迁移在新版本中得到修复。
扩展挑战 #2：
接下来，Cashin和Andersson讨论了扩展RabbitMQ。RabbitMQ是一种在OpenStack组件之间充当消息传递代理的工具，但在暴雪的案例中已被证明很容易被淹没。 在出现问题时恢复服务（例如数据中心中的大规模网络事件）似乎是他们面临的最大挑战，这是不容忽视的事情。 为了解决这个问题，暴雪调整了RabbitMQ配置以引入具有差异的扩展连接超时，以允许更慢但更优雅的恢复。对Rabbit队列应用了额外的调整，以确保只有关键队列在集群中被复制，并且队列在这些事件期间不会呈指数增长。
要点：RabbitMQ需要针对您的环境进行独特的调整。
扩展挑战 #3：
Neutron缩放被证明是暴雪的第三大障碍。由于将某些OpenStack服务托管在相同的控制器主机上，暴雪经历了几起旷日持久的运营事件。暴雪团队在2019年解决了这个问题，当时他们决定通过将Neutron RPC worker迁移到虚拟机来横向扩展。迁移到VM也解决了API和工作池的共同命运。此外，当元数据服务大规模代理大量数据时，还存在控制平面不堪重负的问题。 经过大量研究和与社区的对话，Andersson能够将间隔时间延长至4-5分钟，并在正常操作期间将控制平面的负载大大降低高达75%。
要点：随着云规模的增长，应仔细考虑Neutron配置和部署。
扩展挑战 #4：
最后，计算机群维护问题已经困扰暴雪很长一段时间了。随着他们的私有云大规模投入生产，内部驱动力将更多工作负载从裸机迁移到云中。在许多情况下，这意味着迁移发生在应用程序真正具有云感知能力之前。 随着时间的推移，这严重影响了暴雪维护舰队的能力。 升级需要大量的工作，而且无法扩展。在过去的15个月里，暴雪的软件团队开发了一款新产品Cloud Automated Maintenance，可以实现车队的自动清空和升级。该产品在底层使用Ironic来编排裸机和公共云风格的通知系统，所有这些都通过生命周期信号实现自动化。
要点：对迁移能力抱有严格期望的OpenStack租户，尤其是对于不太短暂的工作负载。 此外，在进入生产之前，要有适当的流程和/或系统来管理车队维护。
展望未来，暴雪将继续查明并应对挑战，以尽可能地大规模消除复杂性。 如果您有兴趣寻找应对这些挑战的解决方案，暴雪正在他们位于加利福尼亚州尔湾的办公室招聘。
注：内容援引OpenStack开源社区，原文链接：https://superuser.openstack.org/articles/for-blizzard-entertainment-its-game-over-on-scaling-complexity/