AutoScaling-成本优化模式升级混合实例策略

伸缩组成本优化模式以成本为目标,始终创建最低价的实例,同时,通过多可用区,多实例规格分布,以此来提高服务稳定性。但是,对于成本优势最大化的竞价实例,伸缩组难以防范竞价实例大范围回收可能导致的服务雪崩,本次升级允许用户制定更详细的成本控制策略,在成本和稳定性之间进行调整和权衡。 成本优化模式简介当您的伸缩配置选择了多实例规格,并想以最低的价格来使用同等规模的 ECS 实例配置时,您可以选择使用 成本优化策略 的伸缩组,来降低您的 ECS 实例使用成本;当您的伸缩配置选择的实例为抢占式实例时,您可能会遇到由于价格、库存等原因导致抢占式实例创建失败场景,从而导致扩容不及时,影响到业务,您也可以选择使用 成本优化策略 的伸缩组,在抢占式实例创建失败的时候自动为您尝试创建同规格的按量实例,来保证业务的稳定性。 从上述的描述,我们可以清晰的看到,成本优化模式的核心策略: 创建实例时,以单核cpu价格价格最低来选择创建实例的 InstanceType(实例规格),ZoneId(可用区)等配置信息。竞价实例创建失败时,调整为创建按量实例,以保证业务连续性。我们将上述的策略称为最低价策略(LowestPrice)。 关于成本优化模式更详细的信息,请查看 AutoScaling 推出成本优化模式。 成本优化模式升级成本优化模式的升级策略主要针对竞价实例回收机制可能带来的业务雪崩情况。主要集中在以下两点: 混合实例配比。允许用户为成本优化伸缩组制定按量实例与竞价实例的混合策略。竞价实例主动替换。在竞价实例释放前创建新实例,主动替换掉当前的竞价实例。在下面的文章中,我们将原成本优化伸缩组称为普通成本优化伸缩组,将指定实例混合策略的成本优化伸缩组称为成本优化混合实例伸缩组。 参数详解OnDemandBaseCapacity伸缩组所需要的按量实例的最小个数,当伸缩组中按量实例个数小于该值时,将优先创建按量实例。 OnDemandPercentageAboveBaseCapacity满足 OnDemandBaseCapacity 条件后,创建实例中按量实例所占的比例。 SpotInstancePoolsSpotInstancePools 指定了最低价的多个实例规格,当创建竞价实例时,将在 SpotInstancePools 中进行均衡分布。 SpotInstanceRemedy是否开启竞价实例的补偿机制。开启后在竞价实例被回收前5分钟左右,将主动替换掉当前竞价实例。 兼容性介绍成本优化混合实例伸缩组与普通成本优化伸缩组在接口和功能方面是完全兼容的。当您不指定混合实例策略的相关参数时,您将创建出普通成本优化伸缩组。同时,对于成本优化混合实例伸缩组,通过合理的制定混合实例策略,能够具有与普通成本优化伸缩组完全相同的行为。下面举例说明: 假设普通成本优化伸缩组创建的全为按量实例。此时,你创建的成本优化混合实例伸缩组只需要指定OnDemandBaseCapacity=0, OnDemandPercentageAboveBaseCapacity=100,spotInstancePools=1,那么将拥有完全相同的行为。 假设普通成本优化伸缩组优先创建竞价实例。此时,你创建的成本优化混合实例伸缩组只需要指定OnDemandBaseCapacity=0, OnDemandPercentageAboveBaseCapacity=0,spotInstancePools=1,那么将拥有完全相同的行为。 扩缩容策略成本优化混合实例伸缩组拥有一套相对独立的扩缩容策略,您在大多数情况下不需要关注实例的选择过程,如果您需要对伸缩组行为具有更详细的了解,本节中对扩缩容过程进行了详细的描述。 扩容策略当指定了伸缩组的实例混合策略之后,伸缩组并非仅对新创建出来的实例按照混合比例进行创建,而是保证伸缩组整体的实例配比趋近目标配比。 按量实例扩容策略按量实例部分,采用了 LowestPrice 的创建方式,多实例规格与多可用区按照优先级方式依此进行选择,该部分与普通成本优化伸缩组保持一致。 竞价实例扩容策略竞价实例部分,采用了 LowestPrice 的创建方式,当配置多实例规格时,将根据 SpotInstancePools 配置,在最低价的多个实例规格之间平均分配,针对每一种实例规格,当无法成功创建时,按照价格顺序依次选取下一规格继续进行创建,当竞价实例全部不可创建,将退回到创建对应的按量实例。多可用区则按照优先级的方式依次进行选择。 下面,我们通过示例来描述成本优化混合实例伸缩组的扩容行为: 假设伸缩组组内按量实例个数为3,竞价实例为1个ecs.n1.tiny规格实例,OnDemandBaseCapacity = 5,OnDemandPercentageAboveBaseCapacity = 40,SpotInstancePools = 2,伸缩组实例规格配置为:ecs.n1.tiny, ecs.n1.small,ecs.n1.medium(价格依此上升)。 扩容数量按量实例分配情况竞价实例分配情况031(tiny)141(tiny)251(tiny)361(tiny)471(tiny)571(tiny)1(small)672(tiny)1(small)782(tiny)1(small)882(tiny)2(small)缩容策略成本优化混合实例伸缩组的释放策略不遵循伸缩组上指定的释放策略,为了保持实例伸缩组内实例的混合配比,将采用以下描述的实例释放策略。首先,将根据伸缩组实例混合策略,确定将要释放的按量实例与竞价实例的个数,我们将在保证足够数量的实例被释放的前提下,按照伸缩组整体趋近期望配比的方式确定释放按量实例和竞价实例的个数。当按量实例个数不足时,将释放更多的竞价实例;当竞价实例个数不足时,将改为释放按量实例。 按量实例缩容策略释放按量实例时,将按照以下条件选择可释放的实例: 优先释放价格高的实例;价格相同时,按照伸缩组指定的释放策略选取合适数量的实例进行释放。竞价实例缩容策略释放竞价实例时,将按照以下条件选择可释放的实例: 将首先释放不属于spotInstancePools中规格类型的实例,这部分实例的释放策略与上述按量实例的缩容策略相同;如果还需要释放规格类型属于spotInstancePools的实例,将进一步选择释放所需要的实例,选择方式如下: 选择释放的实例将使得剩余实例的实例规格在spotInstancePools中趋于均衡分布;相同规格的多个实例可供选择时,将按照伸缩组指定的释放策略选择释放的实例。下面,同样我们通过简单的示例来描述成本优化混合实例伸缩组在缩容时的实例选择过程: 假设伸缩组组内按量实例个数为8,竞价实例为2个ecs.n1.tiny规格实例,2个ecs.n1.small规格实例,OnDemandBaseCapacity = 5,OnDemandPercentageAboveBaseCapacity = 40,SpotInstancePools = 2,伸缩组实例规格配置为:ecs.n1.tiny, ecs.n1.small,ecs.n1.medium(价格依此上升)。 缩容数量按量实例分配情况竞价实例分配情况082(tiny)2(small)182(tiny)1(small)272(tiny)1(small)371(tiny)1(small)471(tiny)561(tiny)660750840竞价实例补偿竞价实例在系统回收之前五分钟左右将会发送系统回收消息,当您开启竞价实例主动替换功能之后,在系统发送竞价实例的回收消息之后,弹性伸缩将会为该竞价实例创建补偿任务,并在稍后通过创建新的竞价实例来替换即将释放的实例。我们将这一主动替换即将被回收的竞价实例的行为称为竞价实例补偿。 竞价实例补偿是保障业务连续性的辅助保障机制,该补偿机制具有以下特点,你需要对这些特点有充分的认识,以便您配置合理的成本优化伸缩组。 竞价实例补偿的时间窗口。在收到竞价实例系统回收消息后,将为对应的实例生成补偿任务,大约五分钟时间后实例将被回收,当实例被回收后,伸缩组内的对应实例将被健康检查机制清除伸缩组(大约6分钟)。竞价实例补偿任务的有效期为:补偿任务生成到健康检查将实例移除伸缩组之间。一旦错过补偿时间窗口,对应的补偿任务将会失效和清理,意味着对应实例错过补偿期。有限的补偿能力。一次竞价实例的补偿过程分为新实例启动和旧实例释放两个过程,补偿任务执行过程中,伸缩组将处于锁定状态。由于暂时伸缩组不支持并行伸缩活动处理,因此,在有限的补偿时间窗口内,能够进行的补偿任务次数和实例数是有限的。由于竞价实例回收通常是呈现批次状,因此,为了最大程度利用有限的补偿能力,我们将对补偿任务进行一定程度的聚合之后,按批次进行下发,最大程度的补偿更多的实例。最佳实践这里我们主要展示如何使用java SDK创建伸缩规则,并采用maven进行依赖管理。创建目标追踪伸缩规则,需要使用aliyun-java-sdk-ess 2.3.1及以上版本。 程序所需的maven依赖如下: <dependency> <groupId>com.aliyun</groupId> <artifactId>aliyun-java-sdk-core</artifactId> <version>3.0.8</version> </dependency> <dependency> <groupId>com.aliyun</groupId> <artifactId>aliyun-java-sdk-ess</artifactId> <version>2.3.1</version> </dependency>创建混合实例的成本优化伸缩组: ...

