云计算时代IT资源扩容的思考

利用率达到多少的时候就应该扩容？

近期，我和周围的同事在多个项目中，经常被计划部门或业务部门同事问到的一个问题就是：某某业务系统的服务器、存储资源，乃至整个私有云资源池，利用率达到多少的时候就应该扩容？
这个问题，真不是一两句话能说清楚的。首先，确保业务可用与提升资源利用率这两个出发点就不同；其次，不同的业务系统，难以有“一刀切”的结论；再次，我们很多业务系统都缺乏全面的资源利用率监控数据，很难为分析判断提供技术依据。
不过在这些讨论过程中，我自己逐步意识到：与决定IT资源是否扩容关系最大的，也许并不是你的资源利用率，而是你的扩容速度。

资源扩容是云计算时代的新课题

在运营商传统的通信网络建设中，一套设备或系统的性能或容量，通常相对比较明确。在规划建设阶段根据用户数、话务量等指标估算建设规模，上线后基于网管系统监测忙时利用率，达到一定阈值（例如70%）即启动新一轮扩容。这种建设模式确保了系统的安全运行，在长期的实践中特别是通信业务快速增长的背景下，是被广泛接受的行之有效的手段。
在后来的IT支撑系统建设中，这种模式也被继续沿用。其实许多计划或业务部门的同事其实已经意识到，IT系统合理性能需求估算和容量规划，并没有通信网络那么简单明了。为了尽力确保资源满足业务需求，笔者见过不少估算资源的过程中乘以1.3、再除以0.7之类的冗余算法，甚至还有x86服务器CPU利用率超过50%性能就会不稳定等说法。不过同样因为业务增长快、IT投资盘子总体太小，这种相对粗放式的扩容方式也没有太大问题。
但到了云计算时代，情况不太一样了。一则业务的多样性、技术的演进等都比以前要显著；二则云平台的建设运营部门与业务需求部门有不同的关注点，前者更重视利用率等指标，后者对业务的稳定性更为关注；三则提升资源利用率、降低成本本身也被认为是云平台建设的目标，还有Google、Amazon等互联网公司超高的资源利用率传说作为标杆。因此，IT资源扩容的矛盾、以及合理的判断依据等问题，随着公司内部私有云的建设、运营，必然作为一个新的课题浮现出来。

资源利用率并不直接决定扩容

IT资源或者说云平台是为上层业务服务的，需要满足业务的性能要求。在业务负载（访问量、处理量等）最高的时候，IT资源需要能够提供足够的处理能力，确保相关业务指标（时延、并发用户数等）达到预定要求。如果资源不能或者预计不能满足业务要求，就说明需要扩容了。
从IT资源角度看业务负载的高低，最直接的指标就是资源利用率，如CPU利用率、带宽利用率等等。与高业务负载对应的就是业务的峰值资源利用率，其理论最大值是100%。那么，当前峰值利用率的高低，是不是就是判断是否需要扩容的直接依据呢？其实不是的，下面就是两个反例：
1）当前峰值利用率高不等于一定需要扩容

当前峰值利用率高不等于一定需要扩容。有些业务是离线批处理类型的，在按照预定计划启动批处理任务的时候，其CPU利用率可能接近100%。但是，如果系统完成批处理任务的时间，能够完全满足业务指标要求，就不需要扩容。例如，下图蓝色线条的某业务系统就是属于这种情况：

2）当前峰值利用率低不等于一定不需要扩容
当前峰值利用率低不等于一定不需要扩容。 与离线业务不同，在线业务对并发访问数、响应时延等业务指标要求较高，需要更仔细规划资源来满足峰值的业务需求。试想一下，社交平台上的特殊时间、淘宝“双11”、微信春节“红包”的业务负载可能是平时的数倍甚至数十倍，所以就算阿里在每年“双11”之前的峰值利用率只有20%，面对连年刷高的销售额目标，基础设施部门敢不扩容？

以上两个反例并不少见，我们还能说，根据峰值利用率是否达到一个阈值就确定是否启动扩容吗？这里的核心不在于这个阈值是40%、70%还是90%，而是这个方法本身就有问题。

决定扩容的核心因素

既然峰值利用率仅仅是一个参考指标，不是扩容的决定因素，那是否扩容到底有什么决定呢？答案应该就是：看业务是否真正受到（或可能受到）影响。
笔者在一次交流过专门请教过为“双11”准备扩容服务器的阿里同事，类似这种扩容，总结起来主要有以下两个核心因素：
尽量准确预测你的下一次业务高峰。业务部门需要预测它出现的时间、需要满足的业务量，相对当前资源最高处理能力的增加幅度等等；
明确满足下一次业务高峰所需要的准备时间。为了应对新的业务需求，技术部门需要有一个协同、全盘的考虑：是否启用新的硬件平台技术？是否对原有软件进行大幅升级？硬件的测试、采购、到货、部署时间，软件的开发、测试、上线部署时间，以及其它可能的技术或非技术因素所消耗的时间。
如果这两个核心因素搞清楚了，扩容就成为自然而然的事情了：以在某一个时间点需要满足的某一个业务需求为目标，倒排工作计划并完成它。当然要明确这两点并不是单一的一个云的运营部门能够搞定的，需要与业务部门详细沟通业务发展预期、优化目前现有的建设采购模式等，这正体现了做云的运营所需要的整体协调性和与业务贴近性。
在这里，你当前的资源峰值利用率是20%还是50%都不重要，是确保业务不受影响的目标决定了你的扩容动作。
所以为什么总是在“双11”之前即使加班加点也要完成扩容，因为一旦过了这一峰值，业务量甚至回落到你扩容前资源就能满足的规模，没有按期完成的扩容就失去了意义。

