引言
首先应该知道竞价实例（Spot Instance）可以帮助我们节省80-90％的云计算成本，与按需实例对比竞价实例通常仅是其价格的 10-20%。和预留实例对比，竞价实例通常仅是其价格的 30-60%。竞价实例提供了大量节省云资源费用的可能性。使用竞价实例的风险是，云厂商仅提前几分钟通知的情况下终止这些实例。如果应用需要保证可用性、一致性或数据一致中的任何一个，那么在使用竞价实例时，就需要专门的工具来保证这些，云厂商是不会为竞价实例来提供 SLA 的，对于大多数公司而言，这通常意味着价实例的使用场景仅限于某些开发环境和数据处理工作。然而，通过利用多个实例类型和可用区，竞价实例的不稳定性要小很多，因为在一个合适的可用区中，有很大的可能为一个合适的实例类型找到一个对应的服务器。通过扩大实例类型的范围，并在没有竞价服务器可用的情况下自动回退到按量服务器，并且如果能够提前知道回收时间，就有时间触发智能迁移，从而确保应用程序始终稳定可用，而观测云的智能巡检可以通过巡检发现是否有竞价实例即将释放并且提示当前规格的竞价实例的所有可用区的最新价格以及该竞价实例的历史价格，也可以通过自定义巡检直接续租或者寻找到可用节点进行续租，这样就可以把一些关键的工作负载也运行在竞价实例上了。
各云厂商竞价实例分析
| 云厂商 | AWS | Google Cloud | 阿里云 | Azure | 腾讯云 | 华为云 |
|---|---|---|---|---|---|---|
| 实例名称 | EC2 Spot Instances | Preemptible VMs | 竞价实例 | Low Priority VMs | 竞价实例 | 竞价计费型实例 |
| 计费单位 | 秒 | 秒 | 秒 | 秒 | 秒 | 秒 |
| 价格 | 可变最高节省 90% | 固定最高节省 80% | 可变最高节省 90% | 固定最高节省 80% | 当前时间段固定节省 80% | 可变最高节省 90% |
| 抢占/回收顺序 | 未说明 | 通常，Compute Engine 会抢占最近启动的实例，并且会避免单个客户抢占过多实例 | 一般从出价最低的实例开始终止抢占式实例，如果多个抢占式实例的出价相同，则随机确定实例的终止顺序 | 未说明 | 随机回收(系统不会因为市场价格大于用户出价的原因产生中断) | 一般从出价最低的实例开始终止抢占式实例，如果多个抢占式实例的出价相同，则随机确定实例的终止顺序 |
| 中断原因 | 市场价格大于用户出价、库存不足、请求约束条件不再满足 | 系统事件 | 市场价格大于用户出价 | 库存不足 | 市场价格大于用户出价、库存不足 | 市场价格大于用户出价、库存不足 |
| 回收警告提前时长 | 2 分钟 | 30 秒 | 5 分钟 | 30 秒 | 2 分钟 | 5 分钟 |
| 最大可用时间限制 | 无 | 24 小时 | 无 | 无 | 无 | 无 |
| 保护周期 | spot Block Instances 1/2/3/4/5/6 小时 | 无 | 1 小时 | 无 | 无 | 无 |
| 适用范围 | 所有区域/型号 | 所有区域/型号 | 所有区域、与支持按量付费售卖的实例规格相同 | 所有区域、型号不支持 B 系列和Dv2r 推广系列 | 绝大部分地域上线，支持实例类型与按量计费模式同步 | 所有区域/型号 |
使用竞价实例痛点
- 市场价格大于用户出价被回收实例
- 库存不足无法提供服务
- 系统事件避免单客户占用过多实例触发回收
竞价实例存活巡检方案
巡检定义
检测对象：云账户下的所有竞价实例
触发逻辑：未来两分钟存在竞价实例回收警告
根因查询： 每种实例的配置, 每种实例的价格趋势, 每种实例的库存趋势
数据点频率： 1 s
检测数据范围： 2分钟
巡检周期： 2分钟
巡检流程设计
以云账户为入口检测未来两分钟存在竞价实例回收警告，当发现有实例回收警告时时触发生成事件逻辑并进行根因查询
巡检事件报告
- 事件概览：描述异常巡检事件的对象、内容等
- 抢占式实例详情：可查看当前实例的详细信息包括实例名称、ID、地域、可用区等
- 抢占式实例类型价格：查看当前规格下所有可用区的价格帮助用户进行出价
- 抢占式实例类型历史价格：可查看当前规格的抢占式实例再不同可用区的历史价格方便追踪价格变动
- 温馨建议：给出当前异常场景的操作建议
观测云阿里云抢占式实例存活巡检使用实践
前置条件
- 自建 DataFlux Func 观测云特别版 ，或者开通 DataFlux Func 托管版
- 在观测云「管理 / API Key 管理」中创建用于进行操作的 API Key
- 安装 阿里云抢占式实例存活巡检 巡检脚本
开启巡检
在自建的 DataFlux Func 中，通过「脚本市场」安装「观测云集成（阿里云-ECS采集） 」、「 观测云自建巡检（阿里云抢占式实例存活检测）」并根据提示配置观测云 API Key 完成开启。
在 DataFlux Func 脚本市场中选择需要开启的巡检场景点击安装，配置观测云 API Key 和 GuanceNode 后选择部署启动脚本即可
启动脚本部署成功后，会自动创建启动脚本和自动触发配置，可以通过链接直接跳转查看对应配置。
触发事件
当巡检过程中发现最近两分钟内出现即将回收实例现象，就会生成事件报告，报告内容如下：
- 事件概览：描述异常巡检事件的对象、内容等
- 抢占式实例详情：可查看当前实例的详细信息包括实例名称、ID、地域、可用区等
- 抢占式实例类型价格：查看当前规格下所有可用区的价格帮助用户进行出价
- 抢占式实例类型历史价格：可查看当前规格的抢占式实例再不同可用区的历史价格方便追踪价格变动
- 温馨建议：给出当前异常场景的操作建议
通过报告内容我们可用直接下单对于的竞价实例，也可以通过 DataFlux Func 基于巡检结果调用阿里云相关 API 完成自动出价下单操作
竞价实例的使用建议
不像预留实例和按需实例一样直接，竞价实例的市场驱动机制在实施和理解角度比较复杂。
另外，整体竞价资源的供给和需求同时不确定，用户在使用的时候必须考虑不稳定的价格波动和实际有多少资源可用性。
1．混合使用竞价实例、按需实例和预留实例。
这其实跟使用混合云模式有相同的思路，本地资源相当于预留实例，是固定的资源。而根据需求，弹性扩展到云的资源就包括了按需实例和竞价实例。竞价实例有价格优势，但其可被抢占性决定了不是什么时候都适用。利用自动化和分析平台，混合使用三种实例可以在运行大量工作负载的同时，保证低成本和SLA。
2．避免在竞价实例上运行不能中断的任务，而运行对错误容忍度高和使用灵活的应用
比如大数据，容器化的工作任务，高性能计算HPC，无状态的web服务器，渲染、CI/CD和其他测试和开发工作负载。
3．把需要比较长时间的大型工作任务拆分成大量小的、异步的短时间工作任务
尽可能利用低成本的竞价资源来运行，减少被中断的可能性。
4. 充分利用竞价实例的价格浮动特性
在适当的时间购买可被抢占实例，降低计算成本，并在整体成本下降的前提下，提升业务在该时间周期内的吞吐量。比如在晚上或周末这种非高峰时段运行大型抢占式虚拟机集群。
5．合理使用云厂商提供的工具
AWS的Spot Instance Advisor 可以帮用户确定中断可能性最低的池，提供与按需费率相比可节省的成本信息。在选择实例时，用户可以权衡应用程序对中断的容错能力和自身的成本节省目标。中断率越低，Spot 实例的运行时间可能就越长。
