Eine Verkettung unglücklicher Umstände mit verbuggtem Code hat einem Ex-Google-Mitarbeiter und Startup-Gründer bei einem Google Cloud-Test einige aufregende Stunden beschert. Statt ein 7 US-Dollar-Budget zu verballern, wie geplant, standen plötzlich 72.000 US-Dollar auf dem Rechnungskonto.
Anzeige
Ich mache eigentlich einen weiten Umweg um alles, was mit Cloud-Diensten zu tun hat, wenn ich nicht genau kontrollieren kann, was im Hintergrund abgeht. Mir steht zwar ein dreistelliger Betrag für Azure-Tests bei Microsoft zur Verfügung. Aber mir ist nie ganz wohl bei einer solchen Sache, weil man sich das Kleingedruckte genau durchlesen muss, um nicht ins finanzielle Grab zu wandern. Und im Grunde genommen brauche ich die Cloud-Lösungen auch nicht zu testen, ich setze diese ja nicht ein.
The Register hat jetzt einen speziellen Fall in diesem Artikel aufgegriffen. Getroffen hat es Sudeep Chauhan, den Gründer des Startups Milkie Way. Dazu muss man sagen, dass Chauhan ein Ex-Google-Mitarbeiter ist und sogar zwei Jahre als technischer Programmmanager für Zahlungen tätig war.
Test einer Anwendung in der Cloud
Das Ganze ist beim Testen einer Anwendung passiert. Die Idee war, einen Dienst auszuprobieren, der Webseiten ausliest und die Ergebnisse in einer Datenbank speichert. Das Entwicklerteam entschied sich für Google Cloud Run, einen GCP-Dienst zum Ausführen von Containern, um diese Aufgabe auszuführen. Die Daten wurden in eine Firebase-Datenbank geschrieben. Bald stellten die Entwickler fest, dass ihr Code in jeder Instanz eine Zeitüberschreitung verursachte und anhielt, während er eine Seite nach der anderen abarbeitete.
Also richteten sie ein System ein, das Seiten parallel verarbeitete, um jede Seite innerhalb des Laufzeitlimits abzurufen und zu speichern. Für den Test hatte Sudeep Chauhan ein Budget von 7 US-Dollar eingeplant (Ziel war es, so lange als möglich ohne eigenen Server auszukommen). Das Problem bei diesem Ansatz: Man muss sehr genau wissen, was man da an Cloud-Diensten nutzt und welche Kosten auf einen zukommen. Chauhan schrieb dazu:
Ich sprang aus dem Bett, loggte mich bei Google Cloud Billing ein und sah eine Rechnung über ~$5.000". Super gestresst und nicht sicher, was passiert war, klickte ich herum und versuchte herauszufinden, was passiert war. Ich fing auch an, darüber nachzudenken, was passiert sein könnte und wie wir möglicherweise die 5.000-Dollar-Rechnung bezahlen könnten. Das Problem war, dass die Rechnung jede Minute weiter anstieg. Nach zwei Stunden stand sie bei etwas weniger als 72.000 Dollar.
Da war einiges schief gelaufen. Die Ausführung der Testversion von 'Hello World' auf Cloud Run verursachte 116 Milliarden Lesevorgängen und 33 Millionen Schreibvorgängen in der Firebase-Datenbank. Diese immense Zahl an Read-Operationen auf die Firebase-Datenbank schlugen mit 69.000 US-Dollar zu Buche. Um diese Zahl in die richtige Perspektive zu rücken: Google erhält etwa 3,5 Milliarden Suchanfragen pro Tag. Wenn jede Suche 30 Tabellen-Lookups erfordert, wäre das immer noch weniger als die Lookups, die das Testprogramm in wenigen Stunden durchgeführt hatte.
Fluch der Cloud, Fluch der Instanzen
Hinzu kam der 'Fluch der Instanzen'. Nach dem Testen nahmen die Entwickler an, dass die Requests beendet würden, weil die Protokollierung gestoppt wurde. Aber tatsächlich ging jede Anfragen in einen Hintergrundprozess über. Da die Leute die Dienste nicht löschten (dies war das erste Mal, dass sie Cloud Run verwendeten, und sie verstanden es damals noch nicht wirklich), arbeiteten mehrere Dienste langsam weiter. In 24 Stunden verbrauchten diese auf jeweils 1000 Instanzen skalierten Dienstversionen 16.022 Stunden Cloud-Rechenzeit.
Das verursachte weitere Kosten – und am Ende des Tages war das das Startup faktisch pleite. Aber Google hat wohl eine Ausnahme gemacht und denen diese Rechnung als einmalige Geste guten Willens erlassen. Der Original Post mit den technischen Details findet sich auf Medium und trägt den bezeichnenden Namen We Burnt $72K testing Firebase — Cloud Run and almost went Bankrupt [Part 2]. Der Fall zeigt, dass der Teufel im Detail steckt.
2015
Da hast du schön recht Günter, bis auf die Dropbox inkl. Boxcrypter nutze ich auch keine Cloud, maximal also zur Datenübertragung von Größen Dateien die man schlecht oder nur umständlich Splitten könnte.
Anfang 2000 fand ich die Idee noch ganz interessant Daten und Programme in der Wolke zu speichern mittlerweile interessiert es mich nicht mehr selbst die Bilder auf meinem Smartphone Speichere ich auf der sdkarte und nicht in der Cloud, wozu auch wenn ich etwas mit anderen teilen möchte kann ich auch das Original anstatt was Komprimiertes aus der Cloud benutzen.
116 Milliarden Lesevorgänge und 33 Millionen Schreibvorgänge in der Firebase-Datenbank – es ist doch eher ein außergewöhnlich seltener Fall, dass man mit "Hello World" derart Ressourcen verbraucht. Und es gibt auch Limits oder Prepaid-Modelle bei denen man gar nicht mehr zahlt als das gewählte Budget.
Cloud-Dienste würde ich gar nicht grundsätzlich verteufeln. Privat stellt sich natürlich die Frage, ob man Dateien, Kontakte, Fotos, etc. lieber auf einem eigenen NAS speichert. Das ist aber auch nicht für jeden ein gutes Modell und die Dienste von MS, Google und Apple bieten meist doch besseren Funktionsumfang, gerade wenn es um die Synchronisierung bspw. von OneNote oder Kontakten geht.
Und bei professionellen Projekten, gerade im KMU-Bereich, steht nicht immer ein Rechenzentrum zur Verfügung. Hier sind Cloud-Ressourcen eine preiswerte und leicht skalierbare Alternative. Und die IT-Sicherheit ist in einem hemdsärmeligen Kleinbetrieb oft nicht so hoch wie in einem professionellen RZ mit spezialisierten Fachkräften, klar verteilten Rollen und intensivem Monitoring.
Egal ob kostenloser Privatkundenservice oder kostenpflichtige Cloud-Ressourcen im B2B-Geschäft: Man kann immer AGB, EULA, Data Policy oder ähnliche Dokumente einsehen, die festlegen, was mit den Daten passiert. Dass gerade die kostenlosen Consumer-Services mit Daten und der Anzeige personalisierter Werbung bezahlt werden, ist inzwischen hinlänglich bekannt. Und das Argument diese Dienste dann nicht zu nutzen, ist auch valide. Bei einer AWS oder IBM public cloud für ein geschäftliches IT-Projekt, trifft es hingegen nicht zu.