一、背景随着互联网的兴起，许多企业都经历了互联网的野蛮成长。但在互联网市场逐渐成熟稳定后，各大企业业务增长速度逐渐放缓，也开始“向内挖掘成本”，以期更精细地控制成本，提升竞争力。的企业。力量。尤其是随着“互联网寒冬”的来临，“冷气”传到了各行各业，“降本增效”的概念也被再次提起。有停电，扣费和细节；也有全线大规模裁员，淘汰部分业务，减少人手；有的团队直接组建横向团队，用顶层思维，在不影响团队运作的情况下，聚焦核心成本。保证降本效果的技术难题。本文将结合笔者在CDN带宽利用率优化方面的实践，与大家分享我们的降本思路和实践方法。作为一个持续的创新方向，“降本增效”并不局限于某个部门，企业价值链上的任何一个环节都可能成为突破点。作为技术开发人员，我们需要“从所负责的业务方向出发”，以企业成本为切入点进行业务分析和挖掘，从技术角度出发，进行技术突破，深入探索，降低成本。费用。提高效率，为公司带来真正的价值。通过这篇文章，你可以：1）打开思路，为“降本增效”提供可能的思考方向，帮助大家探索轻量化但高价值的目标。2）一目了然的了解我们CDN带宽利用率优化的核心方法。名词解释：【CDN】内容分发网络。本文中的CDN专指静态CDN。动态CDN主要是对路由节点进行加速，带宽开销比较小。通俗解释：CDN厂商在各个地方部署了很多节点来缓存你的资源。用户下载时，CDN网络帮助用户找到最近的节点，用户通过该节点的下载速度大大提高。【CDN带宽利用率】带宽利用率=实际带宽/计费带宽，可以理解为投入产出比一样性质的东西。为什么要提高利用率？比如：你不愿意花1亿去买1000万的东西。如果你的利用率只有10%，你居然做了这么不合逻辑的事情。【愚公平台】通过带宽预测和削峰填谷，大幅提升企业整体CDN带宽利用率的平台。2、“寻寻觅觅”寻求降本作为CDN的大用户，笔者有幸见证并参与了我司在CDN带宽成本成倍增长的情况下，从最初阶段基于各自业务的CDN带宽利用率的优化是基于带宽可控调控的思想。本章我们来聊聊我们CDN降本的几个重要阶段，和大家分享一下我为什么选择CDN带宽利用方向进行研究？2.1CDN带宽计费方式首先要说一下我们的计费方式，峰值平均计费：每天取最高值，每月取每日最高值的平均值作为计费带宽。Monthlybilling=Avg(dailypeakvalue)这种计费方式的意思是：日峰值越低，费用越低。带宽利用率决定成本。因此，我们从未放弃对带宽利用率的追求。让我们来看看我们在优化带宽利用率方面的经验。2.2CDN降本三部曲我们的CDN降本优化主要分为三个阶段。三个阶段各有妙用，在当时的情况下，都取得了不错的效果。而且都是根据当时的情况摸索出来的比较合理的优化方向。2.1.1本地优化本地优化是基于我们公司主要CDN使用的思路。作为手机厂商，我们静态CDN使用场景的核心业务是应用分发，比如：应用商店应用分发、游戏中心应用分发、版本自升级分发。综上所述，六大核心业务占据了我们公司90%以上的带宽。只要提高这六大业务的带宽利用率，我们的带宽利用率就可以得到显着的提升。基于这样的情况，CDN运维人员往往会找到核心业务，给出一个带宽利用率的指标，让各个业务提高带宽利用率。总结一下，核心思想就是：找到核心CDN用户，为他们设定自己的使用指标，提出需求任务，明确说明优化的价值。经过这一阶段的优化，我们核心业务的带宽突发场景已经关闭，整体带宽利用率得到了显着提升。2.1.2全局优化由于局部优化是对单个服务的优化，大量尖峰问题解决后，每个服务的带宽利用优化都会进入一个瓶颈区域。其中，效果比较好，单项服务的带宽利用率很难超过60%，除非是特殊的服务形态，完全控制带宽。这时候我们业务抽取部分带宽来调节公司整体带宽，进一步提高公司整体带宽利用率。我们将其定义为全局优化阶段。基于这样的全局优化思路，只要每个业务不出现大的秒杀，整体的带宽利用率就会有很大的提升。首先，我们对带宽进行划分，将服务器可以控制的部分带宽提取出来，拆分成可控带宽，主要是工信部许可的WLAN下载带宽；然后，我们观察带宽的趋势，根据带宽的历史趋势分离出各个时间段的带宽。带宽数据，针对不同时间段控制不同的带宽量级和增量，最终达到“削峰填谷”的目的。该策略控制通过阈值缩放的速度。每小时设置一个阈值，按照每小时的阈值生成每秒令牌数，以控制令牌桶的容量。2.1.3自动化控制整体优化后，作为技术开发者，更进一步的方法是用程序代替人工，将音量控制向更精细化控制的方向发展。基于这样的想法，作者开始探索机器学习中的预测技术，想象如果有规律和特征，就有一定的预测可能性。与股票不同，虽然影响CDN带宽的因素很多，但影响最大的因素是显而易见的。所以我们分析这些因素，先归因，然后提取特征和特征分解，预测阈值，预测每个点的带宽值。最终克服了这个预测问题，通过预测技术调整了CDN带宽的峰谷问题。2.3降本思想的由来谈到降本增效，作为技术的发展，首先想到的就是用技术来代替人工，用程序来提高大家的工作效率。比如：自动化测试、自动化抽查、自动化监控分类告警等，无论哪个团队都不在少数。甚至提高大家编码效率的自动化代码生成器也已经孵化出一大批平台。接下来分析一下我们降本增效的主要思路。笔者主要负责的技术模块为应用分发，涉及的成本方向为：CDN带宽成本、存储成本、主机成本。与CDN的巨大成本、存储成本、主机成本相比，少量业务的体量是微不足道的。目前来看，最适合我们的方向是在CDN成本方向突破。CDN成本方向有两个细分方向：减少带宽量和提高带宽利用率。简介：减少带宽量非常复杂。从目前的情况来看，如果能够对带宽进行自动预测和自动控制，可以大大提高带宽利用率，达到明显的降本效果。而且，企业CDN费用越高，降本收益越大。3、经过“脚踏实地”的预测和确定目标后，话题初步在“个人OKR目标”中缓慢推进。本章，笔者将和大家谈谈我们对“预测方向”的主要探索思路。3.1带宽预测探索我们的探索期主要分为两个阶段。前期主要围绕：观察→分析→建模，类似于特征分析阶段；后期主要进行算法仿真→算法验证，选择效果比较满意的算法，继续深入分析探索，深入挖掘价值，研究算法的最终突破口。可能性。3.1.1观察规律如图为我司三大项目今年7月1日-7月31日的带宽趋势图（数据已脱敏）：可以观察到一些明显的规律：3.1.2原因分析我们带宽会走出这样的趋势，与其影响因素有关，下面列举一些“明显”的影响因素。3.1.3模型分裂了解带宽成因后，我们的主要研究方向有：机器学习、残差分析、时间序列拟合等方向。然而，最终适合我们的预测模型是：阈值时间序列预测，带宽实时预测模型。从最初的探索到最终成型，我们的模型探索也经历了多次转向，逐渐走向成熟。3.2算法关键【近期数据】CDN厂商虽然不能提供实时的带宽数据，但是可以提供一段时间之前的数据，比如15分钟前的带宽数据，我们简称为近期数据。我们在近期带宽数据的基础上，尝试结合延迟数据与历史数据之间的关系，将其纳入模型，自主研发算法（主要周期单位为周）进行实时预测。下图（数据脱敏）是结合最新数据后的一周预测拟合。此外，与残差学习对突变点的敏感性不同，我们的模型预测主要问题在于带宽转折点。只要妥善处理转折点的带宽模型，就可以保证算法效果。我们自研算法的核心思想：算法注意事项：4.像愚公一样“兢兢业业”假设你已经能够比较准确地预测带宽（标准是：在特殊突变点之外，方差为5%以内），那么你真的要投入生产其实还有很多细节要做，在模型优化或者技术处理上可能会遇到一些问题。接下来主要说一下我们的《愚公平台》系列从预测到量控的解决方案，并且针对实施中的实际问题做了一些说明，让大家少走弯路。4.1我们的落地方案总的来说，我们方案的最终目标是降低成本，而降低成本的思路是基于计费模型。我一句话概括了我们的方案，如下图，预测蓝线，控制阴影区域，最后把蓝线压低，也就是我们的计费带宽，从而达到如图所示的降本效果数字。4.2愚公平台的实践思路如下图所示。愚公平台的核心思想可以概括为：利用离线模型预测明天的阈值，利用自研模型，实时预测未来的带宽值，结合阈值和预测值，并计算出控制量将受控量写入令牌桶，每秒产生令牌供端侧消费。4.2.1使用Prophet预测阈值首先是阈值预测。在之前的带宽预测的基础上，我也研究了prophet预测，所以最终选择它作为阈值。预测的核心算法。它的时间序列特性和突变点的识别很适合我们的场景，最终的效果也很好。如下图（数据已经脱敏）所示，除了少数特殊的爆点，大部分阈值点基本都在预测范围内。最后，阈值预测本身就是一个时间序列预测模型。网上有很多类似的选择方案。我们使用prophet来预测阈值，我们还设计了一个阈值自适应模型来自动扩展带宽阈值，可以在一定程度上降低阈值。偏差风险。所以，我们使用的阈值一般都是音量阈值，结合它的适应性特点和一些干预手段，可以极大的保证我们的调节效果。4.2.2使用自研算法预测带宽这部分在预测部分已经详细介绍，这里不再赘述。一般来说，还是用最近的带宽，结合历史趋势，来拟合未来一段时间的带宽趋势，从而预测未来短期的带宽趋势。4.2.3子模型解决控制问题。这里主要是为了预测数据和控制数据之间的转换，做一些细化处理。关注突发、边界、转换、干预等问题，需要结合实际业务情况进行分析和应对。4.2.4流控SDK问题研究发现很多业务可能带宽可控。基于此，我们统一了一个流控SDK。将更多的带宽纳入管控，控制的带宽量越大，效果越好。这里SDK的本质还是令牌桶技术。通过这个SDK可以实现对所有带宽的统一控制，可以大大减少各种业务处理带宽问题的麻烦。4.3精细化控制能力的阈值预测后，最终控制量之间存在较大的换算关系，可能需要进一步思考和优化，以大幅提高带宽利用率。本节给出了我们遇到的挑战的例子，一些我们流量控制问题的例子，以及一些分解解释。4.3.1多CDN数据源问题一般公司会接入多个CDN，每个CDN分配一定的层级。有些CDN不提供拉取最新数据的能力，或者频率限制太严，拉取数据困难。我们的解决方案：找一家配比比较可以接受，数据拉取也比较配合的厂商，利用他们的数据和配比来扭转公司的总带宽，减少对其他CDN厂商的依赖。注：由于公司业务较多，小企业不支持多CDN配比控制能力，会造成该配比波动。如果波动太大，控制就会失真，你的利用率就会受损。4.3.2当带宽控制不允许因大小文件限流时，一般只能控制开始下载，但一旦开始下载，不知道什么时候下载完成。对于小文件，下载时间更短，控制精度更高。（常见的小文件，小资源分发等）大文件，比如系统升级包，3G包，下载可能需要一个多小时，控制下载开始会有问题。下载时间造成的长尾会让你绝望。我们的解决思路：思路一：对于这种对流量时效性要求不高的超大文件，将其拆分成粗略的控制模型（可以理解为全局控制的一套思路）。使用小文件进行精确控制。PrecisionControl使用预测模型来进一步补充整体带宽。思路二：拆分一个大文件的下载，假设分成100M，每次下载100M请求流控服务器。这里复杂度高，依赖客户端的修改，算是一种思路。4.3.3流量转化问题其实是流量长尾造成的。每秒可以下载100个文件，每个文件100MB，所以带宽是10000MB/s。其实因为下载是连续的，这一秒并没有下载完成，只是实际流量没有那么多。我们的解决方案：有一个流量换算系数，就是你控制3Gbps，但实际上满载后只有2Gbps，这里需要你手动设置一个换算系数，方便更精准的流量控制。注意：这个换算系数会因为包体大小的波动而导致你的利用率受到影响。4.3.4边界长尾问题一般边界在清晨时，每天计费一次。但是昨天23:59，大家的带宽往往被低估了。如果你控制了很多带宽（假设你控制了大量的10Tbps，因为昨天爆发了），而流量恰好足够，这个流量可能是由于长尾问题。直到今天00:01才完成。由于流量太大，今天的计费带宽在凌晨形成了一个巨大的峰值。我们的解决方案：对边界点之前的一些点进行特殊控制。例如：23:50~23:59，使用明天的峰值进行音量控制。4.3.5突发响应问题这主要是指模型识别的突发。例如，数据显示20分钟前带宽急剧增加。根据模型，其实可以根据这个burst判断出当前的bandwidth处于高位，而且因为趋势的问题，bandwidth预示着一个更高的值。我们的解决方案：根据总增长值（或增长值占比），或增长率（或增长率占比），或最大增长步长（每分钟增长最大的数据）认为是判断突发事件的方法，采取应急预案。也有人发现，如上所述，有些突发事件是无法预测的。我们如何处理它们以减少损失？①阈值空间是为小突发预留的。例如，预测目标阈值是2T，可以设置1.8T作为阈值。这样即使有短的突发，带宽突发到2T也在我们的目标范围之内。预留的0.2T是我们给自己留的退路，我们的目标永远不是100%的带宽利用率。这部分预留是我们不得不牺牲的带宽利用率。此外，当带宽达到较高的峰值时，应合理配置预留值。②大突发集合统一接入如何定义大突发？一些业务，如游戏发布、微信发布等，涉及范围大、用户面广。只要版本一出，必然会引起大爆。这种只能由大服务引起的大带宽突变是大爆发。如果突然的趋势不是很快，可以尝试控制速度来压制这个趋势（其实我们在第一阶段优化带宽利用率方面已经做得很好了）。如果它变成缓慢的爆发，我们的模型可以识别趋势并很好地处理它。到目前为止，大爆发不是问题。反之，对于压制不住的大爆发，突然增加300多G，突然捂耳朵，模型来不及调整。我们建议将类似行为直接接入控制系统，让控制系统提前挖坑进行处理。③在容易爆的段，少加点带宽，牺牲一些带宽来防御某些时间段，比如晚高峰，容易爆，这个也好，那个也好，意外的爆总是会的发生。建议直接调低阈值，原来阈值是2T，直接把压力控制到1.5T一段时间。这个0.5T就是系统的保障。毕竟只挖了一个时间段，其他时间段把被堵的流量放掉。整体效果还是不错的。4.3.6突然下降或不下降的问题根据模型预测的突然下降（由历史规律引起），可以知道此时带宽的趋势是下降，并且有一些规律性下降的减少数据。然而，实际下降幅度可能并没有那么大，最终新的峰值可能是由监管问题引起的。基于这个问题，我们的解决思路是定义倾角场景和倾角识别规则，对倾角点进行特殊标记，处理倾角带宽的重载策略，避免引入新的峰值。4.3.7手动干预处理一些特殊场景，比如大型软件，预计量级会非常大，或者大型游戏预约（比如：王者荣耀）更新。这部分可以提前知道突发。我们的解决方案：提供突发SDK接入能力和后台输入能力。针对一些容易突发事件的业务，提供突发事件上报SDK，提前上报数据，方便模型应对突发事件。例如：根据带宽量和历史突发场景的规律，模拟和模拟突发峰值。在突发期间，阈值降低；在爆发之前，阈值被提高了。4.3.8特殊模式：Weekend&HolidayMode假期不同于平时的带宽趋势，会有几个明显的规律：大家不上班，可控带宽明显少，突点向早高峰转移.节假日单独建模，分析节假日带宽趋势。4.3.9阈值自适应调整问题如果阈值保持不变，在一个burst之后使用之前的阈值会造成大量的带宽浪费。我们的解决方案：设计一个阈值增长模型。如果池外峰值带宽超过阈值，或者总带宽超过阈值一定比例，则考虑扩大阈值。4.3.10带宽权重问题在CDN竞争激烈的时代，由于用户习惯，白天使用带宽较多，晚上使用带宽较少。所以有些CDN厂商支持分段计费方案，也就是说我们可以在某个时间段使用更多的带宽，而在某个时间段使用更少的带宽。我们的解决方案：本方案基于分段计费，因此需要设置不同时间段的带宽权重，以保证带宽模型的平稳运行。当然，分割后会出现新的边界问题，需要重新处理。4.4技术问题本节根据我们使用的技术，说明您最有可能遇到的技术问题。4.4.1热点key问题由于接入方众多，下载流量限制巨大，每秒可能上百万次，这里肯定有问题，就是热点key问题。我们通过slot和node之间的分布关系来确定keyprefix（可以从DBA那里得到），每个request随机分配给某个keyprefix，从而随机分配给某个node。这样就把流量平均分配到各个redis节点上，减轻了各个节点的压力。下面是我们的流控SDK，LUA脚本参考：//CDN流量初始化和扣费的LUA脚本//KEY1扣费key//KEY2流量控制平台计算值key//ARGV1节点数30整形//ARGV2流控bottomvalueMB/len并提前划分（防止平台计算延迟或异常，设置一个bottomvalue），shaping//ARGV3本应用的流量（统一单位MB，不是Mb）Shaping//ARGV4ValidityshapingpublicstaticfinalStringInitAndDecrCdnFlowLUA="localflow=redis.call('get',KEYS[1])"+//优先级取自控制值，如果不是则使用底值"ifnotflowthen"+"localctrl=redis.call('get',KEYS[2])"+"ifnotctrlthen"+//底线"flow=ARGV[2]"+"else"+"localctrlInt=tonumber(ctrl)*1024"+//节点数"localnodes=tonumber(ARGV[1])"+"flow=tostring(math.floor(ctrlInt/nodes))"+"end"+"end"+//取值在游泳池“地点lcurrent=tonumber(flow)"+//扣除值"localdecr=tonumber(ARGV[3])"+//池中没有流量，返回扣除失败"ifcurrent<=0then"+"return'-1'"+"end"+//计算剩余"localremaining=0"+"ifcurrent>decrthen"+"remaining=current-decr"+"end"+//executeupdate"redis.call('setex',KEYS[1],ARGV[4],remaining)"+"returnflow";4.4.2虽然本地缓存解决了hotkeys的问题，但是当真正的流控为0时（比如连续1小时为0），仍然会出现大量请求，尤其是客户端重试机制导致请求更频繁的时候，这些请求都会一点点走LUA，所以我们需要设计一个缓存，告诉你这一秒流控平台上没有流量，从而降低并发。我们的方案：使用内存缓存，当所有节点都没有流量时，设置一个指定秒的本地缓存key，可以过滤本地缓存key，大大降低redis的访问级别。当然，除此之外对此，还存在流量平衡的问题。客户端1分钟内流量表现是：前10s流量很多，触发限流，后50s没有流量。对于此类问题，我们的服务器没有很好的解决方案。可能需要在端侧寻找解决方案，但是端端很多，推上去也不容易。4.5最终效果为去权后的带宽趋势。从图中可以看出，使用《愚公平台》调节带宽可以显着提高CDN带宽利用率。实践历程：结合业务，选择了CDN降本方向作为技术研究方向。观察规律，我选择了Prophet作为离线阈值预测算法。算法突破，自研拟合算法作为实时预测算法。不断思考，思考对模型中问题的反应和不断优化的解决方案。最终，从技术角度来看，将为企业创造巨大的成本降低效益。
