一不小心 2 个多小时烧了 47 万的云:差点破产

租用服务器Q78664972 4周前 (12-18) IDC资讯 79 0
TAGS:
云服务器大促销查看详情
作者:Sudeep是Milkie Way公司的创始人。
“这则故事讲述了我们还未推出第一款产品就差点关门大吉、我们如何活下来以及汲取的教训。”
2020年3月,新冠疫情肆虐全球时,我们初创公司Milkie Way也遭到了重创,差点儿倒闭。我们在内部探究并测试Firebase和Cloud Run,不料短短几小时花掉了72000美元(47万人民币)。
2019年11月有了这个想法后,我开始开发Announce https://announce.today。目的是开发一款“MVP”(产品的实用版本V1),因此我们的代码基于简单的堆栈。我们使用了JS和Python,并将我们的产品部署在Google App引擎上。
一不小心 2 个多小时烧了 47 万的云:差点破产-第1张图片-新之洲IDC资讯桌面端Announce
团队规模很小,于是我们专注于编写代码、设计UI和准备产品上。我花了极少的时间在云管理上,只想着让我们的产品可以上线,并拥有基本的开发流程(cicd)就行。
在V1 Web应用程序中,用户体验不是最流畅的,但我们只想开发一些用户可以尝试的产品,同时我们还构建了更好的Announce版本。由于新冠疫情蔓延全球,我们认为这是大有作为的最佳时机,因为Announce有望被各国政府用来在全球发布公告。
即使一开始用户没有创建内容,平台上有一些丰富的数据岂不是很酷?这个想法促成了另一个名为Announce-AI的项目。目的是为Announce自动创建丰富的内容。丰富的数据是指事件、地震等安全预警以及可能的本地相关新闻。
一些技术细节

为了开始开发Announce-AI,我们使用了Cloud Functions。由于我们抓取互联网的机器人程序问世不久,我们认为轻量级Cloud Functions是出路。然而我们决定扩展规模时,却遇到了麻烦,因为Cloud Functions的超时时间约9分钟。
这时我们对Cloud Run有所了解,当时它有免费使用的套餐!我还没有完全了解它,就让团队在Cloud Run上部署“测试”Announce AI功能,观察其性能。目的是尝试一下Cloud Run,以便我们可以尽快了解和探究它。
一不小心 2 个多小时烧了 47 万的云:差点破产-第2张图片-新之洲IDC资讯Google Cloud Run
由于我们的实验对象是很小的网站,于是为了简单起见,我们使用Firebase作为数据库,因为Cloud Run没有任何存储,部署在SQL Server或其他任何数据库上进行测试运行无异于大材小用。
我创建了一个新的GCP项目ANC-AI Dev,限定了7美元的云计费(Cloud Billing)预算,让Firebase项目采用免费(Spark)方案。我们想过了,就算搞砸了,最糟糕的情况无非超出Firestore每日免费的限制。
我们在修改了一些代码后部署了代码,通过在一天当中手动发出少量请求来运行它,然后撒手不管。
噩梦开始

测试当天一切顺利,我们回过头去开发Announce。第二天下班后,我在傍晚眯了一会。一醒来我读了谷歌云发来的几封电子邮件,它们都是相隔几分钟发送过来的。
一不小心 2 个多小时烧了 47 万的云:差点破产-第3张图片-新之洲IDC资讯第一封电子邮件:Firebase项目的自动升级
一不小心 2 个多小时烧了 47 万的云:差点破产-第4张图片-新之洲IDC资讯
第二封电子邮件:预算超标
还好,我的卡预设了100美元的消费上限。这导致拒绝收费,于是谷歌暂停了我们的所有帐户。
一不小心 2 个多小时烧了 47 万的云:差点破产-第5张图片-新之洲IDC资讯第三封电子邮件:卡被拒绝
我跳下床,登录到Google Cloud Billing,看到了一张约5000美元的账单。压力山大,又不清楚发生了什么,我不停地点击,设法搞清楚状况。我还开始考虑前因后果,以及我们怎么“可能”支付这笔5000美元的账单。
问题是,账单数额每分钟都在上涨。
5分钟后账单显示15000美元,20分钟后显示25000美元。我不知道最终会显示多少费用。可能一直涨上去?
2小时后,账单将近72000美元。
这时我和我的团队忙着打电话,我完全呆若木鸡,根本不知道下一步该怎么办。我们禁用了计费,关闭了所有服务。
由于我们的所有GCP项目使用同一张公司卡,因此我们的所有帐户和项目统统被谷歌暂停了。
噩梦继续

