AWS Spot 实例省钱陷阱：宠物服务器丢不起
原文：https://dev.to/maame-codes/never-put-a-pet-on-an-aws-spot-instance-em3（作者 @maame-codes）
实习时我接到一个听起来很简单的任务：把我们的一台服务器迁到新的 AWS 区域，保持和原来一样，同时把花费压到最低。
最后那半句一直在我脑子里转。只要你花时间看过怎么给 AWS 省钱，到处都是 Spot 实例。AWS 自己说它比普通的按需实例最多便宜 90%。百分之九十！我以为自己找到了白捡的便宜。
然后在站会上，一个队友问了一个问题，十秒钟就把这个想法干掉了：
"这台服务器的数据存在哪？"
这是我学到的东西，也是我现在挑 Spot 之前必问的问题。
1. Spot 实例到底是什么
AWS 有大量数据中心，里面塞满了服务器，任何时刻都有一部分机器是闲着的。Spot 实例让你以低得多的价格租用这部分空闲容量。
坑就在交易条款里：AWS 一旦需要这批容量，随时可以收回去。你会收到一个两分钟的警告，然后实例就没了。
默认情况下，被中断的 Spot 实例会被直接终止，除非你另外配置过，否则它挂载的磁盘也会一起消失。
两分钟够你保存一点工作进度，但不够你保存一整台服务器的内存。
2. 我们的服务器是扔不起的
这就是站会那个问题的要害。
我要迁移的这台服务器，把它的上下文全部放在自己的磁盘上。它知道的一切都存在那一台机器上，没有独立的数据库或存储来保存副本。
所以如果 AWS 把容量收回去，我们丢的不只是一台正在运行的服务器，而是它积累下来的全部东西，一切要从零开始。
那个最便宜的方案，很可能最后变成最贵的。
3. 宠物与牛群
DevOps 里有句老话，这件事之后我终于真正理解了。
牛群（cattle） 是你不会对任何一台产生感情的服务器。它们长得一模一样，死了一台就换一台，没人会注意到。典型例子是负载均衡器后面的 Web 服务器——真正的数据存在别处的数据库里。
宠物（pet） 是你会在意的服务器。它们有自己的名字、自己的数据，死了一台，你这一天就难过了。
Spot 实例非常适合牛群，对宠物来说风险很大。
我们的服务器是一台不折不扣的宠物。
4. 我现在会问的问题
在给任何东西选 Spot 之前，我会先问自己：
"如果这台服务器现在凭空消失，我们会丢什么？"
如果答案是"没什么，重新开一台就行"，那 Spot 大概率很合适，比如：
- 可以重新跑起来的批处理任务
- CI runner
- 测试环境
- 自动伸缩组里的服务器，且数据存在别处
如果答案是"丢很多"，那就老老实实用按需实例，至少等到数据搬到更安全的地方为止。
5. 我们照样省了钱，只是方式不同
目标依然是压低成本，所以便宜本身没被排除，只是得是正确的那种便宜。
方案是让服务器按开关机时间表运行，只在需要的时候才开。用按需实例，停机期间不付计算费用，只付一点磁盘钱；而且停机不会删掉磁盘，所以过一晚什么都不会丢。
Spot 也没有被永久排除。迁移完成后我们会再评估一次：一旦数据搬离这台服务器，它就不再是宠物，Spot 就重新变成一个选项。
最后一点想法
我进场时以为最便宜的方案就是最聪明的方案。站会上的一个问题让我明白：如果便宜的代价是可能丢数据，那它就不便宜。
说实话，这次实习里我学到的最好的东西，有些并不来自文档，而是来自队友问出那些我根本没想到要问的简单问题。这就是我喜欢和人一起工作的原因——你每天都能学到新东西。
所以我想问：你做过哪些当时觉得"省钱"、最后反而花得更多的决定？
原文：https://dev.to/maame-codes/never-put-a-pet-on-an-aws-spot-instance-em3（作者 @maame-codes）