June 25, 2019 · 1 min · jiezi

一篇文章了解广告全链路

笔者加入腾讯已经快5年时光,一直负责广告前端研发工作。最近即将离开公司,特意将广告的全链路整理了一下,作为自己的一个总结。本文将从产品的角度入手,通过描述广告的玩法,让读者对广告有一个整体的概念和印象。如果你对广告熟悉,只想了解广告的后台算法逻辑,大可从第三部分开始;如果你是对广告不太了解,那么从头开始阅读全文想必能让你有所收获。废话不多说,马上开始。1. 广告和它的分类广告,广而告之。在信息大爆炸的今天,酒香更怕巷子深了。如何尽快提高自己的曝光度,把产品推销给潜在受众,就成大部分商家的问题。当前,广告可以分为两种:品牌广告和效果广告。1.1 品牌广告品牌广告是最原始的广告,它的主要目的是进行商家品牌的塑造。多采用销售员和商家谈合约的方式进行售卖,单笔的交易额较大,定向并不准确,往往是CPT售卖。比如说奔驰在腾讯视频网站首页的广告,也不管笔者是不是买得起奔驰,直接就展示了出来。CPM: 广告最主要的计费手段,按每千次曝光来计费,其他计费方式也会最终转换为CPM来横向衡量它的价值CPT: 按广告展示的单位时间来计费,比如说8W/天CPC: 按用户的每次点击广告来计费CPA: 按用户的每次行动来计费,比如说填一个问卷或者注册CPS: 按实际的销售额来计费,如销售某件商品1.2 效果广告毫无疑问,品牌广告有个很大的问题在于,大量的广告费用被浪费在了非潜在用户身上。这对于小广告主——往往广告预算有限——是非常不友好的。而效果广告就是通过精准的定向,任意的购买数量,实时竞价的价格,迅速抢占了除了头部流量之外的其他流量。时至今日,数字化营销已经大行其道,效果广告也已经成了业界的主流——就看我之前供职的腾讯广平(主营品牌广告)被广点通(主营效果广告)收编就可以窥探一二。本文也主要是围绕着效果广告展开的。2. 购买/售卖流程在上一部分我们提到效果广告是当前的主流广告类型,那一个效果广告要如何才能被广告主购买,并最终展示给用户呢?首先要了解几个概念:DSP: 需求方平台。广告主用来进行购买广告的平台。ADX: 对接多个DSP和SSP,提供实时竞价的平台。SSP: 供应方平台。为资源提供方服务,处理一些用户纬度逻辑,管理广告位等。DMP: 第三方数据管理平台。为DSP,ADX,甚至SSP提供用户维度服务。RTB: 实时竞价让我们来整体过一下上面这张图,它可以分为N个步骤:广告主A想购买北上广三地的广告,所以他在某一个DSP上选择了“大城市维度”,并以8元/CPM的价格下单了10000CPM。当一个用户浏览媒体时,前端会迅速发送一个广告请求并带上用户的相关数据SSP把这个用户的相关信息进行维度拆分,例如30岁,上海,男性等,然后把这个曝光机会发送给ADX各DSP在ADX上对这个曝光机会进行竞拍,如果我们以20元/CPM的价格竞拍成功,广告主A就获得了这次展示机会SSP会获得广告主A的素材,然后再把这个素材传给前端前端根据素材进行渲染,用户从而在媒体上看到广告整个流程会在100ms以内完成。你可能也已经发现了,广告购买售卖的核心是RTB,那么RTB是怎么实现的呢?3. 广告核心:RTB要做到RTB,需要明确两个点,一个是该卖给谁,一个是还有多少货。举个例子:A每天卖200个西瓜。用户B愿意出5元/个的价格买3个,用户C愿意以10元/个买2个,用户D愿意以2元/个的价格买1000个,两天内交货。当然了,我们要先卖高价,然后再卖低价。同时,还需要考虑下是否能满足D的订单,否则可能背上官司。卖给谁的问题就是竞价,而能不能满足订单就是库存。3.1 竞价算法3.1.1 GSP(广义第一高价)这个算法是97年提出的。它很好理解,谁出价高广告就卖给谁。像下面的这种情况,无脑卖给广告主A。广告主出价A10元/CPMB4元/CPM但是这种算法不是没有问题的。广告主总是会倾向于出最少的钱,他会使用自动竞价工具反复试探当前的最高出价,然后再自己的承受范围内加一点,加一点。像上面的这个例子,如果没有底价的话,广告主A和B都会从0.1元开始,一直加到4元,然后B放弃了竞价,A马上又把价格降低为0.1元,B察觉到后又会重新加入到竞拍中,终而复始…这就造成了媒体收益的剧烈波动,另外不断的竞价嗅探也给整个平台造成了巨大的性能负担。3.1.2 GSP(广义第二高价)要是能让广告主减少不断变化的出价欲望就好了,GSP就是这样的一个算法——广告主按照自己的出价报价,但是按照第二高价付钱。例如3.1.1的例子中,A按照10元的报价拿到了曝光的机会,但是这次曝光只需要付出4元,所以实际的价格也是4元/CPM。在这种情况下,广告主并不会有特别的欲望频繁修改自己的出价。2002年Google一推出GSP,就因为它的稳定性和通俗易懂,很快成为了主流的竞价方式,并沿用至今。除了第二高价之外,GSP还引入了quality(广告因子)的概念。广告的竞价排序不再单纯是出价的高低了,而是竞价排序 = 出价 * qualityquality包含几千个维度,主要用于计算广告和用户的匹配程度,包括但不限于素材,上下文,时间,用户历史点击行为,广告类别,用户的人口属性等。这样的设计保证了广告的点击率,从而保证了媒体的利益。《浪潮之巅》中举过一个例子,AMD以1元/CPM的价格购买定向AMD的广告,但是Intel为了不让AMD做宣传,花4元/CPM的价格买下了所有的曝光机会。然而4元/CPM的价格对Intel来说也是亏本的,所以它通过CPC的方式来购买广告,并将广告素材改为了Coca Cola。由于定向不同,没有多少人会去点击广告,Intel花了很少的钱就打击了AMD。3.1.3 VCGGSP也不是一劳永逸,广告主B发现广告主A总是用较少的价格就能获取到曝光,他经过反复的尝试,判断出了广告主A 10元/CPM的报价,从而将报价改为9.9元。这样就可以快速消耗广告主A的广告预算,从而为自己获得曝光。广告主A发现自己的收益降低,也不甘示弱,降低为9.8元/CPM,广告主B从而以过高的价格获得了大量曝光,亏了一笔。于是广告主B又将价格降低为9.7元/CPM,继续坑广告主A…当然啦,实际的情况会比这个复杂很多,再有多个广告主,多个广告位的情况下,广告主很难找到一个合理的价格去坑对手。更何况这个操作的收益来的如此不明显。所以当前广告主还是更关注自己ROI(投资回报率),而不是干些刻意损人不利己的勾当。但是从理论上来说,这种情况确实存在。有没有一种算法可以实现让每个广告主都可以坦诚的说出自己的价格,并且获得最大的收益?这种算法就是VCG。它是为了最大的社会价值而生的。要解释它,可以举个例子。广告主盈利A10元/CPMB4元/CPMC2元/CPM广告位库存1号150CPM2号100CPM假设每个广告主只买一个广告位,在广告主A在不参与竞拍的情况下,BC广告主共收益150 4 + 100 2 = 800元,但是由于A广告主参与了竞拍,所以BC广告主的收益变成了100 * 4 = 400元,所以A广告主需要付出400元来买到1号这些CPM,单价为400 / 150 = 2.6元/CPM。同理,B广告主需要付出2元/CPM。所以媒体的总收益为600元。对比GSP的800元,VCG的收益明显是少了。这一部分的权益被让利给了广告主。事实上,数据推导证明,对于媒体来说,所有的GSP都比VCG盈利的多。但是长期来看,如果广告主接受并认可这种竞价方式,媒体也可能在市场占有率上获得回报,这也就是FaceBook为什么选择这种竞价方式的原因。3.2 库存算法刚才我们讨论了竞价,现在我们来讨论下库存。对于异常事件,库存预估算法是无能为力的,库存预估只能对大多数普遍的情况的作出预估。当前的库存预估算法主要有两种。3.1 建立数学模型通过对与库存强相关维度的分析,把维度当作参数构建数学模型,然后通过输入不同的维度值就可以得到最终的库存走势。3.2 根据ARIMA模型将离散的指经过数学处理,变为均衡波动的值,延伸这个均衡波动,反推从而推断离散的值。ARIMA是一种自线性回归模型,至于为什么不选择其他模型,是因为它的效果较好。4 总结本文描述了广告的全链路和相关的算法知识,受限于库存算法的复杂性和个人知识面,只粗略的提出了两个方案(广平使用的)。但是对于大家了解广告的玩法,还是希望能起到一定的借鉴意义。

December 30, 2018 · 1 min · jiezi