分享几个最佳实践，让你用好云的竞价/SPOT 计算实例来降低成本

[wan0573]

• 应用无状态化: spot 实例本身没有 SLA ，随时会被回收。应用不要将关键元信息持久化到本地磁盘或云盘。无状态的应用可以随时被停止和重新拉起

• 应用本身做好弹性:如果应用进程的重启会影响业务，那么这种弹性水平是不够的。通过分布式多节点、极速的容灾与恢复做到应用进程重启，业务无感

• 充分利用 spot 实例的终止信号: 云厂商对 spot 实例被回收的时候，都会提前一小段时间(15 秒到 2 分钟不等)的时间让用户做优雅停止，这个需要好好利用。云本身也有提供一些产品化的能力可以帮助用户方便的处理这个终止信号，例如 asg 生命周期钩子、eks 的容量重平衡能力等。

• 按需实例与 spot 实例混布:按需和 spot 实例混布可以保证在满足最低服务水平的情况下尽量节约成本。即使最坏情况下所有 spot 实例都同一时刻被回收，仍然可以确保保有一定容量的按需实例

• spot 实例库存不足时自动回退成按需实例: spot 实例有时候会在某些可用区容量不足导致一直无法新建出 spot 实例，这时候可以利用 asg 这种弹性伸缩组来达成自动回退按需实例的效果

AutoMQ 是一款开源的云原生 Kafka 解决方案，以上经验都已经在 AutoMQ 中实践并且应用于生产，如果以上内容对大家有帮助，或者想进一步了解 AutoMQ 是如何用好云的，可以给我们开源项目点个赞，加入我们社区群关注第一手信息。关于 spot 实例应用的详细原文可以在 AutoMQ 公众号内查看。

开源项目 github 地址： https://github.com/AutoMQ/automq-for-kafka

今天是开年第一天，也预祝各位龙年大吉，事事顺利

[zhouxinyu]

用好 Spot 实例是用云的最佳实践，欢迎大家一起讨论使用 Spot 实例面临的各种问题啊。。。

[ysicing]

spot 回收通知时间太短了

[wan0573]

@ysicing 不同云策略不一样，gcp 和 azure 的通知时间确实非常短。如果你用阿里云或者 aws ，预留优雅停止的时间还是比较充足的。aws 有重平衡信号，会大概提前数十分钟就通知，阿里云的话预留 5 分钟时间优雅停止，也比较足够了。当前现状来看，确实不是所有应用都适合 spot 实例的，有些应用没有比较好的弹性能力或者没法做成无状态的话，就不适用了。

[sampeng]

spot 我们曾经碰到坑点，反复伸缩。就是弹出来又缩回去。引起集群的极度不稳定。找了 aws 的工程师也没查出个所以然。。

[zhouxinyu]

@sampeng 你们是什么场景呀，有混合 on-demand 实例使用吗？

[wan0573]

@sampeng 是不是用了弹性策略？如果是基于 metric 的弹性策略，在集群规模比较小的时候，扩缩策略设置不合理会引发频繁扩缩，我们是在缩的时候额外增加了条件，只有在缩了以后不满足扩的条件才会真正的缩容，避免这种抖动。

[sampeng]

@zhouxinyu 一个独立的伸缩组，当时是给大数据做数据分析用，想得挺美好。


@wan0573 必然不是。横竖就是不定时的机器没了，然后又出来一台。不用弹性伸缩，自己写程序来控制才搞定。。

[wan0573]

@sampeng 如果全部用 spot 实例，集群确实会时不时抖动，这个根据所在 region 和 zone 的机器库存有关。你的情况应该就是机器被回收了，然后为了满足 asg 的容量，会重新创建新的 spot 实例。如果业务没法容忍集群比较多的抖动的话，配合一定比例的 on-demand 实例比较好，兼顾成本与稳定。od 实例还可以套用 saving plan ，更加实惠点。