大规模分布式系统资源管理（一）

如今大火的机器学习和人工智能等技术如何应用在资源管理方面？我们请到了南开大学的王刚和李雨森教授前来 360，分享他们以及所在课题组在大规模分布式系统资源管理方面的研究工作，内容包括云游戏系统中的请求调度、资源分配，以及搜索引擎数据中心的负载均衡、配额管理等。

主要内容

1 云游戏中的资源管理

2 搜索引擎中的资源管理

3 AI 在资源管理中的应用

1 云游戏中的资源管理

云游戏

概念： Server 端运行游戏，并将压缩的视频传给 Client；Client 只负责解压、显示视频

优点: 将 load 从客户端转移到 Cloud 端。显然用户就不用安装游戏，也不用很好的设备，普通的电脑就可以运行大型的游戏，从而实现

Gaming anywhere, anytime, on any device

挑战

完成高质量的游戏。比如，有的游戏玩家对游戏的反映时间和灵敏度有很高的要求，这一方面其实是很大的挑战。

延迟

双倍网络延迟 (Client - Server - Client)

有的游戏玩家对游戏的反映时间和灵敏度有很高的要求，使用时要把指令发送过去，再把指令传回来，同时还有视频压缩，这是一个很耗时的过程。

带宽

最低要求： 3~5 Mbps

传数值并不是一个小事情，如果传高质量的视频，最低要求是 3-5Mbps 的带宽。

成本

每台 server 同时只能运行几个游戏。

如果用户比较多的话，那么运营商就要提供很多的服务器。服务器的成本很高，包括它的运营成本维护成本等。云游戏收用户的钱可能还抵不过服务器的钱或者网络的钱。所以成本一直是云游戏里一个很大的挑战。

研究目标

优化成本

所有 server 的总运行时间最短

一般来说是用越少的服务器越好，也可以理解为，我们使用服务器的总运行时间最短。服务器的数量可能有的时候不太合理，如果这个机房有一万台服务器，它们可能不需要同时运行.如果这台服务器是空闲的，我们可以把它关掉或者是转化到一种低能耗的模式。所以我们的优化目标并不是单单的使所用的服务器数量最少，而是在满足用户条件的情况下使得所有服务器的运行时间最短。

请求调度

这里有一个假设，假设所有的服务器都是重构的，如果其他条件都没有变化的情况下，运行时间基本上是由请求调度算法来决定的。

Example

假如现在有三个请求，r1，r2，r3。它们是同时到来的，横轴表示时间，假设在 0 时刻三个请求都到了，r1 和 r3 的结束时间是 10 分钟，可以理解为玩游戏的时间停留在系统里的时间是 10 分钟。r2 很快就离开了，它的停留时间是 1 分钟，假如每台服务器只能服务两个请求，那么希望有 2 种策略。

左边是一种，把 r1 和 r2 放在一台服务器上，r3 另开一台服务器，那么如果要完成 3 个请求的话这 2 台服务器都要运行 10 分钟。总时间就是 20 分钟。

右边的策略是，把 r1 和 r3 放在一起，r2 单独放在一台服务器上，那么 r1 和 r3 需要运行 10 分钟，而 r2 在 1 分钟之后就可以把它调为低能耗的模式或者关掉它。

所以这个例子可以说明，采用不同的调度策略，服务器总的运行时间，某种程度上可以理解为总的成本，是有很大差别的。

问题定义

目标

如何调度游戏请求，使得总的 server 运行时间最少。

挑战

Online，请求到达后需马上做出决定

请求结束时间未知

运行中的游戏不能移动

相似问题

有一个和上面所讲的云游戏的请求调度问题非常相似的问题，叫动态装箱问题。

普通装箱问题： 我有一些请求，那么我希望用最少的箱子即最少的服务器，来装下这些请求。

动态装箱问题： 请求是有来的时间和结束的时间的。目标是，要有一个策略，使得整个过程中所用的顺时的服务器的最大的数量最小。

区别： 我们的问题是使所有服务器开着的时间总和最小。

比如，图上每个绿色的条代表一个服务器开着的时间段的话，我们的目标是使所有这些加起来最小。

研究工作

可以说它是动态装箱问题的一个变形。我们就要研究经典的装箱问题的算法在这个问题上的表现如何。我们的研究工作主要集中在三个方面。

• 一 经典算法

• 经典调度算法在云游戏请求调度上的表现

• 二 新算法

• 预测请求结束时间，优化请求调度算法

• 三 问题延伸

• 考虑游戏部署开销

下面简要介绍一下这三个部分

一、经典算法

Any Fit

只有当前正在运行的 server 都满负载时，才开一台新的。

First Fit

在所有有空闲的 server 中，选择最早开始运行的那台 server。

Best Fit

在所有有空闲的 server 中，选择空闲最少的那台 server。目标是尽量使满的 sever 更满。

