被忽视的折扣 - Spot 和 Graviton 为什么便宜

AWS 账单连续两个月超出预算,超出的幅度是个位数百分比。金额不算离谱,但方向是往上走的。我逐个资源排查想看看还能砍掉什么,结果出乎意料-几乎没有资源可以再砍了。真正的杠杆根本不在「用多少」,而在「怎么买」。这次排查让我明白,账单上的每一个数字都有它的理由,只有搞清楚这个理由,才知道该关掉什么、该留下什么。

资源早就被榨干了

我先看了用量本身,结果发现这块早就下过功夫。NAT 网关已经去掉,改用公有子网;日志只保留 7 天,链路追踪按 1% 采样,监控看板也被压缩在免费额度以内。数据库和 Redis 早就换成了更便宜的 ARM 实例,S3 用了自动分层,堡垒机也是按需启动。能在资源层面挤出来的水分,基本都挤干了。

6 月账单按项目列出来是这样的:数据库(RDS)一项就占了总账单的近 40%,其次是计算(ECS Fargate)约 17%,负载均衡器和 WAF 各占约 10%,公网 IP、缓存(ElastiCache)、S3 则分别只占个位数百分比。这时候再把实例调小就是在开倒车了-数据库之前就因为内存不够被扩容过一次,WAF 也是特意留着在生产发布前验证规则用的。剩下的唯一杠杆不是资源,而是付费方式:同样的资源,换一种更便宜的买法。

Spot 为什么便宜

最先注意到的是,计算资源一直是按需(on-demand)原价在买。但 AWS 其实有个便宜得多的通道来卖同样的服务器,那就是 Fargate Spot,比按需价格便宜大约 70%。

便宜是有原因的。AWS 按峰值需求建好了数据中心,平时大部分时间服务器是闲置的。闲着不卖收益就是 0,于是 AWS 加上一个条件-「原价客户一来,2 分钟内让位」-把这部分闲置容量低价卖出去。这跟航空公司在起飞前甩卖空座位是一个道理:反正空着飞收入也是 0,不如加个条件也要卖出去。

关键在于能不能扛得住这个条件,也就是「说收回就收回」。生产环境显然为难-用户正连着,任务却在 2 分钟后被收回,哪怕只是短暂的服务抖动也会出问题。但 staging 不一样,没有真实用户,哪怕掉线几分钟,顶多是某个 QA 短暂不便。所以我们把 staging 的 API 迁到了 Spot 上。性能和按需实例完全一致,因为 vCPU 和内存跑在同样的硬件上,唯一变化的是「可能被收回」这一条可用性条件,而这恰恰是 staging 愿意承担的代价。迁移之后,staging 上的任务在 Spot 上运行得很正常。

Graviton 为什么便宜

第二个杠杆是计算资源用的芯片。数据库和 Redis 早就用上了 ARM 实例,唯独跑应用的 Fargate 还留在 x86 上。换成 AWS 自研的 ARM 芯片 Graviton,同样的性能大约能便宜 20%。

这个便宜的道理跟 Spot 不一样。普通实例是 AWS 从英特尔或 AMD 那里采购 CPU 再转卖,我们付的价格里包含了芯片厂商的利润。Graviton 是 AWS 自己设计的芯片,没有这层中间商差价。而且 ARM 架构做同样的运算耗电更少、发热更低,数据中心的电费和散热成本也随之下降。对 AWS 来说成本更低,便宜 20% 卖出去照样有得赚,同时也是把客户往自家芯片生态里拉的策略。

关键差异就在这里:Spot 的折扣附带「要能承受被收回」这个条件,Graviton 的折扣没有任何条件,单纯就是更便宜的芯片。所以 Spot 只能用在 staging,Graviton 却可以一路用到生产环境。性能方面也基本不用担心-Node.js 在 Graviton 上单 vCPU 性能跟 x86 持平甚至更好,唯一要留意的是冷启动。应用刚启动时对单核速度比较敏感,Graviton 在这一点上可能比最新款 x86 略慢,启动时间会多出几秒。我们先在 staging 上实测了启动耗时,再升级到生产环境,事先只需要确认原生模块是否已经构建了 arm64 版本。

把这两种折扣的性质总结一下:Spot 是用忍受不便换来的折扣,所以带条件(因此只能用在 staging);Graviton 是分享AWS 自研芯片的成本优势换来的折扣,所以没有条件(因此可以用到生产环境)。性能没差别的情况下,没理由继续留在更贵的 x86 原价上。说到底,这次优化与其说是「新省下了什么」,不如说更接近把一直没去领的折扣现在才领上。

也有不能关掉的成本

不过翻账单的时候,也会遇到反方向的陷阱-看起来是浪费,实际上是保险的项目。

RDS Proxy 就是这样。它每个月要花一笔固定费用,一开始看起来像是可以砍掉的候选。Proxy 的功能之一是无中断地自动轮换密钥,而这个轮换功能当时是关闭的。既然不用轮换,为什么还要留着 Proxy?

这是个误判。Proxy 真正的用途不是轮换,而是防止连接数暴涨。发布或者扩容时任务数量突然增加,打到数据库的连接数会随之激增,而数据库能同时接受的连接数是有上限的。Proxy 在数据库前面把连接汇聚、复用,确保不超过这个上限。凑巧的是,这个数据库之前就因为内存不够扩容过一次,而每一个连接都会占用内存。也就是说,这笔固定费用不是浪费,而是每次发布时防止数据库被连接洪峰压垮的保险费。关掉它省下的不是钱,而是撤掉了一道防线。

造成这次误判的原因是代码注释。解释这个 Proxy 的注释主要是从轮换的角度写的,导致读的人很容易误以为「轮换关了,Proxy 也就没用了」。所以我们没有把 Proxy 从节省方案里删掉,而是在注释里补了一句:「主要目的是抑制连接数暴涨,轮换只是附加功能」。这样下一个看账单的人就不会再犯同样的判断错误。

账单上的每个数字都有理由

一听到要压缩云成本,手总是先伸向「关掉什么」-缩小实例、关掉功能、删掉资源。但这次学到的恰恰相反:动手砍之前,应该先问「这个数字为什么在这里」。

有些数字是没领到的折扣。就像 Spot 和 Graviton,明明有更便宜的通道能买到同样的资源,却一直在按原价购买。这类折扣各自有便宜的理由,搞清楚那个理由-是要承担被收回的风险,还是无条件的成本优势-就能判断该安全地用在哪里。也有些数字反过来是不能关的保险。看起来是浪费,但如果它挡住的是某种事故,那这一行成本就不是支出,而是防御。

说到底,读账单不是把数字变小,而是弄清楚每个数字存在的理由。搞清楚理由之后,该承担条件换来的折扣就拿下,该防事故的成本就留住。我们做的事情也就是这些-不是新省下了什么,而是把该拿的折扣和该留的保险分清楚了。