滴滴内部线上系统的容量评估方法

发布于:2019 年 12 月 9 日 09:30

滴滴内部线上系统的容量评估方法

1. 背景

以滴滴内部某业务为例,从 BI 监控、流量晚的流量高峰、夜间的流量低谷。但把周期拉长,可以看到业务单量及服务流量的增加趋势。

滴滴内部线上系统的容量评估方法

滴滴内部线上系统的容量评估方法

对应该服务的资源使用,比如 CPU Idle,长期看则有一定的下降趋势。

滴滴内部线上系统的容量评估方法

基于此,我们能否从中找到规律,回答几个重要的问题:

  • 随着业务单量增长,该服务的流量也会增加,峰值会是多少?
  • 随着该服务的流量增加,该服务消耗更多的资源,容量上限是多少?
  • 以及终极问题:随着业务单量增长,该服务是否需要扩容,扩容多少?

2. 容量预估的思路

懵懂中有这样的猜想,服务的流量应该取决于业务单量。所以换个角度考虑,把上面三幅图的横坐标改为业务单量,纵坐标改为服务流量。如果关系成立,预测流量增长自然不难。

滴滴内部线上系统的容量评估方法

不出意外,资源使用率(如 CPU Idle)应该取决于服务流量。如果关系成立,评估容量上限也会迎刃而解。

滴滴内部线上系统的容量评估方法

想法是否成立,我们快速验证一下,采集了 5 个线上服务,生成服务流量与业务单量的关系图,结果显示,有 3 个服务存在较强的关系:

滴滴内部线上系统的容量评估方法

接下来是资源使用率与服务流量,采集了多个资源使用率指标,比如内存、CPU Idle、磁盘 IO 等,结果显示,应用类服务的 CPU Idle 与流量存在较强的关系

滴滴内部线上系统的容量评估方法

3. 容量预估的方案

评估容量上限

流量高峰时,如果某个服务的主要资源指标下降到一定程度,我们会觉得其容量到了上限。前面分析验证过,应用类的服务大多数是 CPU 类型,CPU 使用率或者 CPU Idle 是主要的资源指标。有一定的理由相信,如果 CPU Idle 下降到基线标准,我们可以说该服务的容量达到了上限。

但基线标准如何定义?在达到特定的容量时,该服务的错误率有明显提升、或者时延 SLA 不达标、或者突然 Crash,这就是一个经过验证、令人信服的基线值。

在没有验证的基线之前,我们可以依赖历史经验,比如这里取 CPU Idle 40% 作为基线值。

滴滴内部线上系统的容量评估方法

从图中可以看出,服务的 CPU Idle 与流量有较强的相关性,给出性能基线后,很容易评估其容量上限。

预测服务流量

很多时候业务上对增长有较明确的预期,比如半年之内单量增加 50%,即使一些促销的运营类活动,也应该对业务增长有粗略的估算,这样底层的 IT 系统可以更好应对。

这些业务增长的预期,会直接转化为内部各服务的流量,前面已经分析和验证过二者的关系,因此服务的流量也是可以预测的。

下面的左图非常典型,流量与单量强相关。右图则不然,呈现出两个不同的阶段。其实这种情况不难理解,某些服务的流量不只受单量影响,还受制于司机数量,即使单量增加,但司机不够,很多订单分不出去,相关服务的流量必然不会一直增长。所以需要综合考虑服务流量与业务单量、司机在线数等多个因素的关系。

滴滴内部线上系统的容量评估方法

算法说明

持续采集线上数据,经过预处理、格式转换,可以用来做预测。多次训练和验证对比,并使用节假日时的高峰流量二次验证,为不同的服务选择不同的算法。

滴滴内部线上系统的容量评估方法

最后,由于关系图上的点有一定的离散度,引入 bootstrap 95% 置信区间算法,给出的预测结果是一个范围,而非具体的一个数值。

4. 预测结果的准确度

不难理解,大家会有很多疑问:

  • 预测准不准,怎么证明?
  • 按 CPU Idle 40% 进行计算,会不会出现 CPU Idle 60% 或者 50% 时服务突然 Crash?

滴滴内部线上系统的容量评估方法

当某个服务的流量继续增加,CPU Idle 持续降低,我们与哨兵压测合作,让该服务单台机器的流量增加,并采集资源类数据,如下图所示。肉眼看起来,基本符合预测的关系,并进行了量化计算,预测的准确度大概是 89%。

滴滴内部线上系统的容量评估方法

至于是否会 Crash,起码从哨兵压测 CPU Idle 降到 40% 的情况下,这两个模块未发生突然 Crash。这当然避免不了流量继续增加是否会 Crash,但我们在选择性能基线的时候可以更保守一些。容量的预估只需要采集相关的业务指标、流量数据、资源数据,几乎不需要服务侧做任何改动,仅此接入的成本较低。

5. 案例分析

容量的预估只需要采集相关的业务指标、流量数据、资源数据,几乎不需要服务侧做任何改动,仅此接入的成本较低。

案例一

以某服务为例,集群共有 10 台机器,当前的峰值流量 1000QPS(非线上实际数值,仅为示例用途,下同),两个主要的关系图如下:

滴滴内部线上系统的容量评估方法

经过计算,该服务的结果如下:

  • 若不扩容,该服务的容量上限预测结果为:【1500-1700】
  • 单量增加 30%、司机增加 10% 时,该服务的流量峰值是:【2000-2200】
  • 按悲观估算,容量取下限 1500,峰值流量取上限 2200,则该服务需要扩容 4~5 台

案例二

以另一个服务为例,集群共 5 个容器,当前的峰值流量是 250QPS。

滴滴内部线上系统的容量评估方法

经过计算,该服务的结果如下:

  • 若不扩容,该服务的容量上限预测结果为:【1100-1200】
  • 单量增加 30%、司机增加 10% 时,该服务的流量峰值是:【450-500】
  • 按悲观估算,容量取下限 1100,峰值流量取上限 500,则该服务需要缩容 2 台

案例三

从业务角度,可以看到各核心服务的容量上限、流量增长趋势,以及建议的扩容结果:

滴滴内部线上系统的容量评估方法

6. 局限性说明

线上业务面临各种各样的稳定性挑战,这种常规场景下的容量预估方法,当然也有其局限性:

性能基线如何选择

使用 CPU Idle 作为基线指标,源于本文对少量数据集的验证结果,大部分应用类服务是 CPU 资源型。

使用 CPU Idle 40% 作为基线值,则是源于经验。在 40% 之前服务是否存在性能拐点,是否会发生 crash,则需要结合全链路压测、哨兵压测等其他机制验证。

对下游时延增加等性能抖动的容错

一旦下游服务或基础组件发生性能抖动,比如时延增加、错误率增加,对很多服务会产生致命的影响,甚至引发雪崩。

服务可以容错多大的性能抖动,可以结合防火等手段进一步验证。因此本文的容量预估结果,更多是对服务容量的一个参考。

作者介绍

张晓庆

滴滴 | 高级算法专家

本文转载自公众号滴滴技术(ID:didi_tech)。

原文链接

https://mp.weixin.qq.com/s?__biz=MzI1NDA3NzY4NA==&mid=2247485991&idx=2&sn=b05f02468e54fd0661cbf86299f77084&chksm=e9cbf5bcdebc7caa9b69dbbbeb6de6ba163a3553c7c5a4b23b96e5e6dd02b38c3a6f7f95abee&scene=27#wechat_redirect

阅读数:2375 发布于:2019 年 12 月 9 日 09:30

更多 新基建、技术管理、运维 相关课程,可下载【 极客时间 】App 免费领取 >

评论

发布
暂无评论