这发生在3月27日周五晚上,即我们计划Announce V1上线三天前。由于谷歌暂停了我们的所有项目(它们都与同一张信用卡相关联),产品开发工作停止了。我的士气无比低落,我们公司前途未卜。
一不小心 2 个多小时烧了 47 万的云:差点破产-第6张图片-新之洲IDC资讯
我们的所有云项目都暂停,开发工作停止。
冷静下来后,半夜里我坐下来调查此事。我开始写一份详述所有调查的文件……我称该文件为“Chapter 11”。
参与这次试验的两名团队成员也通宵达旦地调查,试图搞清楚经过。
第二天即3月28日周六,我致电或发邮件给十几家律师事务所,要求约见某位律师或咨询一下。最终其中一位律师通过电子邮件回复了。由于事件的细节即使对于工程师来说都错综复杂,所以向律师简明扼要地解释此事本身并非易事。
“作为一家自力更生的公司,我们拿不出72000美元。”
到这个时候,我已很熟悉破产法的第7章和第11章,对接下来可能发生的事情已有了充分的思想准备。
稍微喘口气:GCP的漏洞

向律师发送电子邮件后的周六,我开始阅读更多内容,并仔细阅读GCP文档中的每一页。我们确实犯了错误,但是我们甚至之前没有为项目付费,谷歌就随我们花费72000美元毫无道理!
一不小心 2 个多小时烧了 47 万的云:差点破产-第7张图片-新之洲IDC资讯GCP和Firebase
1、将Firebase帐户自动升级到付费帐户
我们从未料到这点,当初注册Firebase时也根本没有显示过这点。我们的GCP项目其计费与Cloud Run执行有关,但Firebase采用的是免费方案(Spark)。GCP突然升级了它,并向我们收取了费用。
结果证明,这是由于“Firebase和GCP深度集成”。
2、计费“限额”不存在。预算至少延迟一天。
GCP计费实际上至少延迟了一天。 谷歌在大多数说明文档中建议使用Budgets(预算)和自动关闭云功能。猜猜发生了什么?到关闭功能触发或通知云用户时,破坏很可能已造成。
计费大概需要一天的时间来同步,这就是为什么我们第二天才注意到收费。
3、谷歌应该向我们收费100美元,而不是72000美元!
由于我们的帐户到目前为止未付款,GCP应该先根据帐单信息收取100美元的费用,然后未付款时停止服务。可谷歌没有这么做。我后来明白了原因,但这仍不是用户的错!
向我们帐户收取的第一笔费用约5000美元。下一笔费用是72000美元。
一不小心 2 个多小时烧了 47 万的云:差点破产-第8张图片-新之洲IDC资讯我们帐户的计费阈值是100美元。
4、别依赖Firebase仪表板!
不单单是计费,连Firebase仪表板都要超过24个小时来更新。
据Firebase控制台文档显示,Firebase控制台仪表板上的数字可能与“计费”报告“略有不同”。
以我们的情况为例,相差86585365.85%,即8600万个百分点。即使已向我们告知账单,Firebase控制台仪表板仍显示该月有42000次读写操作(低于每日限制)。
新的一天,新的挑战

我在谷歌工作过六年半,撰写过大量的项目文档和事件报告等,知道等谷歌团队在2天后回来上班后如何向对方提出辩护。
编辑:一些读者表示我动用了在谷歌的内部联系人。事实上,我没有联系任何人,我走的是任何平常的开发人员/公司会走的路子。与其他任何小型开发者一样,我在聊天、咨询、邮件和bug上花了大量的时间。
一不小心 2 个多小时烧了 47 万的云:差点破产-第9张图片-新之洲IDC资讯在谷歌的最后一天
另一个任务是了解我们所犯的错误,并制定我们的产品开发策略。并非每个团队成员都知道发生了什么,但是很显然我们摊上了大麻烦。
我在谷歌时碰到过团队犯错误,给谷歌造成数百万美元损失的情况,但是谷歌文化保护员工(除非工程师写一份冗长的事件报告)。这回是我们公司,不是谷歌。我们自己有限的资金和付出的辛勤工作岌岌可危。
“1600亿次:这是我们的测试代码在不到一小时内读取Firestore数据库的次数。”
耸立的喜马拉雅山告诉我们……

