Die Geschichte, wie wir vor der Einführung des ersten Produkts am Rande des Bankrotts standen, wie wir es geschafft haben zu überleben und welche Lehren wir gezogen haben.
Im März 2020, als COVID die Welt eroberte, wurde auch unser Startup Milkie Way hart getroffen und fast geschlossen. Wir haben 72.000 US-Dollar verbraucht, als wir Cloud Run mit Firebase mehrere Stunden lang recherchiert und intern getestet haben.
Ich habe im November 2019 mit der Entwicklung des Announce- Dienstes begonnen . Das Hauptziel war es, die minimale funktionale erste Version des Produkts freizugeben, sodass der Code auf einem einfachen Stapel funktioniert. Wir haben JS, Python verwendet und unser Produkt in Google App Engine bereitgestellt.
Mit einem sehr kleinen Team konzentrierten wir uns auf Codierung, UI-Entwicklung und Produktvorbereitung. Ich habe fast keine Zeit mit der Verwaltung der Cloud verbracht - ich habe gerade genug Zeit aufgewendet, um das System zum Laufen zu bringen und einen grundlegenden Entwicklungsprozess (CI / CD) bereitzustellen.
Desktop-Ankündigung
Die erste Version war nicht sehr praktisch, aber wir wollten nur eine Version zum Experimentieren veröffentlichen und dann an der normalen arbeiten. Aufgrund von COVID dachten wir, dass dies ein guter Zeitpunkt für den Start ist, da Regierungsbehörden auf der ganzen Welt Announce verwenden können, um Warnungen zu veröffentlichen.
Ist es nicht großartig, Daten auf der Plattform zu generieren, wenn Benutzer ihre Inhalte noch nicht hochgeladen haben? Dieser Gedanke führte zu einem anderen Projekt, Announce-AI, zur Erstellung von Inhalten. Datenreich sind verschiedene Ereignisse wie Erdbebenwarnungen und möglicherweise relevante lokale Nachrichten.
Einige technische Details
Wir haben Cloud-Funktionen verwendet, um mit der Entwicklung von Announce-AI zu beginnen. Da unser Scraping-Bot noch in den Kinderschuhen steckte, haben wir uns für diese leichten Funktionen entschieden. Es gab jedoch Probleme mit der Skalierung, da Cloud-Funktionen eine Zeitüberschreitung von ca. 9 Minuten haben.
Und plötzlich erfuhren wir von dem Cloud Run-System, das damals ein großes kostenloses Nutzungslimit hatte! Ohne es vollständig zu verstehen, bat ich das Team, die "Test" -Funktion Announce-AI in Cloud Run bereitzustellen und ihre Leistung zu bewerten. Das Ziel war es, mit Cloud Run herumzuspielen, um Erfahrungen zu sammeln.
Google Cloud laufen
Da wir eine sehr kleine Site haben, haben wir der Einfachheit halber eine Firebase-Datenbank verwendet, da Cloud Run keinen Speicher hat und die Bereitstellung von SQL Server oder einer anderen Datenbank für den Test zu umfangreich ist.
Ich habe ein neues GCP ANC-AI Dev-Projekt erstellt, ein Cloud-Abrechnungsbudget von 7 USD eingerichtet und das Firebase-Projekt mit einem kostenlosen Plan (Spark) gespeichert. Der schlimmste Fall, den wir uns vorgestellt haben, ist das Überschreiten des täglichen Firebase-Limits.
Nach einigen Änderungen haben wir den Code vorbereitet, einige manuelle Anfragen gestellt und ihn dann ausgeführt.
Der Albtraum beginnt
Am Tag des Tests lief alles gut und wir kehrten zur Entwicklung von Announce zurück. Am nächsten Tag nach der Arbeit am späten Nachmittag machte ich ein Nickerchen. Als ich aufwachte, sah ich mehrere E-Mails von Google Cloud, alle im Abstand von mehreren Minuten.
Erste E-Mail: Automatisches Upgrade unseres Firebase-Projekts
Zweite E-Mail: Über Budget
Glücklicherweise hat meine Karte ein Limit von 100 USD. Aus diesem Grund wurden keine Zahlungen getätigt und Google hat den Dienst unserer Konten eingestellt.
Dritter Buchstabe: Karte abgelehnt
Ich sprang aus dem Bett, gab die Google Cloud-Abrechnung ein und sah eine Rechnung über etwa 5.000 US-Dollar. In Panik fing er an, auf die Tasten zu klicken, ohne zu verstehen, was los war. Im Hintergrund begann ich darüber nachzudenken, wie dies hätte passieren können und wie ich die 5.000-Dollar-Rechnung bezahlen sollte. In diesem Fall.
Das Problem war, dass die Punktzahl von Minute zu Minute zunahm.
In fünf Minuten wurden 15.000 US-Dollar angezeigt, in 20 Minuten 25.000 US-Dollar. Ich verstand nicht, wann die Zahlen nicht mehr steigen würden. Vielleicht wachsen sie auf unbestimmte Zeit?
Zwei Stunden später stoppte die Zahl bei knapp 72.000 US-Dollar.
Zu diesem Zeitpunkt waren das Team und ich auf der Telefonkonferenz, ich war völlig geschockt und hatte absolut keine Ahnung, was ich als nächstes tun sollte. Wir haben die Abrechnung deaktiviert und alle Dienste geschlossen.
Da wir in allen GCP-Projekten mit einer Karte abgerechnet haben, wurden alle unsere Konten und Projekte gesperrt.
Der Albtraum geht weiter
Dies geschah am Freitagabend, dem 27. März - drei Tage bevor wir die erste Version starten wollten. Jetzt wurde die Entwicklung eingestellt, da Google alle unsere mit einer Karte verknüpften Projekte ausgesetzt hat. Meine Moral war unter dem Boden und die Zukunft des Unternehmens schien ungewiss.
Alle unsere Cloud-Projekte werden angehalten, die Entwicklung wird gestoppt.
Sobald sich mein Geist mit der neuen Realität abgefunden hatte, beschloss ich um Mitternacht herauszufinden, was normal passiert war. Ich begann mit der Ausarbeitung eines Dokuments mit einer detaillierten Untersuchung des Vorfalls ... und nannte es "Kapitel 11" [dies ist ein Kapitel aus dem Insolvenzgesetz - ca. pro.].
Die beiden Kollegen, die an dem Experiment teilnahmen, blieben auch die ganze Nacht wach und recherchierten und versuchten zu verstehen, was passiert war.
Am nächsten Morgen, Samstag, 28. März, rief ich an und schrieb Briefe an ein Dutzend Anwaltskanzleien, um einen Termin zu vereinbaren oder mit einem Anwalt zu sprechen. Sie waren alle weg, aber ich konnte eine Antwort von einem von ihnen per E-Mail erhalten. Da die Details des Vorfalls selbst für Ingenieure so komplex sind, war es an sich nicht einfach, ihn einem Anwalt in einfachem Englisch zu erklären.
Für uns als Start-up-Startup gab es keine Möglichkeit, 72.000 US-Dollar zurückzugewinnen.
Zu diesem Zeitpunkt hatte ich bereits das 7. und 11. Kapitel des Insolvenzrechts gründlich studiert und mich mental darauf vorbereitet, was als nächstes passieren könnte.
Einige Ruhepausen: GCP-Lücken
Nachdem ich am Samstag E-Mails an die Anwälte verschickt hatte, begann ich, jede Seite der GCP-Dokumentation zu lesen und durchzugehen. Wir haben Fehler gemacht, aber es hatte keinen Sinn, dass Google uns 72.000 US-Dollar dramatisch ausgeben ließ, wenn wir vorher keine Zahlungen geleistet hatten!
GCP und Firebase
1. Automatisches Upgrade eines Firebase-Kontos auf ein kostenpflichtiges Konto
Wir haben dies nicht erwartet und dies wurde bei der Registrierung bei Firebase nirgendwo davor gewarnt. Unsere GCP-Abrechnung wurde in die Ausführung von Cloud Run eingebunden, aber Firebase war Gegenstand eines kostenlosen Plans (Spark). GCP hat aus dem Nichts auf einen bezahlten Plan aktualisiert und uns den erforderlichen Betrag in Rechnung gestellt.
Es stellt sich heraus, dass sie diesen Prozess "tiefe Integration von Firebase und GCP" nennen.
2. Es gibt keine "Abrechnungslimits". Budgets verspäten sich um mindestens einen Tag
Die GCP-Abrechnung wird effektiv um mindestens 24 Stunden verzögert. In den meisten Dokumenten schlägt Google vor, Budgets und die Funktion zum automatischen Herunterfahren der Cloud zu verwenden. Zu dem Zeitpunkt, an dem die Abschaltfunktion ausgelöst oder eine Benachrichtigung an den Benutzer gesendet wird, ist der Schaden bereits angerichtet.
Die Abrechnungssynchronisierung dauert ungefähr einen Tag, weshalb wir die Abrechnung am nächsten Tag bemerkt haben.
3. Google hätte 100 Dollar nehmen sollen, nicht 72 Tausend!
Da bisher keine Zahlungen von unserem Konto getätigt wurden, musste GCP zunächst eine Gebühr von 100 US-Dollar gemäß den Zahlungsinformationen erheben. Wenn dies nicht der Fall war, wurde der Dienst eingestellt. Das ist aber nicht passiert. Ich habe den Grund später herausgefunden, aber das ist auch nicht die Schuld des Benutzers!
Die erste Rechnung für uns war ungefähr 5000 Dollar. Der nächste beträgt 72.000 US-Dollar.
Der Abrechnungsschwellenwert für unser Konto beträgt 100 US-Dollar
4. Verlassen Sie sich nicht auf Ihr Firebase-Dashboard!
Das Abrechnen, aber auch das Aktualisieren des Firebase-Dashboards dauerte über 24 Stunden.
Laut der Firebase Console-Dokumentation können die Nummern im Dashboard "geringfügig" von den Abrechnungsberichten abweichen.
In unserem Fall unterschieden sie sich um 86.585.365,85% oder 86 Millionen Prozentpunkte. Selbst als die Rechnung einging, wurden in der Firebase-Konsole immer noch 42.000 Lese- und Schreibvorgänge pro Monat angezeigt (unter dem Tageslimit).
Neuer Tag, neue Herausforderung
Nach sechseinhalb Jahren bei Google und dem Schreiben von Dutzenden von Projektdokumenten, Untersuchungsberichten und mehr begann ich, ein Dokument für Google zu schreiben, den Vorfall zu beschreiben und dem Bericht Google-Lücken hinzuzufügen. Das Google-Team wird in zwei Tagen wieder arbeiten.
Korrektur: Einige Leser haben vorgeschlagen, dass ich meine internen Google-Kontakte verwendet habe. Tatsächlich habe ich mit niemandem kommuniziert und den Weg gewählt, den ein normaler Entwickler oder ein normales Unternehmen einschlagen würde. Wie jeder andere kleine Entwickler habe ich unzählige Stunden damit verbracht, zu chatten, zu beraten, lange E-Mails zu verfassen und Fehler zu melden. In einem der folgenden Artikel zur Meldung von Vorfällen werde ich die Dokumente anzeigen, die ich bei Google eingereicht habe.
Letzter Tag bei Google
Außerdem war es notwendig, unsere Fehler zu verstehen und eine Produktentwicklungsstrategie zu entwickeln. Nicht jeder im Team wusste von dem Vorfall, aber es war ziemlich klar, dass wir in großen Schwierigkeiten waren.
Bei Google habe ich Millionen von Dollar an menschlichem Versagen festgestellt, aber die Google-Kultur rettet Mitarbeiter (außer dass Ingenieure später lange Berichte schreiben müssen). Diesmal gab es kein Google. Unser eigenes kleines Kapital und unsere harte Arbeit stehen auf dem Spiel.
Der standhafte Himalaya sagt uns ...
Dies war das erste Mal, dass ich einen solchen Schlag bekam. Dies könnte die Zukunft unseres Unternehmens und meines Lebens verändern. Dieser Vorfall brachte mir mehrere Geschäftslektionen bei, darunter die wichtigste - einen Treffer zu erzielen.
Zu dieser Zeit hatte ich ein Team von sieben Ingenieuren und Praktikanten, und Google brauchte ungefähr zehn Tage, um uns über diesen Vorfall zu antworten. In der Zwischenzeit mussten wir die Entwicklung wieder aufnehmen und einen Weg finden, um die Sperrung von Konten zu umgehen. Trotz allem mussten wir uns auf die Funktionen und unser Produkt konzentrieren.
Gedicht "The Stalwart Himalayas Tell Us"
Aus irgendeinem Grund drehte sich ständig ein Gedicht aus meiner Kindheit in meinem Kopf. Es war mein Lieblingsbuch, und ich erinnerte mich Wort für Wort daran, obwohl ich es das letzte Mal vor mehr als 15 Jahren gelesen hatte.
Was haben wir eigentlich gemacht?
Als sehr kleines Team wollten wir die Ausgaben für Hardware so lange wie möglich vermeiden. Das Problem mit den Cloud-Funktionen und dem Cloud-Lauf war eine Zeitüberschreitung.
Eine Instanz entfernt kontinuierlich URLs von der Seite. Aber nach 9 Minuten wird es eine Zeitüberschreitung geben.
Nachdem ich das Problem beiläufig besprochen hatte, notierte ich in ein paar Minuten den Rohcode auf der Tafel. Jetzt wurde mir klar, dass dieser Code viele architektonische Mängel aufwies, aber dann strebten wir schnelle Fehlerbehebungszyklen an, um schnell neue Dinge zu lernen und auszuprobieren.
Announce-AI-Konzept bei Cloud Run
Um die Zeitlimitbeschränkung zu überwinden, schlug ich vor, POST-Anforderungen (mit einer URL als Daten) zu verwenden, um Jobs an eine Instanz zu senden und - mehrere Instanzen parallel zu starten, anstatt sich für eine in die Warteschlange zu stellen. Da jede Instanz in Cloud Run nur eine Seite verschrottet, gibt es nie eine Zeitüberschreitung, alle Seiten werden parallel verarbeitet (gut skalierbar) und der Prozess ist stark optimiert, da Cloud Run mit Millisekundengenauigkeit verbraucht wird.
Cloud Run Scraper
Wenn Sie genau hinschauen, fehlen dem Prozess einige wichtige Details.
- Es tritt eine kontinuierliche exponentielle Rekursion auf: Die Instanzen wissen nicht, wann sie gestoppt werden sollen, da keine break-Anweisung vorhanden ist.
- POST-Anfragen können dieselbe URL haben. Wenn es einen Link zurück zur vorherigen Seite gibt, bleibt der Cloud Run-Dienst in einer unendlichen Rekursion stecken, aber am schlimmsten ist, dass diese Rekursion exponentiell multipliziert wird (die maximale Anzahl von Instanzen wurde auf 1000 festgelegt!).
Wie Sie sich vorstellen können, hat dies dazu geführt, dass 1000 Instanzen alle paar Millisekunden Anforderungen stellen und in Firebase DB schreiben. Wir haben gesehen, dass an einem Punkt ungefähr 1 Milliarde Anfragen pro Minute durch Firebase-Lesevorgänge gingen!
GCP-Monatsendtransaktionszusammenfassung
116 Milliarden Lesevorgänge und 33 Millionen Schreibvorgänge
Die experimentelle Version unserer App auf Cloud Run hat 116 Milliarden Lese- und 33 Millionen Schreibvorgänge im Firestore durchgeführt. Oh!
Firebase-Lesekosten:
$ (0,06 / 100.000) * 116.000.000.000 = $ 69.600
16.000 Cloud-Betriebsstunden
Nach dem Testen kamen wir nach dem Stoppen der Protokolle zu dem Schluss, dass die Anforderung gestorben ist, aber tatsächlich in einen Hintergrundprozess übergegangen ist. Da wir die Dienste nicht deinstalliert haben (wir haben Cloud Run zum ersten Mal verwendet und es damals nicht wirklich verstanden), wurden einige Dienste weiterhin langsam ausgeführt.
Innerhalb von 24 Stunden liefen alle diese Dienste auf 1.000 Instanzen insgesamt 16.022 Stunden.
Alle unsere Fehler
Stellen Sie den fehlerhaften Algorithmus in der Cloud bereit
Wurde bereits oben besprochen. Wir haben eine neue Möglichkeit gefunden, serverlose POST-Anforderungen zu verwenden, die ich sonst nirgendwo im Internet gefunden habe, aber wir haben sie bereitgestellt, ohne den Algorithmus anzugeben.
Stellen Sie Cloud Run mit Standardparametern bereit
Bei der Erstellung des Cloud Run-Dienstes haben wir die Standardwerte dafür ausgewählt. Die maximale Anzahl von Instanzen beträgt 1000 und die Parallelität beträgt 80 Anforderungen. Uns war nicht bewusst, dass diese Werte tatsächlich das Worst-Case-Szenario für das Testprogramm sind.
Wenn wir max-instance = 2 wählen würden, wären die Kosten 500-mal geringer.
Wenn wir Parallelität = 1 setzen, würden wir die Punktzahl nicht einmal bemerken.
Verwenden von Firebase ohne volles Verständnis
Sie verstehen nur etwas aus Erfahrung. Firebase ist keine Sprache zum Lernen, sondern eine Containerplattform. Die Regeln werden von einem bestimmten Google-Unternehmen festgelegt.
Außerdem müssen Sie beim Schreiben von Node.js-Code über Hintergrundprozesse nachdenken. Wenn der Code in Hintergrundprozesse eingeht, kann der Entwickler nicht leicht erkennen, dass der Dienst ausgeführt wird. Wie wir später erfuhren, verursachte dies auch die meisten Zeitüberschreitungen für unsere Cloud-Funktionen.
Schnelle Fehler und schnelle Lösungen sind in der Cloud eine schlechte Idee
Die Wolke als Ganzes ist wie ein zweischneidiges Schwert. Wenn es richtig verwendet wird, kann es sehr nützlich sein, aber wenn es falsch verwendet wird, beschuldigen Sie sich.
Wenn Sie die Anzahl der Seiten in der GCP-Dokumentation zählen, können Sie mehrere dicke Bände veröffentlichen. Es braucht viel Zeit und ein tiefes Verständnis der Funktionsweise von Cloud-Diensten, um alles zu verstehen, einschließlich Abrechnung und Nutzung von Funktionen. Es überrascht nicht, dass dafür einzelne Vollzeitmitarbeiter eingestellt werden!
Firebase und Cloud Run sind wirklich mächtig
In seiner Blütezeit verarbeitet Firebase etwa eine Milliarde Lesevorgänge pro Minute. Dies ist ein äußerst leistungsfähiges Werkzeug. Wir spielen jetzt seit zwei oder drei Monaten mit Firebase - und entdecken immer noch neue Aspekte, aber bis dahin hatte ich keine Ahnung, wie leistungsfähig dieses System ist.
Gleiches gilt für Cloud Run! Wenn Sie die Anzahl der parallelen Prozesse auf 60, max_containers == 1000, festlegen, kann Cloud Run bei Anforderungen von 400 ms 9 Millionen Anforderungen pro Minute verarbeiten!
60 * 1000 * 2,5 * 60 = 9.000.000 Anfragen pro Minute
Im Vergleich dazu verarbeitet die Google-Suche 3,8 Millionen Anfragen pro Minute.
Verwenden Sie die Überwachung
Obwohl Google Cloud Monitoring die Abrechnung nicht beendet, werden zeitnahe Benachrichtigungen gesendet (Verzögerung von 3-4 Minuten). Es ist zunächst nicht einfach, die Google Cloud-Terminologie zu verstehen. Wenn Sie sich jedoch die Zeit nehmen, erleichtern Ihnen das Dashboard, die Warnungen und die Messdaten das Leben ein wenig.
Diese Metriken sind nur 90 Tage lang verfügbar und wurden bei uns nicht gespeichert.
Wir überlebten
Fuh, mitgerissen
Nachdem Google unseren langen Vorfallbericht, der die Situation von unserer Seite beschreibt, nach verschiedenen Konsultationen, Gesprächen und internen Diskussionen geprüft hatte, vergab uns die Kosten!
Danke Google!
Wir schnappten uns einen Rettungsring und nutzten diese Gelegenheit, um die Produktentwicklung abzuschließen. Diesmal mit viel besserer Planung, Architektur und viel sicherer Implementierung.
Google, mein bevorzugtes Technologieunternehmen, ist nicht nur ein großartiges Unternehmen, mit dem ich zusammenarbeiten kann. Es ist auch eine großartige Firma, mit der man zusammenarbeiten kann. Google Tools ist sehr entwicklerfreundlich, verfügt (größtenteils) über eine hervorragende Dokumentation und wird ständig weiterentwickelt.
(Hinweis: Dies ist meine persönliche Meinung als einzelner Entwickler. Unser Unternehmen ist in keiner Weise gesponsert oder mit Google verbunden.)
Was weiter?
Nach diesem Vorfall haben wir mehrere Monate damit verbracht, die Cloud und unsere Architektur zu untersuchen. Innerhalb weniger Wochen hatte sich mein Verständnis so sehr verbessert, dass ich die Kosten für das Scraping "des gesamten Internets" mit Cloud Run mit einem verbesserten Algorithmus abschätzen konnte.
Der Vorfall zwang mich, die Architektur unseres Produkts gründlich zu analysieren, und wir haben die in der ersten Version aufgegeben, um eine skalierbare Infrastruktur aufzubauen.
In der zweiten Version von Announce haben wir nicht nur ein MVP erstellt, sondern auch eine Plattform, auf der wir neue Produkte in schnellen Iterationen entwickeln und in einer sicheren Umgebung gründlich testen können.
Diese Reise hat lange gedauert ... AnkündigenEs wurde Ende November, etwa sieben Monate nach der ersten Version, gestartet, ist jedoch hoch skalierbar, nutzt das Beste aus der Cloud und ist hoch optimiert.
Wir haben auch auf allen Plattformen gestartet, nicht nur im Internet.
Darüber hinaus haben wir die Plattform erneut verwendet, um unser zweites Produkt, Point Address, zu erstellen . Es bietet auch Skalierbarkeit und gute Architektur.