查看原文
其他

2小时,账单47万!「Milkie Way公司破产未遂事件」复盘分析

灵魂工作室 速石科技 2021-06-16

2019年11月,Milkie Way公司开始开发一个叫Announce的产品。

2020年3月,这家初创公司就差点儿破产关门。


一个云上的小测试项目,使用了数据库和Serverless服务几个小时,在1000个实例上进行了1160亿次读取和3300万次写入,他们不小心烧掉了将近72000 美元(折合人民币约47万元)

EXO ME ???????

 

我们大概讲过一万次(bushi):用户用云是有一定的学习成本和难度的。在应用和基础架构,加上丰富多样的云产品和服务之间,是存在GAP的。

但一直没有合适的案例。

这次的「Milkie Way公司破产未遂事件」,当事人Sudeep Chauhan的一手复盘分析和经验总结,我们觉得非常有代表性和参考性,值得跟大家分享。


尽管文中的示例是关于GCP(Google Cloud Platform)的,但所有云服务都具有相似的功能,只不过具有不同的名称、价格和使用策略。


事情是怎么发生的?



作为一家初创企业,一开始团队就是简单快速创建了MVP(最小可行性产品),把产品部署在Google App引擎上。工作的重点都放在写产品代码和UI设计上,对云的关心程度仅限于“能用就行”。

这,就为后面发生的事情埋下了导火索


2020年,随着新冠疫情的爆发,Sudeep Chauhan认为这可能是他们的产品走向世界的好机会。于是,创建了Announce-AI项目。

团队在没有彻底研究清楚Cloud Run(Serverless服务)到底是怎么个玩法的情况下就在上面部署了“测试版”Announce-AI,想看看效果怎么样。


由于这个测试版只是一个非常小的站点,所以团队选择了Firebase的数据库

他们创建了一个新的GCP项目,设置了7美元的云资源使用预算,选择了Firebase免费计划,想着最坏不过是超过每天的免费额度(该计划免费提供5GB的存储空间,以及每天免费提供5万次读取和2万次写入操作)。


3月26日,一切都很好。

到了第二天晚上,噩梦就开始了。

Sudeep Chauhan在邮箱中发现了几封来自GCP的提醒邮件:

第一封邮件:您的Firebase Project已自动升级为收费账户。

第二封邮件:您在GCP的7美元云资源使用预算已超支。

第三封邮件:由于信用卡支付失败,您的GCP账户已暂停使用。

由于Sudeep Chauhan的信用卡设置了100美元的消费限额,他以为此时此刻的花费最多不过100美元。
然而,他登录后台查看账单时却看到一张约5000美元的账单。


就在他还在思考如何付清这笔“巨款”的时候,更可怕的事发生了:账单金额还在不停增长!

5 分钟后,账单显示15000美元。

20分钟后,账单显示25000美元。

…………

他整个人都懵了。


直到两个小时以后(这大概是他人生最漫长的两个小时,期间,他们禁用了计费功能,并关闭了所有服务),账单金额最终停在接近72000美元。

由于在所有GCP项目中都绑定了相同的银行卡,因此他们所有的帐户和项目都已被Google暂停。
产品开发工作被迫停止,公司前途未卜。
他开始疯狂研究破产法,因为,没钱。


他们到底做错了什么?


 

他们主要犯了两方面的错:

一、在云上部署了有缺陷的算法;

二、对GCP产品和服务的认知不足,使用默认选项。


1

有缺陷的算法



团队使用POST请求将URL作为数据发送到某一实例,且并发使用多个实例以替代串行使用单一实例(这是发挥云上弹性优势的常见操作)。由于Cloud Run的处理操作能够精确到毫秒,所以全部页面都将得到并发处理,整体性能得到了高度优化。


但在具体的编码过程中,由于缺少break语句,实例无法中断。而POST请求可以具有相同的URL,如果其中存在指向上一页的反射链接,那么Cloud Run服务就会陷入无限递归中而且这个递归会呈指数增长。

 

团队将最大实例数设置为1000,这意味着当测试开始后,这1000个实例会不断进行查询,并且每几毫秒就向Firebase数据库写入一次。高峰时,Firebase每分钟的请求数甚至高达10亿个。

24小时内,Cloud Run进入后台进程,在1000个实例上,一共消耗了16022个小时


最终,在账户被GCP停用前,该项目共执行了1160亿次读取和3300万次写入。而Firebase上的读取成本是每十万次0.06美元,仅此项花费就接近7万美元。

 

