[转]竞价实例与AWS SPOT逆向解析-优快云博客

竞价实例与AWS SPOT逆向解析

李力

腾讯云的老程序员，招聘各类技术职位

作者是我的同事alexmwang，已经获得授权

竞价实例是什么 —— what

用户视角的竞价实例

AWS竞价实例，即AWS EC2 SPOT instance
用户在竞价型实例请求中指定愿意支付的最高出价。
如果竞价型实例价格不高于用户的出价，则用户实例可以运行，且按照竞价型实例的实际价格付费；如果竞价型实例价格高于用户出价，则实例中断运行，会被销毁。
竞价实例加个由Amazon EC2设定，并且根据竞价型实例容量的供求关系发生周期性波动。

直观认识：AWS SPOT 价格示例

image

多数时候为折扣形式（低于按量计费）
可能高于按量计费，通常为倍数关系
- 验证应当是售罄的一种表现形式

AWS SPOT 控制台

image

请求类型
- 请求，提交一次性竞价实例请求。实例被抢占后不会自动补充。
- 请求并维护，自动补充由竞价中断的竞价实例。可以修改请求的容量，即实例个数。
- 预留持续时间，请求在1到6小时内不中断的竞价实例，在持续时间内不被抢占。
目标容量
- 即实例个数
AMI镜像
- 可选公有镜像和私有镜像。
实例类型
- 具体小机型，可单选or多选
- 2个工具，辅助用户选择，包括定价历史记录、竞价出价顾问。
分配策略
- 关于可用区&实例类型
- 选择最便宜的可用区&实例类型
- 在选定可用区和实例类型之间平衡竞价实例
可用区
- 无首选项，或者选择若干个zone
最高价
- 使用自动出价（推荐），按照市场现货价格预配置竞价实例，以按需价格为上限
- 用户人为设定最高价

定价历史记录

image

按照下列维度检索
实例类型，即具体小机型
日期范围
产品，具体来看是不同的OS平台
结果
该region内部多个zone的价格曲线
可能超过按量计费的原价，推测为售罄表现形式
疑问
价格与实例的OS平台有关，难道是预生产了？
预生产对镜像和规格都有限制，如果不match，将造成浪费。加之竞价实例理论上生产销毁更为频繁，采用预生产机制预计会增加复杂性

竞价出价顾问

image

按照下列维度检索
区域，即region
操作系统
出价：相对于按需计费的比例，25%、50%、100%
实例类型刷选条件：vCPU和内存下限
结果包括下列维度
具体机型和配置
相比按需，可节省成本比例
出价过高的频次
上述数据依据过去30天的历史数据
小结
对于同一机型，出价越高，节省成本比例越小，但是出价过高的频次越小
AWS 希望通过Advisor机制，建议用户购买“低频”机型，避免竞价超出用户出价，导致实例销毁。同时，引导到达市场适度平衡。

竞价实例的价值 —— why

用户侧

有效降低用户成本
- 考虑到云服务厂商自身成本，通常只能给用户一个适中的折扣。如果使用竞价实例，可以将闲时计费降到很低，有效降低用户成本。
不仅batch场景，广义的离线计算都可以使用竞价实例，用户可以接受实例被销毁

image

平台侧

错峰填谷，提升综合售卖率。
我们时常售罄，但是每周仍然有相当时间资源空闲，这其实也是浪费
单一在线业务与终端用户行为有关，通常难以改变“高峰-低谷趋势”；但是公有云上运行混合负载，涵盖在线业务和离线业务，可以引导离线业务客户购买竞价实例，实现错峰填谷
AWS 竞价实例规模巨大，曾披露：2016年一周的EC2 SPOT的计算能力大于2012一年EC2的计算实例

如何实现竞价实例 —— how

竞价实例整体设计

竞价市场
- 以可用区zone + 具体机型为基本单位，不考虑OS平台
- 竞价市场，根据供需关系确定实时价格，后文专题展开
- 竞价市场的输出是price table，即指定zone + 指定机型，输出定价历史曲线。这样拉看，前文中的“定价历史记录”不仅是运营工具，更是核心数据
计费方式
- Cvm bill组件查询price table获得具体分时价格，结合实例存在时间，向计费侧进行计费
- 整体流程与按量计费类似，不同点在于引入竞价市场的price table，计费粒度更小
请求与实例
- 维护请求与实例2层关系
抢占
- 抢占前2分钟，通知实例。子机内程序可识别信号，进行自我清理，实现“优雅退出”
- 子机计费，不得超过用户最高出价，特别注意抢占阶段。
售罄与配额
- 与当前售罄机制、配额向配合，包括总体按量售罄、具体机型售罄、用户配额。
- 当具体机型售罄时，竞价实例也应当售罄；每个用户在指定region的竞价实例也应当具有配额。
API
- 需要支持API方式

竞价市场和定价规则

关于AWS竞价市场和定价规则，AWS从未公开，最初有2种思路，auction model或者后台设定价格。

