Google Cloud：隔夜72,000美元的账单

初创公司Milkie Way的创始人Sudeep Chauhan在一次账单震惊的情况下遭受了惨重考验，该账单上有一笔$ 7.00的帐单预算和免费的Google Cloud Platform（GCP）数据库计划，一夜之间产生了$ 72,000的发票。

＆＃34;我跳下床，登录Google Cloud Billing，看到一张约5,000美元的账单，＆＃34; Chauhan在他的公司的博客上写道。 ＆＃34;超级强调，不确定发生了什么，我四处张望，试图找出正在发生的事情。我也开始考虑可能发生的事情，以及如何支付$ 5K的账单。问题是，账单每分钟都在上涨。两个小时后，它的价格略低于$ 72,000。

尤其令人惊讶的是，乔汉（Chauhan）曾经是Google的一员，甚至曾担任支付技术项目经理两年。发生了什么？

这个想法是建立一个可以抓取网页并将结果存储在数据库中的系统。他的团队选择了Google Cloud Run（一项运行容器的GCP服务）来完成这项工作。然后，他们发现每个实例中的代码都将超时并停止，因为它一页一页地刮到另一页。因此，他们建立了一个多实例系统，该系统可以并行处理页面，以在运行时限制内获取并存储每个页面。

开发人员被邀请烘烤＆＃39;在Google Cloud上运行＆＃39;按钮进入git repos ...当然是Google了

阅读更多

Chauhan写道：＆＃34;为了克服超时限制，我建议使用POST请求（以URL作为数据）将作业发送到一个实例，并[使用]并行使用多个实例，而不是串行使用一个实例。因为Cloud Run中的每个实例只能刮取一页，所以它永远不会超时，并行（缩放）处理所有页面，并且由于Cloud Run的使用精确到毫秒，因此也得到了高度优化。

前Googler反映，他错过了链接回彼此的页面的可能性，从而导致＆＃34;无限递归。不过，这应该没什么大不了的：他将帐单预算设置为$ 7.00，并且有免费计划的Firebase数据库。 ＆＃34;我们想象中最糟糕的情况是超出了每日免费Firestore限制，＆＃34;他说。此外，该帐户的信用卡的支出限额为100美元。

不幸的是，结算预算不会自动限制Google Cloud或Google Maps Platform的使用/支出，＆＃34;根据文档。

经过一天的测试，Chauhan处于睡眠状态，但Google发送了一封自动电子邮件，通知他，由于Google Cloud中的活动，他的免费Firebase计划已“升级”，＆＃34;并且此“发起了帐单”该项目。

他发现了GCP成本控制的多个问题。结算大约需要一天的时间，这就是为什么我们第二天才注意到收费的原因， Chauhan说。接下来，＆＃34; Firebase仪表板花了超过24小时才能更新，＆＃34;他说。他说，这意味着仪表板显示的使用量在每日限制之内，当时是8600万个百分点。比显示的更多。

GCP Cloud Run默认设置也发挥了作用。 ＆＃34; max-instances预设为1,000，并发设置为80，＆＃34;他说。如果他已将此值校正为2和1之类的较小值，则不会发生帐单冲击。

由于这些设置，＆＃34;在Cloud Run上运行此版本的Hello World部署使Firestore读取了1,160亿次，写入了3,300万次，＆＃34;周汉说。

大部分成本都降到了Firebase读取操作上，甚至是每100,000只$ 0.06。将其乘以1,160亿，您将获得69,600美元。另外还有16,000小时的Cloud Run Compute时间，这部分是因为应用程序没有删除服务，而是将它们留在了后台进程中。

越野车代码的性能令人印象深刻。 ＆＃34;在高峰期，Firebase能够处理每分钟约10亿次读取，＆＃34; 他说，同时运行的Cloud Run可以每分钟处理900万个请求。 ＆＃34;快速失败，通过云快速学习是一个坏主意，＆＃34; 乔汉总结说。 如果您算出GCP文档中的页数，则可能比[一本]小说中的页数还多。 了解定价，使用情况不仅耗时，而且需要深入了解云服务的工作方式。＆＃34; 有一个幸福的结局。 ＆＃34;仔细阅读了有关此事件的冗长文档后，我们分享了自己的观点，进行了各种咨询，对话和内部讨论，Google一次性放弃了我们的账单，＆＃34; 周汉说。 不能依靠这种宽大处理。 自动扩展和按需计算存在弊端，弄清楚将要花费的成本是具有挑战性的。 建议注意。 ®