Horrorgeschichten der Serverless-Technologie

 (serverlesshorrors.com)
2 Punkte von GN⁺ 2024-03-01 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Website, die anhand realer Fälle zeigt, welches Risiko explodierender Kosten hinter der Bequemlichkeit nutzungsbasierter Abrechnung steckt
  • Unerwartete Rechnungen bei Cloudflare, Vercel, AWS, Firebase, Netlify, BigQuery und anderen lassen sich nach Dienst und Ursache vergleichen
  • Auch kleine Projekte oder persönliche Services können in kürzester Zeit zu hohen Rechnungen führen, etwa $36,000 bei Cloudflare, $46,485.99 bei Vercel oder $100,000 Firebase-Kosten an einem Tag
  • Wiederkehrende Ursachen sind Bandbreite, DDoS/DoS, Storage, fehlerhafte Implementierung, Rekursion, Queue-Loops sowie steigende Nutzung durch Events, Bilder, Dokumentation und KI
  • Wer Serverless- und Pay-as-you-go-Dienste nutzt, sollte Abrechnungslimits, Cache, Request-Muster und Automatisierungs-Loops vor und nach dem Deployment prüfen

Charakter der Website und Einreichung von Fällen

  • ServerlessHorrors ist ein einfacher Blog, in dem man Fälle von Abrechnungs- und ausfallähnlichen Problemen beim Einsatz von Serverless lesen kann
  • Der Macher ist Andras, der an Coolify, Jean und mehreren weiteren Open-Source-Projekten sowie an coolLabs-bezogenen Arbeiten beteiligt ist
  • Fallmeldungen werden über zwei Wege entgegengenommen

Repräsentative Fälle mit hohen Rechnungen

  • $36,000: Das Nebenprojekt RetainDB erhielt bei 81 Nutzern eine Cloudflare-Rechnung über $36k
    • Ursache waren 16B Durable Object writes, ein runaway queue loop, nicht gebatchte Durable Object writes und ein bei jedem Request ausgeführter KV list scan
    • Tags: cloudflare, workers, durable-objects, kv, queues
  • $46,485.99: Jmail überschritt 450M pageviews, und selbst nach vielen Cache-Entlastungen stieg die Vercel-Rechnung auf $46k
    • Tags: vercel, bandwidth
  • $100,000.420: Eine einigermaßen beliebte Upload-Website für WebGL-Spiele wurde von einem DoS getroffen, wodurch an einem Tag Firebase-Kosten von $100k anfielen
    • Tags: google, storage, firebase
  • $120,000.420: Ein Fall, in dem Cloudflare versuchte, innerhalb von 24 Stunden $120k einzufordern, und anschließend die Website abschaltete
    • Tags: cloudflare, bandwidth
  • $104,500.123: Ein Fall, in dem eine E-Mail von Netlify über eine überfällige Rechnung von $104,500.00 einging
    • Tags: netlify, bandwidth, ddos
  • $96,280.69: Ein Fall einer hohen Rechnung im Zusammenhang mit Vercel bandwidth
    • Tags: vercel, bandwidth, new
  • $72,000.999: Ein Fall, in dem ein Test mit Firebase + Cloud Run $72K verbrannte und fast zur Pleite führte
    • Tags: google, firebase, cloudrun, wrong-implementation, recursion
  • $70,000.69: Bei einem Projekt, das zuvor $50 pro Monat kostete, kam eines Tages eine Rechnung über $70,000
    • Tags: google, storage, firebase, gcs