思路一
auction model
类似互联网广告，m个广告主，n个广告位，最终价格与市场供需（包括广告主的出价）有关。常见模型包括GSP（广义第二价格）等。
思路二
与市场用户的竞价行为无关，后台设定价格
调研结论
很可能是思路二
代表论文：《Deconstructing Amazon EC2 Spot Instance Pricing》，以色列理工，以2010年数据为例，234次引用
核心观点：AWS SPOT的价格不是由市场驱动。相反，价格通常是根据后台预留好的价格生成的。
备注：论文年限相对较久，但是在本问题上影响力很大，引用广泛，因此主要参考本论文。

论文核心

背景
- AWS为了售卖空闲资源，推出竞价实例
- AWS并未披露其市场定价的机制与规则，只是公开了定价历史记录（不公开定价记录，则整套机制无法运转）
- 作者尝试去逆向AWS市场定价机制
基本方法
- 定义出价D的可用性，即在一个时间段内D大于等于实际价格的时间片分数
- 公式较为抽象，论文中仅配备了公式，并无配图。读者这里脑中可以结合定价历史记录想想一个走势图，易于理解此公式。
<figure style="margin: 1em 0px;">

image
统计数据
- 横坐标为最高出价，纵坐标为前文定义的可用性
- windows，不同region、不同机型的变化曲线，出价为绝对值
<figure style="margin: 1em 0px;">

image
- linux，不同region、不同机型的变化曲线，出价为归一化结果（折扣，出价除以按需原价的比例）
<figure style="margin: 1em 0px;">

image
- windows，不同region、不同机型的变化曲线，出价为归一化结果（折扣，出价除以按需原价的比例）
<figure style="margin: 1em 0px;">

image
先破后立
形成上述趋势，有两种可能
1. AWS采用市场竞价模型，自然形成的这种趋势。
2. AWS后台设定“保留价格“，然后动态随机波动。
  论文先假设第一种可能，并推翻；然后证明第二种可能成立。两部分有所呼应，但整体行文是先破后立。
假设与推翻
- 假设AWS定价是根据市场供需、用户出价自然形成的
- 反推几乎不可能：
  - 论文提出，如果是市场驱动形成的，不可能同时满足多个趋势，例如：不同机型、不同地域，出价与可用性存在刚线性关系。按照绝对值计算，不同机型趋势相同，但取值不同；按照归一化结果计算，不同机型趋势和取值都近似等，这里不做展开。
  - 并用数学AR（auto-regresive）推导，大概率不是根据市场生成的，与用户出价无关。
猜想与证明
- 作者猜想的方法：动态随机保留价格算法，后台预先设定好若干个价格值，动态随机波动
- 算法需要一对入参，保留价格的下限F和上线C，然后通过AR推导出多个保留价格
<figure style="margin: 1em 0px;">

image
- 用数学AR推导，这种猜想的方法大概率是成立的
- 私货：对于价格与需求侧（用户出价）无关，论文说服力强；但是对于价格与供给侧（库存量）无关，论文说服力弱，因为研究者无从知道AWS的库存情况。有可能AWS实时查询库存值，然后根据预先设定好的若干个价格值中，进行关联波动。
后台设定价格的好处
- 保证成本，避免用户竞价对最终价格产生直接影响，保证售价符合成本预期
当前数据
私货：论文利用的是2010年的数据，有没有可能AWS现在已经扬弃了当年的做法呢？我们来看下2017年5月最新的数据。
刻意选取了一种变化相对不规律的机型和一种变化非常规律的机型。可以发现即使是前者图中，也有很多设定的值，即最终定价是在若干个（几种或者几十种）价格中波动的；而对于后者图中，价格只有一折、十倍两种取值。
因此，大概率AWS目前仍然在沿用类似的机制。

<figure style="margin: 1em 0px;">

image

<figure style="margin: 1.6em 0px 1em;">![image](http://upload-images.jianshu.io/upload_images/12031442-6825d7aba6836205.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

竞价市场原型

算法思路：阶梯折扣
- 设定库存阈值与预留价格的对应关系
- 定时查询库存，根据阈值设定实时价格
举例
- 后台预先设定好若干个价格值，并与库存阈值关联
- 其中价格5元类似论文中的上限C，3元类似论文中的下限F
- 其中库存值和价格的关系，是根据经验人为设定，并非市场竞价模型得出

image

需配合方支持

计费
- 支持分时计费，子机不同时段费用不同，时间粒度细
- 支持更多价格，同一机型、同一配置，具有不同价格，可以供调用方（CVM）灵活调用
资源管理
- 适当扩大资源buff，尽量避免售罄
- 可跟随竞价实例的运营推广程度同步进行
库存统计
- VStation已经支持模拟装箱算法进行准确库存统计
- 其他维度的库存待对齐支持，例如cbs、ip等
运营监控
- 竞价实例产品对运营监控能力要求较高，包括要展示各个机型的定价历史记录，使用者包括腾讯云用户和产品运营人员。
- 对资源库存统计、子机创建销毁进行监控，形成运营报表，同时覆盖竞价实例单独的运营报表
- 目前已有相关报表，进一步完善
客户筛选
- 理论上，子机随时可能被销毁，用户可接受
- 用户自行解决“断点重算”等问题，对用户有一定要求
- 剖析用户需求为增量需求，还是存量需求转换（按需计费改买竞价实例）。理论上，售价越便宜，客户购买量越大，但是实际情况还要观察。