72 000 $ en deux heures : le test Cloud Run et Firestore qui s'est emballé

Milkie Way, une petite startup fondée par Sudeep Chauhan, testait sur Cloud Run un scraper web qui enregistrait ses résultats dans Firestore. Ils avaient défini un budget de 7 $. Un bug permettait au scraper de s'appeler récursivement à l'infini lorsque des pages se liaient entre elles, et les paramètres par défaut de Cloud Run à l'époque lui permettaient de monter jusqu'à de nombreuses instances traitant chacune de nombreuses requêtes.

En deux heures environ, une nuit, il a effectué à peu près 116 milliards de lectures Firestore et 33 millions d'écritures. La facture affichait d'abord environ 5 000 $ et s'est terminée juste en dessous de 72 000 $. La leçon de Chauhan, telle que citée par The Register : "Fail fast, learn fast with cloud is a bad idea." (« Échouer vite, apprendre vite avec le cloud est une mauvaise idée. »)

Après que l'entreprise a envoyé à Google un rapport d'incident détaillé, Google a annulé la facture à titre de geste exceptionnel. L'article de blog d'origine, "We Burnt $72K testing Firebase + Cloud Run and almost went Bankrupt" (« Nous avons brûlé 72 000 $ en testant Firebase + Cloud Run et avons failli faire faillite »), n'est plus en ligne.

• Un plafond de mise à l'échelle. Un réglage d'instances maximales bas sur le service Cloud Run aurait limité la vitesse à laquelle la boucle pouvait dépenser.
• Agir sur le budget, pas seulement alerter. Le budget de 7 $ existait ; il ne faisait qu'envoyer des alertes, qui arrivent avec des heures de retard. Un kill switch automatique aurait coupé la facturation dès le premier rapport au-delà de la limite, pour une fraction des 72 000 $.
• Surveiller l'utilisation, pas les coûts. Des milliards de lectures Firestore en une heure, c'est un pic que Cloud Monitoring affiche en quelques minutes. Une règle de pic d'utilisation sur les lectures Firestore se serait déclenchée bien avant le premier rapport de coûts.