72.000 $ in zwei Stunden: der Cloud-Run- und Firestore-Test, der außer Kontrolle geriet

Milkie Way, ein kleines von Sudeep Chauhan gegründetes Startup, testete einen Web-Scraper auf Cloud Run, der seine Funde in Firestore speicherte. Sie hatten ein Budget von 7 $ festgelegt. Ein Bug ließ den Scraper endlos rekursiv laufen, wenn Seiten aufeinander verlinkten, und die damaligen Standardeinstellungen von Cloud Run ließen ihn auf viele Instanzen skalieren, die jeweils viele Anfragen bedienten.

In etwa zwei Stunden einer Nacht führte er rund 116 Milliarden Firestore-Lesevorgänge und 33 Millionen Schreibvorgänge aus. Die Rechnung zeigte zunächst etwa 5.000 $ und endete bei knapp 72.000 $. Chauhans Lehre, wie The Register ihn zitierte: "Fail fast, learn fast with cloud is a bad idea." (schnell scheitern, schnell lernen ist mit der Cloud eine schlechte Idee).

Nachdem das Unternehmen Google einen ausführlichen Vorfallbericht geschickt hatte, erließ Google die Rechnung als einmalige Kulanz. Der ursprüngliche Blogbeitrag, "We Burnt $72K testing Firebase + Cloud Run and almost went Bankrupt" (wir haben beim Testen von Firebase + Cloud Run 72.000 $ verbrannt und wären fast pleitegegangen), ist nicht mehr online.

• Eine Obergrenze für die Skalierung. Ein niedriger Wert für maximale Instanzen beim Cloud-Run-Dienst hätte begrenzt, wie schnell die Schleife Geld ausgeben konnte.
• Auf das Budget reagieren, nicht nur warnen. Das 7-$-Budget existierte; es sendete nur Warnungen, die Stunden zu spät kommen. Ein automatischer Kill Switch hätte die Abrechnung bei der ersten Meldung über dem Limit getrennt, bei einem Bruchteil von 72.000 $.
• Die Nutzung beobachten, nicht die Kosten. Milliarden Firestore-Lesevorgänge in einer Stunde sind eine Spitze, die Cloud Monitoring innerhalb von Minuten zeigt. Eine Spitzenregel für Firestore-Lesevorgänge hätte lange vor der ersten Kostenmeldung ausgelöst.