扩容越快也许你的利用率越高

那么，有没有既能确保满足业务需求，又尽量提高资源利用率的方法呢？其实是有的，那就是尽量加快你的扩容速度。

如图是一个典型的例子。因为扩容是为了满足业务预期的需求，实际上就形成了一个阶梯状的资源分布。扩容时间越长，意味着阶梯的每一级越大，与实际业务需求之间的差距也越大，导致资源利用率长期出于低水平。如果缩短扩容时间，一个个小阶梯就更加贴近实际的业务需求，资源利用率也就自然提高了。
这种扩容时间的变化，反过来对于业务的影响实际上是巨大的。试想一下，我们为什么不在家放大量的现金以备不时之需？原因很简单，我们如果需要，可以随时到银行去取、甚至有24小时自助银行。
如果一次扩容需要一年甚至更长时间，面对业务发展的不确定性，任何业务部门都会倾向于早扩容、多扩容。换言之，如果有足够的资源明天就能到位，今天的业务峰值利用率就算用到99%又有何不可呢？
当然，上图只是业务持续增长的情况，对于实际大多数业务的波动情况，与“扩容”相对的就是“缩容”了，但道理是一致的。那业务“缩容”后的资源去了哪里呢？可以用于其它业务，或者作为资源直接销售给你的客户。这就是为什么自有业务使用大量服务器的公司做公有云有优势、以及为什么国内云服务商通常在12月份促销云主机的原因之一吧。

如何缩短扩容时间？

首先是资源集中和池化

云计算将原来业务独占的资源变成共享的池化资源。传统上业务可能觉得把资源抓在自己手上更为放心，但其实不然，因为池化资源能够提供更大的弹性空间，对每个业务更为有利。
对此，我们常举的一个例子就是，假设每个业务实际有100台服务器需求，预估资源时会各自预留30%的备用，最终也仅仅有30台可用；如果资源池有1000台服务器，考虑总体预留10%的资源备用，那么给每个业务可能最多有100台额外可用资源。前者利用率低、承担业务冲击能力差，后者的优势不言自明。
池化不仅是建设问题，更是运营问题，需要从之前的“集中建设”向“统一运营”方向转变。资源不再属于任何一个业务，而应该由专门的部门或技术团队来负责管理，分配和回收并行，以减轻不同业务资源“多寡不均”的问题。

其次是提高资源动态分配和调度的能力

资源集中和池化后，资源平台需要能够提供资源动态分配和调度的能力。这也就是为什么云平台倾向于采用虚拟化、容器等虚拟资源管理技术，为什么推动业务做软硬件解耦、做云化或微服务化改造，为什么推自动化部署甚至在线/离线业务混布等等，核心都是为了让资源池中的资源能够尽量快速、灵活的被各类业务所使用。

再次是合理的资源预留

为了防范可能出现业务量突增的未知风险，资源池应该长期保留一定量的资源预留，并预留紧急扩容预案。如前面所说，因为池化的资源规模足够大，预留资源的比例相对可以减少。
例如，国内某互联网公司大约在全网预留服务器总量的约1%作为机动资源，并且与服务器供应商签约，要求能够随时满足在数日内增加一定量供货的要求。这有点类似于数据中心柴油发电机的做法：数据中心会预留少量的油，但会与加油站签约，8小时内保证送油到场。

最后是采购和建设周期

在之前与某互联网公司交流中，对方说他们目前的服务器采购，已经从之前相对固定的例如半年一次，调整为按需随时启动采购，这也是提高灵活性的措施之一。业务的发展有其自身的时间要求，无论是IT设备集采、或者建设项目，如果错过了这拨再等一年，那业务部门也只能选择早报、多报新建或者扩容资源需求。

总结

我公司IT系统目前仍然非常分散，业务发展很快，资源规模扩张迅速但整体资源利用率低下，希望通过统一的资源利用率指标等要求，来指导资源的扩容的做法可以作为权宜之计，但应该考虑调整优化。因为决定扩容的主要依据往往不是当前的资源利用率，而是业务预期与扩容速度。
云计算的核心目标就是提升IT系统的灵活性，为上层动态按需的提供资源。真正按照云计算模式重构我们的IT系统，有效缩短业务的扩容时间，寻找满足业务需求与提升资源利用率的最佳平衡，或许是破解扩容难题的一种方法。
现在，我们的基础网络业务也开始向IT化、云化方向发展。在新的云化时代，无论是管理还是技术都需要因时而动，构建面向未来的随需应变的灵活的IT技术与管理架构。

文章作者：唐华斌