2

不了解GCP产品和服务



1、不了解Firebase就直接用了,也没注意账户会自动升级成付费账户

Firebase不是一种可以学习的语言,是Google提供的一种Serverless服务,有特定的规则,而不是由自然法则或特定用户可能会认为的规则来定义。

而且虽然他们使用的是Firebase的免费计划,但他们并没有注意到GCP刚刚更新了和Firebase的深度集成,一旦接受了GCP项目的结算条款,Firebase账户默认可以自动升级为付费账户。

 

2、不知道GCP账单有延迟

团队过于依赖GCP自带的预算超支通知,由于需要先进行结算,该通知在结算完成后才会发出,当预算超支,触发云功能关闭的时候,大量账单费用已经产生了。

 

3、没有意识到Firebase仪表盘数据存在延迟可能造成的后果

虽然Firebase控制台文档明确表明仪表板数字和GCP账单数据略有不同。但在发生每分钟10亿次请求时,这个延迟将非常致命。

 

4、信用卡支付限额并不能阻止巨额账单的生成

GCP的账单结算与支付之间同样存在延迟,因此100美元的信用卡支付限额并不能阻止巨额账单的生成。当GCP发现无法扣款后,用户账号被停用,但此时已经产生了大量的欠费。


完美的故事结局



幸运的是,他们还活着。

在等待、咨询、冗长的电子邮件和查找BUG上花费了无数的时间后,Google最终免掉了他们的账单。


一般来说,故事到了这里就结束了。

就像王子和公主幸福地生活在一起了一样。


但我们更想问一句:后来呢?



后来,Milkie Way公司花了几个月的时间来了解云和自己的产品体系架构,报废了V1版的产品,构建了可扩展的架构来为产品提供动力,在云上建立了一个可以快速迭代、安全的平台,而不仅仅是一个MVP。

7个月后,他们发布了V2版产品。

 

去年年底,创始人Sudeep Chauhan在公司博客上复盘了这次事件,说:

云就像一把双刃剑。如果使用得当,它可能会很有用,但是如果使用不当,则可能会导致后果。

如果您算一下GCP文档中的页数,则可能比几本小说中的页数还多。了解定价和用法不仅耗时,而且需要深入了解云服务的工作方式。

怪不得有人专门做这个!(没错,说的就是我们。)

 

Firebase和Cloud Run确实强大。

在高峰期,Firebase能够处理每分钟约10亿次读取。这是异常强大的。我们已经在Firebase上玩了2-3个月,并且仍在学习它,但是直到现在我仍然完全不知道它有多强大。


Cloud Run也是如此!并发==60,max_containers == 1000,每个请求占用400毫秒,Cloud Run的请求数每分钟可以处理900万个请求!60 * 1000 * 2.5 * 60 = 9,000,000个请求/分钟


相比之下,Google搜索每分钟可获得380万次搜索。“


Sudeep Chauhan的云实践一手经验


 


1

多花点时间学习



1.1、上云之前请先阅读说明书

几乎所有云产品都有非常完整且不断更新的操作指南,里面包含了一系列需要做或不应该做的事情。

强烈建议阅读即将使用的每项云服务的操作指南,这不仅能够得到帮助,也可以避免不必要的麻烦。

 

1.2、不要直接挑战多云HARD模式

不同的云厂商有各自不同的优缺点,如果你有专门的开发团队和SRE(就是DevOps),你可以使用多云。但如果你是独立开发人员或小型创业公司,建议你不要一上来就使用多云,除非你确实需要其他云平台的某个独有功能。

因为每个云平台都有丰富的产品类型和大量的工具资料,多花一些时间研究这些东西,可以确保你对整个云平台和即将使用的产品服务有一个清晰的认识。

 

我们的fastone多云平台,5分钟快速上手的可视化界面免去了大量学习成本,扫码免费试用现在还送300元体验金,了解一下?入股不亏。

 

1.3、了解钱是怎么花出去的

大多数云服务都会提供成本计算器,多花一些时间测试成本,确保你知道钱都花到哪里了,再开始部署。

比较可靠的做法是,先在安全的环境(开发帐户)中测试服务一到两天,等待完整帐单处理完毕,并且你能够正确理解帐单上的每一项之后,再将其集成到产品中。

 

我们有一份六大云厂商服务器资源价格多维度对比报告,对云上资源的灵活计费模式做了深度科普,扫码添加小F微信号(ID:imfastone)即可免费获取。