这是我头一次受到如此大的挫折。它有可能改变我们公司还有我本人的轨迹。这件事在创业方面有几个教训要汲取,一个重要教训是要保持坚强。
那时我的团队由7名工程师/实习生组成,谷歌大概10天后才会就此事回过头来找我们。在此期间,我们必须恢复开发工作,找到解决帐户暂停问题的方法。尽管此事让我牵肠挂肚,但我们必须专注于功能和产品。
一不小心 2 个多小时烧了 47 万的云:差点破产-第10张图片-新之洲IDC资讯诗歌:Khada Himalaya bata raha hai(耸立的喜马拉雅山告诉我们)
不知什么缘故,我小时候的一首诗老在脑海中萦绕。这是我最爱的一首诗,多年后仍能一字不差地背出来。
我们究竟做了什么?

我们是小团队,希望尽可能地保持无服务器状态。Cloud Functions和Cloud Run等无服务器解决方案存在的问题是超时。
在任何时候,一个实例会连续抓取网页中的URL。但是9分钟后不久,它会超时中断。
讨论了这个问题后,几分钟内我在白板上写了一些枯燥的代码,现在我发现存在好多设计问题,但是那时候,我们更关注快速失败和学习以及尝试新事物。
一不小心 2 个多小时烧了 47 万的云:差点破产-第11张图片-新之洲IDC资讯Announce-AI在Cloud Run上的“Hello World”版本
为了克服超时限制,我建议使用POST请求(以URL作为数据)将作业发送到实例,并行使用多个实例,而不是串行使用一个实例。由于Cloud Run中的每个实例只抓取一页,所以永远不会超时,并行(大规模)处理所有页面,还因Cloud Run的使用量精确到毫秒而得到了高度优化。
一不小心 2 个多小时烧了 47 万的云:差点破产-第12张图片-新之洲IDC资讯部署在Cloud Run上的抓取工具!
如果你仔细观察,整个过程丢失几个重要的部分。
1、没有中断的指数递归:没有中断(break)语句,实例不知道何时中断。
2、POST请求可能有相同的URL。如果有指向上一页的反向链接,Cloud Run服务将陷入无限递归中,但最糟糕的是,该递归呈指数增长(我们的最大实例数量设置为1000!)
可以想象,这导致1000个实例进行查询,并每隔几毫秒写入到Firebase DB。查看这次数据post请求事件,我们发现Firebase读取一度达到每分钟约10亿个请求!
一不小心 2 个多小时烧了 47 万的云:差点破产-第13张图片-新之洲IDC资讯GCP计费帐户的月末交易摘要
1160亿次读取和3300万次写入
在Cloud Run上运行该版本的Hello World部署对Firestore执行了1160亿次读取和3300万次写入。我的天!
Firebase上的读取操作成本:
$(0.06 / 100000)* 116000000000 = $69600
长达16000小时的Cloud Run计算时间
测试后,我们以为请求因日志记录停止而终止,但实际上它进入到后台进程。由于我们没有删除服务(这是我们第一次使用Cloud Run,那时我们还不太了解),因此多个服务在继续缓慢运行。
24小时内,这些服务版本每个扩展到1000个实例,共消耗了16022小时。
我们犯的所有错误

在云上部署有缺陷的算法
上面已经讨论过了。我们确实发现了一种借助POST请求使用无服务器的新方法(网上找不到这个新方法),但是未完善算法就仓促部署了。
部署使用默认选项的Cloud Run
创建Cloud Run服务时,我们在服务中选择了默认值。最大实例数预设为1000,并发设置为80。一开始我们不知道这些值对于测试程序而言实际上是最糟糕的情况。
如果我们将最大实例数选择为“2”,我们的费用会猛减至1/500。72000美元的账单就会是144美元。
如果我们选择并发为“1”,可能根本不会注意到这笔账单。
没有完全了解就使用Firebase
有些东西只能吃一堑长一智。Firebase不是一种可以学习的语言,而是谷歌提供的容器化平台服务。它有谷歌定义的规则。
一不小心 2 个多小时烧了 47 万的云:差点破产-第14张图片-新之洲IDC资讯
另外,用Node.js编写代码时,要注意后台进程。如果代码进入后台进程,开发人员就无法轻易知道该服务在长时间运行,但是实际很可能如此。正如我们稍后了解,这也是我们的大多数Cloud Fuctions也超时的原因。
面对云,快速失败、快速学习是坏主意
云总体上像一把双刃剑。如果使用得当,它可能很有用;但如果使用不当,可能会酿成后果。
如果您数一下GCP文档中的页数,可能比一些小说的页数还长。了解定价和使用情况不仅耗时,还需要深入了解云服务的工作方式。难怪有专职人员专门做这件事!
Firebase和Cloud Run确实功能强大
高峰期Firebase每分钟能够处理约10亿次读取。这功能异常强大。我们试用Firebase已有两三个月,仍在不断了解,但是在此之前我根本不知道它的功能有多强大。
Cloud Run也是如此!如果并发设为60,最大容器设为1000,每个请求用时400ms,Cloud Run每分钟可以处理900万个请求!
60 *1000 * 2.5 * 60 = 9000000个请求/分钟
相比之下,谷歌搜索每分钟执行380万次搜索。
使用云监测
虽然谷歌云监测并未停止计费,但它确实发送了及时的警报(滞后约三四分钟)。了解谷歌云的proto/naming结构要费点工夫,但一旦你花时间了解它,仪表板、警报和度量指标都会帮助你简化一点。
这些度量指标只保存90天,我们丢失了这次事件的度量指标(那几天Firebase和Cloud Run的使用量大幅上升),不然我很乐意在本文中披露。
我们活了下来