Weitere erfasste Fälle nach Dienst

  • $23,000.420: EchoFox wurde mit Spam getroffen, die Vercel-Rechnung schoss auf $23k hoch, und es entstanden 56k+ accounts and trials
    • Tags: vercel, bandwidth, ddos
  • $22.639,69: Allein die Nutzung eines öffentlichen Datasets im BigQuery playground führte zu einer Rechnung über 22k USD
    • Tags: google, bigquery, sql
  • $11,000.69: Während eines DoS-Angriffs wurden E-Mails im Wert von $11k versendet, und die Datenbank ging verloren
    • Tags: ddos, mailgun
  • $4,241.69: Ein Fall, in dem der Dienst pausiert wurde, AWS ihn jedoch blockierte und trotzdem Kosten bezahlt werden mussten
    • Tags: aws
  • $3,000.69: Ein Fall, der zur Vorsicht beim Testen oder Deployen auf Vercel mahnt
    • Tags: vercel, bandwidth, wrong-implementation
  • $1,300.69: Kosten entstanden, nachdem ein leerer und privater AWS S3 bucket in der gewünschten Region erstellt worden war
    • Tags: aws, s3, security, ddos
  • $1273.69: Nach der Bitte an Devin AI, Änderungen an der Codebase vorzunehmen, entstanden PostHog-Kosten
    • Tags: posthog, devin, ai, cognition-labs, new
  • ~$1189.420/month: Bei einem Plan für $69/month berechnete Webflow in einem einzigen Monat $1189.420
    • Tags: webflow, bandwidth, image
  • $738.420: Trotz Vercel-Pro-Abo für $20 pro Monat und zusätzlichem $120 spending limit kam es zu einer Rechnung
    • Tags: vercel, bandwidth, vercels-mistake, spending-limit
  • $620.123: Ein Vercel-Fall, bei dem sitemap.txt Hunderte GB/hours verbrauchte
    • Tags: vercel, bandwidth
  • $530.19: Ein PostHog-Fall, bei dem nie zuvor Kosten angefallen waren und plötzlich $530 berechnet wurden
    • Tags: posthog, events, new
  • $400.69: Cloudflare Images berechnete statt der erwarteten $110 monatlich $400; hinzu kamen verwirrende Prepaid-Abrechnung und mehr als acht Monate ohne Support
    • Tags: cloudflare, images, billing
  • $383.69: Ein Mintlify-Fall mit einer Rechnung von fast $400 für eine Dokumentationswebsite
    • Tags: mintlify, ai, documentation
  • $250/month: Für 9,000 page visits wurden $250 pro Monat bzw. $3,000 pro Jahr erforderlich
    • Tags: framer, bandwidth, images and videos
  • $103.26: Ein AWS-Fall, in dem $103 trotz Nutzung des free tier zur Horrorgeschichte wurden
    • Tags: aws, dark-pattern, free-tier

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-01
Meinungen auf Hacker News

  • Wirklich bedauerlich, und es fühlt sich eher wie ein Rückschritt an. Eine 3,44-MB-Datei sollte kein Problem sein, und selbst wenn sie eines ist, sollte „lade sie woanders hoch“ nicht die Antwort sein.
    Wenn es hier eine Lehre gibt, dann die, dass es nichts umsonst gibt, und dass sich solche großen Schäden durch irgendeine Form von Limits verhindern lassen müssen. VPS sind sehr günstig und leicht zu verwalten, und es gibt auch automatische Limits: https://lowendbox.com/blog/1-vps-1-usd-vps-per-month/

    • Die Leute fragen sich, warum es heute nur noch ein paar Websites gibt und der Long Tail verschwunden ist: weil man bei Facebook oder Twitter 3,44 MB Audio hochladen kann, ohne jemals Angst vor einer Rechnung haben zu müssen.
    • Dass ein VPS „leicht zu verwalten“ sei, ist eine ziemlich starke Option, die auf vielen Annahmen beruht.

  • Ich glaube nicht, dass der Netlify-Fall durch Serverless-Architektur verursacht wurde. Serverless hat viele technische Probleme, aber das Problem, wegen eingehendem Traffic eine hohe Rechnung zu bekommen, ist unabhängig von Serverless.
    Selbst wenn man eigene Hardware in Colocation betreibt und Traffic-Kosten bezahlt, kann dasselbe passieren, wenn das Rechenzentrum DDoS nicht abwehrt und nach TB abrechnet. Natürlich ist Colocation pro TB viel günstiger als Netlify, sodass eine Rechnung über 100.000 Dollar weniger wahrscheinlich ist. Dann sollte der Kern aber nicht „Serverless-Horror“ sein, sondern absurd teure Traffic-Kosten und fehlende DDoS-Abwehr.

    • Wenn ein Dienst unbegrenzt skaliert, skaliert auch die Geschwindigkeit, mit der Geld verbrannt wird, unbegrenzt. Ein einzelner Server in Colocation ist irgendwann gesättigt, und damit ist auch der Schaden begrenzt, den er dem Geldbeutel zufügen kann.

  • Andres, der dieses Blog erstellt hat, entwickelt auch coolify, eine Self-Hosting-Alternative zu Heroku/Netlify. Nachdem ich es seit ein paar Monaten nutze, war es so etwas wie die geheime Zutat, die Self-Hosting von Dingen wie changedetector, jdownloader und vaultwarden einfach macht.
    Auch die Community wächst ziemlich gut: Leute steuern neue Templates bei und helfen sich gegenseitig beim Debugging. Ich habe auch versucht, ein Syncthing-Template hinzuzufügen. Allerdings ging einiges kaputt, als auf einer Instanz mit 10 GB Speicherplatz die Festplatte voll lief; hier wären bessere Benachrichtigungen oder Vorbeugung wünschenswert. Abgesehen davon ist es ziemlich stabil.
    https://github.com/coollabsio/coolify

  • Vielleicht ist das eine Überreaktion, aber ich habe beschlossen, meine persönliche Website von Netlify wegzuziehen. Ich brauchte nicht mehr als einen Ort, an dem ich HTML ablegen kann, und dachte, Netlify sei „gut genug“, wusste aber nicht, dass es solche Probleme gibt.
    Die kürzlich betroffene Website fühlte sich für mich besonders real an, weil sie meiner eigenen bei täglichen Besuchern, Bekanntheit und Nischencharakter ähnelte. Ich bevorzuge es, HTML lokal zu bauen und irgendwo hochzuladen, daher reicht für den Umzug im Grunde ein DNS-Update. Merkwürdig fand ich, dass die meisten beliebten Optionen wie Netlify, Vercel und Cloudflare keine echten Ausgabenlimits anbieten. Das wirkt wie eine sehr grundlegende Funktion.

    • Cloudflare Pages hat unbegrenzte kostenlose Bandbreite, der Traffic ist also kostenlos, und deshalb braucht es kein Limit.
    • Ich arbeite bei Vercel, und Vercel hat DDoS-Schutz sowie Ausgabenlimits. Wir arbeiten daran, für beides bald weitere Verbesserungen zu veröffentlichen.
      https://vercel.com/blog/introducing-spend-management-realtime...
    • Cloudflare hat DDoS-Schutz, und man kann ihn fast schon paranoid konfigurieren. Wenn ein DDoS beginnt, kann man dafür sorgen, dass allen ein CAPTCHA angezeigt wird, was die Ausgaben ziemlich effektiv begrenzt.

  • Auch der in einem der Reddit-Posts verlinkte Netlify-Kommentar-Thread ist lesenswert: https://answers.netlify.com/t/limit-bandwidth-to-avoid-high-...
    Ein Netlify-Vertreter sagt dort ausdrücklich, dass sie selbst im Free Tier nichts tun werden, um im Fall eines DDoS eine absurde Bandbreitenrechnung zu verhindern.

    • Was mir an solchen Diensten am meisten missfällt, ist, dass es keine Funktion gibt, die einem Stop-Loss entspricht. Man kann Benachrichtigungen einrichten, dann wird man informiert, aber das war’s; in vielen Fällen kommt die Warnung erst lange nach dem Schaden.
      Bei manchen Abrechnungsmetriken verzögern sich Berichte oder Alerts um Stunden. Die Standardeinstellungen sollten sicher sein, und Limits sollten sich leicht anheben lassen.
    • Früher wurde einfach der Server heruntergefahren; heute bekommt man für eine Serverless-Website nach einem DDoS eine Rechnung über 100.000 Dollar.
      Ich weiß nicht, ob dieses Geschäftsmodell nachhaltig ist. Als man den Server noch besaß, konnte man den Stecker ziehen, aber heute hat man keine Möglichkeit zu wissen, ob jemand /api millionenfach pro Minute aufruft.
    • Kann man nicht den Free Tier unter einem falschen Namen nutzen und eine absurde Rechnung einfach liegen lassen? Ich frage mich, wie sie Kunden verifizieren.
    • Ich frage mich, ob so etwas passiert, weil Netlify in finanziellen Schwierigkeiten steckt. Früher war Netlify ein sehr guter und einzigartiger Dienst, aber inzwischen bieten GitHub, GitLab und Cloudflare Pages fast denselben Service günstiger an.
    • Was soll man tun, wenn so etwas im Free Tier passiert? Einfach die Rechnung nicht bezahlen und gehen? Kommen die wirklich mit Inkasso?

  • Wenn ein Cloud-Anbieter etwas, das er abrechnen darf, übermäßig in Rechnung stellt, fühlt sich das ungefähr so an, als würde ein Automechaniker bei einer Routineinspektion feststellen, dass ein kleines Teil kaputt ist, dann gehen aus demselben Grund auch die Ersatzteile immer wieder kaputt, er tauscht sie in einer Endlosschleife aus, gibt zwei Wochen lang keinerlei Information, und als ich schließlich in die Werkstatt gehe und sage, er solle aufhören, stellt er mir am Ende 999.999.999 kaputte Teile in Rechnung.
    Als kleiner Nutzer, nicht als große Organisation, kann man nicht jede einzelne Steuerungs-Dokumentation bis in den letzten Winkel lesen. Ich möchte ein festes Limit, das beim Erreichen einer vorgegebenen Ausgabengrenze alles abschaltet, notfalls sogar unter Datenverlust. Aber wenn Nutzer vorsichtig mit ihrem Budget umgehen, schadet das dem Umsatz; außerdem kann es Fälle geben, in denen sich die Rechnung im Voraus schwer berechnen lässt. Deshalb machen sie es offenbar nicht.

    • Es gibt Unterschiede. Der Mechaniker im Beispiel hat die Situation selbst geschaffen, Netlify dagegen nicht; außerdem kann es schwierig sein, unerwünschten Traffic von einem SaaS zu unterscheiden, das über Nacht erfolgreich wurde.
      Eine genauere Analogie wäre: Man sagt dem Mechaniker, er solle alles tun, was jemand verlangt, der das Kennzeichen kennt, und der Mechaniker führt das dann genau so aus.

  • Ich habe kürzlich einen OpenAI-API-Key erstellt; standardmäßig erzwingt er eine Quota und deaktiviert den Key, wenn das Limit erreicht ist. Wenn man bereit ist, mehr Requests zu verarbeiten, erhöht man die Quota manuell.
    Es ist erstaunlich, dass nicht mehr Unternehmen das standardmäßig so machen, um solche überraschenden Rechnungen zu verhindern. Wenn man darüber nachdenkt, liegt es vielleicht daran, dass Nutzer am Ende oft einfach zahlen.

    • Der Unterschied ist, dass bei OpenAI tatsächlich Inferenzkosten anfallen und OpenAI daher ein eigenes Interesse daran hat. Wenn Netlify für Bandbreite das 1000-Fache berechnet, entstehen für die Bereitstellung des Dienstes kaum Kosten; es könnte ihnen also tatsächlich ziemlich egal sein, wenn der Nutzer nicht zahlt.

  • Der größte Cloud-Horror ist vielleicht gar nicht Serverless, sondern dass wir akzeptiert haben, Kosten für Traffic zwischen Availability Zones zu zahlen, mit der Begründung, man müsse sich gegen Ausfälle beim Cloud-Anbieter absichern.
    Anders gesagt: Der Anbieter stellt uns in erheblichem Umfang Kosten dafür in Rechnung, Probleme abzufedern, die auf seiner Seite auftreten könnten.

  • In diesem Thread sagen alle, das sei kein Serverless-Problem, sondern ein Cloud-Problem. Das stimmt, aber der Kern bleibt bestehen: Bandbreite ist fast reine Marge, und es wirkt ziemlich schäbig, Bandbreite so teuer abzurechnen und gleichzeitig keine Werkzeuge bereitzustellen, um auf Angriffe außerhalb der Kontrolle des Kunden zu reagieren.
    Laut diesem Thread bietet Netlify nicht einmal die Möglichkeit, eine Site während eines DDoS-Angriffs vorübergehend offline zu nehmen: https://answers.netlify.com/t/limiting-bandwidth-traffic-to-...
    Netlify könnte verschiedene Lösungen haben: Billing-Kontrollen, Request-Limits, Bandbreitenlimits oder bei einem echten DDoS das Erlassen der Überschreitungen. Aber das würde die Gans töten, die goldene Eier legt, und offenbar besteht kein Interesse daran. Schon ein Blick auf die Funktionen, die das bunny.net CDN anbietet, zeigt den Unterschied: https://support.bunny.net/hc/en-us/articles/360014190440-Und...
    Es ist enttäuschend, wie leicht wir die Erklärungen der Cloud-Anbieter akzeptieren, obwohl sie sich schwer anders als mit Gier erklären lassen.

  • Warum ist das Fehlen eines Ausgabenlimits ein Serverless-Problem? Das ist ein Cloud-Problem.
    Allerdings kann ein kleiner Cloud-Server bei einem Angriff ausfallen, und wenn wie bei AWS nur ausgehender Traffic berechnet wird, ist das für den Nutzer vorteilhaft.

    • Weil Serverless häufiger als traditionelle Modelle nutzungsbasierte Abrechnung verwendet und sich außerdem besser bis zu sehr großer Nutzung hochskalieren lässt.
      Wenn jemand meinen DigitalOcean-VPS für 5 Dollar im Monat per DDoS angreift, steigen meine Compute-Kosten nicht, und wahrscheinlich bricht er unter der Last zusammen, bevor sich die Transferkosten stark aufsummieren. Zwar ist auch der Transfer bei DigitalOcean nutzungsbasiert, aber die Grenze wäre vorher erreicht.
    • Das ist kein Cloud-Problem. Cloud ist am Ende nur der Computer von jemand anderem.
      Das ist ein Abrechnungsproblem oder ein Architekturproblem. Man sollte Requests begrenzen können, um Überberechnung zu verhindern, oder bei Erreichen eines bestimmten Betrags abgeschaltet werden.
    • Das ist ein Architekturversagen. Maximalwerte zu setzen ist wichtig. Wenn man eine Plattform wählt, die solche Funktionen nicht unterstützt, trägt man auch selbst Verantwortung.
      In traditionellen Umgebungen ist es implizit einfacher, Circuit Breaker einzubauen, aber man muss es trotzdem unbedingt berücksichtigen. Man sollte Lasttests sowohl für Erfolg als auch für Scheitern durchführen.
    • Der Grund, warum das Fehlen eines Ausgabenlimits ein Serverless-Problem ist: Bei Cloud kann man es abmildern, bei Serverless nicht.
      Da ich Cloud-Instanzen nutze, habe ich dieses Problem nicht und werde es auch künftig nicht haben. Wäre ich auf Serverless gewesen, hätte ich dieses Problem gehabt.