经典算法主要研究两个部分。

Worst Case Ratio 分析

主要研究最坏情况下这几种算法是最优解的多少倍。

对于 1.3 版本之前的 Elasticsearch，fielddata cache 大小是没有限制的。 从 1.3 版本开始，Elasticsearch 添加了一个 fielddata 断路器，如果查询试图加载需要占用 60％以上堆栈内存的 fielddata，则会触发该断路器。

结论：通常情况下， Best Fit 和 First Fit 的平均性能是差不多的。在最坏情况下，First Fit 是有上界的，即 First Fit 在最坏情况下它不是很坏，但 Best Fit 在最坏情况下可以无限坏，没有上界。

Stochastic 分析

调度算法统计学上的平均性能。这里涉及到一些马尔可夫理论还有其他一些随机过程的理论。

二、新算法

游戏请求的 Daily Pattern

从早上七八点开始到 12 点左右请求一直是增加的。12 点过后请求开始下降。

黄色的线是一个最优解，代表需要的使用服务器数量的下界。还有一条红色的线和灰色的线，它们俩是重合的，代表 Best Fit 和 First Fit 算法，说明它俩的表现是一样的，在下坡阶段即图中的 0 点-7 点，比最优解还相差较多。可以得出结论：First Fit 和 Best Fit 在“下坡阶段”浪费大量服务器。

原因其实很简单。在上坡阶段，因为请求是不断地来的，不断开新的服务器，那么请求数量不断增加，每台服务器利用率就很高。在高峰比如 11 点，开了很多服务器，12 点开始这些游戏请求就走了，进入了下坡阶段。这时每台服务器都都不是很满，这样浪费的服务器就比较多。如果游戏请求可以来回不断地发，那么这个问题就很好解决了。主要的问题是不满的这些服务器，这些请求是不能汇总到一台服务器上的。

请求结束时间预测

核心：游戏玩家的游戏时间是否可预测的。

如果是可预测的，请求到来时就能知道它大概什么时候走。如果不可预测那么整个算法就不可行。

我们对一些游戏进行了试验。其中后两个 DotAlicious 和 WOT 是组队式的。每一场游戏里面都有两队，每队里有几个队员。前面 WoWAH 是个人游戏。图纵坐标表示的是预测的错误率。

错误率越小说明预测的越准确。这里可以看到，组队的游戏比如 DotAlicious 和 WOT，尤其是 WOT，预测的是非常准确的。也就是说每个游戏 section 的时间是非常固定的。基于这个结论我们提出了一个新的调度算法。

基于请求结束时间预测的调度算法

当请求到来时，把差不多同一时间结束的请求放在一台服务器上。比如 r1，r2 和 r3，这 3 个请求同时到来时，把 r1 和 r3 放在一起，因为预测 r1 和 r3 会差不多时间结束。

如图为 DotAlicious 游戏的结果。中间绿色的线表示用新的调度算法所用的服务器的数量，显然是在最优解和 Best Fit，First Fit 中间的，且更偏近最优解一些。

三、问题延伸

游戏部署开销

如果运行游戏的话服务器上肯定是要安装游戏的。有一个办法，就是一个数据中心所有的服务器共享，即把游戏都装在一个网络硬盘上，所有服务器需要它的时候通过网络访问它。但是这个办法被云游戏的公司证明是不可行的。

所以当前的云游戏公司采用的办法是每个服务器都自己装自己的游戏。这样就存在一个问题：每台服务器到底要装哪些游戏呢？

通常游戏的数量是很多的，比如 200 多个。如果每台服务器上都装了所有的游戏，那么开销是很大的。需要很大的硬盘，而且一个系统如果要装 200 多个游戏也不太可行。

那么如果不装 200 个游戏，而是每台服务器放一个游戏，这样会有一个问题：当一个游戏请求来的时候，一台服务器是空闲的但是它没有装所需要的游戏。这样可能就需要另外开一台服务器。那么同时需要的服务器数量就会增加。

如果规划目标是使开销最小，那么就需要一个合理的安装策略。

目标：如何部署游戏使得总开销最小

简化：服务器所安装的游戏是不交叉的。即同一类服务器只安装比如 A,B,C 这三个游戏，另外一些服务器装 D 和 E 这两个游戏，它们之间没有交叉，这个问题就变简单了。

分析

Stochastic, Markov models

算法

Simple Algorithms

Dynamic Programming Algorithms

Heuristic Algorith

总结

本期介绍了云游戏中的资源管理：

• 云游戏概念

• 挑战

• 研究目标

• 问题定义

• 相似问题

• 研究工作

下期我们将继续介绍剩下的两部分：

1.搜索引擎中的资源管理

2.AI 在资源管理中的应用

本文转载自公众号 360 云计算（ID：hulktalk）。

原文链接：

https://mp.weixin.qq.com/s/fXfnuP1Bq11OPcT_EWE7vw