一不小心 2 个多小时烧了 47 万的云:差点破产-第15张图片-新之洲IDC资讯
好险,差点完蛋。
谷歌仔细阅读了有关此事件的冗长文档,听取了我们讲述的情况,经过一番咨询、谈话和内部讨论后,免掉了我们的账单!
谢谢谷歌!
我们幸免于难,继续构建Announce。只不过这回有了极好的视角、架构和安全得多的实现。
“我青睐的科技公司谷歌不仅是一家值得效力的优秀公司,也是一家值得合作的优秀公司。谷歌提供的工具对开发人员非常友好,拥有详细完备的文档(总体上而言),而且越来越丰富。”
接下来是什么?

发生此事件后,我们花了几个月来了解云和我们的架构。几周后,我有了很深入的了解,估算了使用Cloud Run和改进的算法抓取“整个互联网”的成本。
这次事件让我深入分析了我们产品的架构,摈弃了产品的V1,以构建可扩展的基础架构为产品提供支持。
在Announce V2中,我们不仅构建了MVP,还构建了一个平台,可以快速地迭代开发新产品,并在安全的环境中全面测试新产品。
这个过程花了我们一些时间……Announce于11月底发布,它具有高度可扩展性,获得了最佳的云服务,并针对使用经过了高度优化。
我们还在所有平台上,不仅仅在互联网平台上发布了产品。
此外,我们重复使用整个平台来构建第二个产品Point Address。这两款产品不仅具有可扩展性,拥有出色的架构和高效性,还建立在一个平台上,我们可以迅速将想法落实到可用产品中。

文章来源: 云头条

版权声明:部分文章内容、图片来源于互联网获取,如有侵权请联系删除,发送邮件:server889#qq.com 请将#改为@,我们将第一时间审核处理!

相关推荐

网友评论

  • (*)

最新评论

相关推荐

php源码论坛源码香港vps数据中心西丽机房江阴数据西安机房win7腾讯管家门户整站PHP系统小程序香港服务器服务器租用电影网站SEO迅雷看看装修网站装饰整站系统NAS和服务器香港主机海外服务器香港机柜江阴市云计算数据中心高防服务器deituiCMS得推分类香港服务器cn2香港机房下载网站游戏服务器国外服务器端口描述香港 GIA-VPS宜兴国际数据中心网站服务器linux系统服务器屏蔽网站外贸公司韩国服务器独立服务器韩国高配低价服务器西安高新电信机房大型商城超市PHP专用服务器建设网站采集站网站站群广渠门IDC机房香港CN2CDNDDoS防火墙香港固定IP专线新之洲数据韩国机房CDN加速自动采集免费源码高清壁纸香港美国VPSBGP多线国内服务器黑客攻击访问速度高防云主机本溪市南地IDC机房服务器机房区块链小说网站维护网站西安联通机房服务器托管棋牌游戏棋牌服务器服务器配置企业服务器香港将军澳CN2 VPS北京大兴大族机房BGP服务器硬件网站建设云服务器大连黑石礁机房香港数据中心数据库服务器数据库系统香港云服务器襄阳联通枢纽楼IDC机房广告联盟联盟服务器WSTShop个人网店人才网独立云服务器企业云服务器服务器访问速度中国移动(广东湛江)数据中心交友网站婚恋网站主机网站优化香港日本韩国中国移动安徽(淮南)数据中心小程序服务器衡阳服务器租用