应用无状态化: 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
今天是开年第一天,也预祝各位龙年大吉,事事顺利
1
zhouxinyu 278 天前
用好 Spot 实例是用云的最佳实践,欢迎大家一起讨论使用 Spot 实例面临的各种问题啊。。。
|
2
ysicing 278 天前
spot 回收通知时间太短了
|
3
wan0573 OP @ysicing 不同云策略不一样,gcp 和 azure 的通知时间确实非常短。如果你用阿里云或者 aws ,预留优雅停止的时间还是比较充足的。aws 有重平衡信号,会大概提前数十分钟就通知,阿里云的话预留 5 分钟时间优雅停止,也比较足够了。当前现状来看,确实不是所有应用都适合 spot 实例的,有些应用没有比较好的弹性能力或者没法做成无状态的话,就不适用了。
|
4
sampeng 278 天前
spot 我们曾经碰到坑点,反复伸缩。就是弹出来又缩回去。引起集群的极度不稳定。找了 aws 的工程师也没查出个所以然。。
|
6
wan0573 OP @sampeng 是不是用了弹性策略?如果是基于 metric 的弹性策略,在集群规模比较小的时候,扩缩策略设置不合理会引发频繁扩缩,我们是在缩的时候额外增加了条件,只有在缩了以后不满足扩的条件才会真正的缩容,避免这种抖动。
|
7
sampeng 276 天前
|