2

不要做这两件事



2.1、不要下载密钥

保护密钥和令牌的最简单解决方案是永远不要下载它们。

 

2.2、不要把鸡蛋放在一个篮子里

理想情况下,在任何项目中,你都应该具有dev、test、staging、prod环境。即便项目非常小,你也应该至少拥有相互之间完全分离的dev和prod环境。


3

捂紧你的钱包



3.1、设置云厂商的服务配额

大多数云服务都可以设置配额,也就是支付上限,可以从每天、每分钟、每用户每分钟使用等多个维度来进行该设置。

当你的实际使用情况达到配额上限时,平台就会自动切断服务。


在设置配额时,需要注意两点:

某些默认配额是针对大客户的,在普通用户看来会非常离谱,比如每天一百万美元的云资源预算,必须重新对其进行设置;

并非所有服务都有配额限制,比如在本次事件中起主要因素的Firebase读写操作。

 

3.2、强烈建议开启云监控功能

当云服务的使用情况超出用户设置的配额时,云监控可以触发包括短信、电子邮件和应用程序通知在内的警报,云监控的大多数指标仅有几分钟的延迟。


GCP把这项服务称为Cloud Monitoring,AWS叫Cloud Watch,Microsoft叫Azure Monitor,国内包括阿里云、华为云、腾讯云在内的主流云厂商均称其为云监控。

这个服务一般是免费的,或者只收取极低的价格,建议时刻开启这项服务。

 

3.3、设置预算超支通知

几乎所有云平台的文档都会都建议用户设置预算超支通知,但由于整个“结算-账单-通知”流程存在延迟,当你收到预算超支的通知时,你可能已经积累了相当大金额的账单,你应该开启这个功能,但不要过于依赖它。

 

云在提供海量资源的同时也在考验着用户的技术能力,不管是普通的云上部署/数据传输,还是高阶的弹性动态使用资源,再进一步根据用户策略的智能自动化调度,很多事情手动做和自动化做的差别很大,甚至手动根本无法完成,比如——

集群自动化部署从4天到1.75小时,如何让Bladed仿真效率提升55倍?

基于用户策略智能调度:提速2920倍!用AutoDock Vina对接2800万个分子

GPU/CPU异构资源:155个GPU!多云场景下的Amber自由能计算


3.4、使用多种付款方式,并设置支出限额

首先,你必须给开发和生产环境分配不同的付款方式,避免两者混用。

这样当其中一个付款方式出现问题后,它只会影响其绑定的环境,而不会对其他工作产生影响。


其次,对付款方式设置支出限额,支出限额可以设置在你预计费用的120-150%之间。

我们在3.1中设置了服务配额,如果某个服务达到了这个配额,那么云平台会立即扣费,扣款会失败,你的服务会被暂停。

如果你没有对你的付款方式设置支出限额,或者你绑定的压根就是一张无限信用卡,那费用就会被成功扣除,可能会从你的卡里扣除一笔远远超过你预期的费用。

这是最后一道防线了,如果你严格按照本文中的建议操作,应该用不到这一步。


如果这些都做到了,你应该能睡个好觉。


我们有个为应用定义的云平台
集成多种应用,大量任务多节点并行
应对短时间爆发性需求,连网即用
跑任务快,原来几个月甚至几年,现在只需几小时
5分钟快速上手,拖拉点选可视化界面,无需代码
支持高级用户直接在云端创建集群


扫码免费试用,送300元体验金,入股不亏~


 END -

更多电子书
欢迎扫码关注小F(ID:imfastone)获取

你也许想了解具体的落地场景:
155个GPU!多云场景下的Amber自由能计算
怎么把需要45天的突发性Fluent仿真计算缩短到4天之内?
国内最大规模OPC上云,5000核并行,效率提升53倍
提速2920倍!用AutoDock Vina对接2800万个分子
从4天到1.75小时,如何让Bladed仿真效率提升55倍?
从30天到17小时,如何让HSPICE仿真效率提升42倍?

关于为应用定义的云平台
【2021】全球44家顶尖药企AI辅助药物研发行动白皮书
EDA云平台49问
国内超算发展近40年,终于遇到了一个像样的对手
帮助CXO解惑上云成本的迷思,看这篇就够了
灵魂画师,在线科普多云平台/CMP云管平台/中间件/虚拟化/容器是个啥
花费4小时5500美元,速石科技跻身全球超算TOP500

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存