Les histoires d’horreur des technologies serverless

 (serverlesshorrors.com)
2 points par GN⁺ 2024-03-01 | 1 commentaires | Partager sur WhatsApp
  • Un site qui rassemble des cas réels montrant le risque d’explosion des coûts caché derrière la commodité de la facturation à l’usage
  • Il permet de comparer des factures inattendues survenues chez Cloudflare, Vercel, AWS, Firebase, Netlify, BigQuery, etc., par service et par cause
  • Des montants comme $36,000 chez Cloudflare, $46,485.99 chez Vercel ou une facture quotidienne de $100,000 sur Firebase montrent que même de petits projets ou services personnels peuvent très vite déboucher sur des sommes énormes
  • Les causes récurrentes sont la bande passante, les attaques DDoS/DoS, le stockage, de mauvaises implémentations, la récursion, les boucles de file d’attente, ainsi que la hausse d’usage liée aux événements, aux images, à la documentation et à l’IA
  • Lorsqu’on utilise des services serverless et à la consommation, il faut vérifier avant et après déploiement les plafonds de facturation, le cache, les schémas de requêtes et les boucles d’automatisation

Nature du site et mode de signalement

  • ServerlessHorrors est un blog simple qui rassemble et présente des cas de facturation excessive ou d’incidents survenus lors de l’usage du serverless
  • Son créateur est Andras, qui travaille sur plusieurs projets open source comme Coolify, Jean, ainsi que sur des travaux liés à coolLabs
  • Les signalements de cas sont acceptés par deux voies

Cas emblématiques ayant mené à des factures massives

  • $36,000 : le side project RetainDB a reçu une facture Cloudflare de $36k alors qu’il comptait 81 utilisateurs
    • Causes : 16B Durable Object writes, runaway queue loop, Durable Object writes non batchés, KV list scan exécuté à chaque requête
    • Tags : cloudflare, workers, durable-objects, kv, queues
  • $46,485.99 : Jmail a dépassé 450M pageviews et, malgré de nombreuses atténuations de cache, la facture Vercel est montée à $46k
    • Tags : vercel, bandwidth
  • $100,000.420 : un site d’upload de jeux WebGL assez populaire a subi un DoS, faisant grimper la facture Firebase à $100k en une journée
    • Tags : google, storage, firebase
  • $120,000.420 : cas où Cloudflare a tenté d’exiger $120k en moins de 24 heures avant de mettre le site hors ligne
    • Tags : cloudflare, bandwidth
  • $104,500.123 : cas d’un e-mail de relance Netlify réclamant $104,500.00 d’impayés
    • Tags : netlify, bandwidth, ddos
  • $96,280.69 : cas d’une facture très élevée liée à la bande passante chez Vercel
    • Tags : vercel, bandwidth, new
  • $72,000.999 : un test avec Firebase + Cloud Run a brûlé $72K et a presque mené à la faillite
    • Tags : google, firebase, cloudrun, wrong-implementation, recursion
  • $70,000.69 : un projet qui payait $50 par mois a reçu un jour une facture de $70,000
    • Tags : google, storage, firebase, gcs

Autres cas recensés par service

  • $23,000.420 : EchoFox a subi du spam, la facture Vercel a bondi à $23k et 56k+ accounts and trials ont été générés
    • Tags : vercel, bandwidth, ddos
  • $22.639,69 : une utilisation d’un dataset public dans BigQuery playground a suffi à entraîner une facture de 22k USD
    • Tags : google, bigquery, sql
  • $11,000.69 : pendant une attaque DoS, pour l’équivalent de $11k d’e-mails ont été envoyés et la base de données a été perdue
    • Tags : ddos, mailgun
  • $4,241.69 : cas où le service a été suspendu, mais AWS l’a bloqué tout en exigeant le paiement des coûts
    • Tags : aws
  • $3,000.69 : un cas rappelant qu’il faut être prudent lors des tests ou des déploiements sur Vercel
    • Tags : vercel, bandwidth, wrong-implementation
  • $1,300.69 : des coûts ont été engendrés après la création d’un bucket AWS S3 vide et privé dans la région souhaitée
    • Tags : aws, s3, security, ddos
  • $1273.69 : des coûts PostHog ont été générés après avoir demandé à Devin AI de modifier la base de code
    • Tags : posthog, devin, ai, cognition-labs, new
  • ~$1189.420/month : avec une offre à $69/month, Webflow a facturé $1189.420 sur un seul mois
    • Tags : webflow, bandwidth, image
  • $738.420 : malgré un abonnement Vercel Pro à $20/mois et une spending limit supplémentaire de $120, une facture a quand même été émise
    • Tags : vercel, bandwidth, vercels-mistake, spending-limit
  • $620.123 : cas Vercel où sitemap.txt a consommé des centaines de GB/hours
    • Tags : vercel, bandwidth
  • $530.19 : cas PostHog où aucun coût n’avait jamais été payé auparavant, puis $530 ont soudainement été facturés
    • Tags : posthog, events, new
  • $400.69 : Cloudflare Images a facturé $400 par mois au lieu des $110 attendus, avec en plus une facturation prépayée déroutante et plus de 8 mois sans support
    • Tags : cloudflare, images, billing
  • $383.69 : cas Mintlify avec près de $400 facturés pour un site de documentation
    • Tags : mintlify, ai, documentation
  • $250/month : 9,000 page visits ont fini par nécessiter $250 par mois, soit $3,000 par an
    • Tags : framer, bandwidth, images and videos
  • $103.26 : un cas AWS où $103, malgré l’usage du free tier, est devenu une histoire d’horreur
    • Tags : aws, dark-pattern, free-tier

À lire aussi

1 commentaires

 
GN⁺ 2024-03-01
Avis sur Hacker News

  • C’est vraiment regrettable, et on a même l’impression de revenir en arrière. Un fichier de 3,44 Mo ne devrait pas poser problème, et même si c’était le cas, la réponse ne devrait pas être « hébergez-le ailleurs ».
    S’il y a une leçon à tirer ici, c’est que la gratuité n’existe pas, et qu’une perte aussi importante devrait pouvoir être bloquée d’une manière ou d’une autre par des limites. Les VPS sont très bon marché, faciles à administrer, et disposent aussi de limites automatiques : https://lowendbox.com/blog/1-vps-1-usd-vps-per-month/

    • Les gens se demandent pourquoi il ne reste plus que quelques sites web et que la longue traîne a disparu, mais c’est parce que sur Facebook ou Twitter, on peut mettre en ligne un audio de 3,44 Mo sans jamais avoir à craindre une facturation
    • Dire qu’un VPS est « facile à administrer », c’est une position assez tranchée qui repose sur pas mal de présupposés

  • Je ne pense pas que le cas Netlify soit dû à une architecture serverless. Le serverless a beaucoup de problèmes techniques, mais le fait de recevoir une énorme facture à cause du trafic entrant est indépendant du serverless.
    Même si on met son propre matériel en colocation et qu’on paie les frais de trafic, la même chose peut arriver si le datacenter n’atténue pas un DDoS et facture au téraoctet. Bien sûr, en colocation, le prix par To est bien inférieur à celui de Netlify, donc une facture de 100 000 dollars est moins probable, mais dans ce cas le vrai sujet ne devrait pas être « l’horreur du serverless », mais plutôt le coût du trafic absurdement élevé et l’absence d’atténuation DDoS

    • Si un service peut monter en charge à l’infini, alors la vitesse à laquelle l’argent brûle peut elle aussi monter à l’infini. Un serveur unique en colocation, lui, finit par saturer, ce qui limite aussi les dégâts possibles pour le portefeuille

  • Andres, qui a créé ce blog, développe aussi coolify, une alternative auto-hébergée à Heroku/Netlify. Après plusieurs mois d’utilisation, ça a été pour moi une sorte d’arme secrète qui simplifie l’auto-hébergement de choses comme changedetector, jdownloader et vaultwarden.
    La communauté grandit plutôt bien aussi : les gens contribuent de nouveaux templates et s’entraident pour le débogage. J’ai moi-même ajouté un template Syncthing. En revanche, quand le disque s’est rempli sur une instance avec 10 Go de stockage, plusieurs choses se sont effondrées, et j’aimerais que les alertes ou la prévention soient meilleures sur ce point. À part ça, c’est plutôt stable.
    https://github.com/coollabsio/coolify

  • C’est peut-être une surréaction, mais j’ai décidé de déplacer mon site personnel de Netlify. Je n’avais besoin de rien de plus qu’un endroit où déposer du HTML, et je pensais que Netlify était « suffisamment bien », mais je ne savais pas qu’il pouvait y avoir ce genre de problème.
    Le site touché récemment m’a paru d’autant plus concret qu’il ressemble au mien en nombre de visiteurs quotidiens, en notoriété et en caractère de niche. Je préfère construire le HTML en local puis le publier quelque part, donc la migration en elle-même se résume à peu près à une mise à jour DNS. Ce qui m’a paru étrange, c’est que la plupart des options populaires comme Netlify, Vercel ou Cloudflare ne proposent pas réellement de plafond de dépenses. Ça semble pourtant être une fonction de base.

    • Cloudflare Pages offre une bande passante gratuite illimitée, donc le trafic est gratuit et il n’y a pas besoin de plafond
    • Je travaille chez Vercel, et Vercel dispose d’une protection DDoS ainsi que de plafonds de dépenses. Nous préparons aussi l’annonce d’améliorations supplémentaires sur les deux points.
      https://vercel.com/blog/introducing-spend-management-realtime...
    • Cloudflare a une protection DDoS, et on peut la régler à un niveau presque paranoïaque. On peut faire en sorte qu’un CAPTCHA s’affiche pour tout le monde dès qu’un DDoS commence, ce qui limite assez efficacement les dépenses

  • Le fil de commentaires Netlify lié dans l’un des posts Reddit vaut aussi le détour : https://answers.netlify.com/t/limit-bandwidth-to-avoid-high-...
    Un représentant de Netlify y dit explicitement que, même sur l’offre gratuite, ils ne feront rien pour empêcher une facture de bande passante absurde en cas de DDoS

    • Ce que j’aime le moins dans ce type de services, c’est l’absence de fonctionnalité équivalente à un stop-loss. On peut configurer des alertes, elles préviendront, mais c’est tout, et souvent elles arrivent longtemps après que les dégâts ont été causés.
      Pour certains indicateurs de facturation, les rapports ou alertes peuvent même avoir plusieurs heures de retard. Par défaut, il faudrait privilégier la sécurité, tout en permettant d’augmenter facilement les limites
    • Avant, on coupait simplement le serveur ; maintenant, on se retrouve avec des sites serverless qui subissent un DDoS et une facture de 100 000 dollars.
      Je ne sais pas si ce modèle économique est viable. À l’époque où on possédait le serveur, on pouvait simplement débrancher la prise, mais aujourd’hui, impossible de savoir qui va appeler /api un million de fois par minute
    • Est-ce qu’on ne pourrait pas utiliser l’offre gratuite sous un faux nom et simplement jeter une facture absurde ? Je me demande comment ils vérifient leurs clients
    • J’ai l’impression que Netlify traverse peut-être des difficultés financières, et que c’est pour ça que ce genre de choses arrive. Le Netlify d’autrefois était un service très bon et assez unique, mais aujourd’hui GitHub, GitLab et Cloudflare Pages proposent à peu près la même chose pour moins cher
    • Si ça arrive sur l’offre gratuite, qu’est-ce qu’on est censé faire ? Partir sans payer la facture, tout simplement ? Ils vont vraiment envoyer des sociétés de recouvrement ?

  • Le fait qu’un fournisseur cloud facture de manière excessive des éléments qu’il est en droit de facturer donne un peu l’impression suivante : un garagiste découvre pendant un contrôle de routine qu’une petite pièce est cassée, puis que les pièces de remplacement continuent elles aussi à tomber en panne pour la même raison, et les remplace en boucle à l’infini pendant deux semaines sans donner la moindre information, jusqu’à ce que j’aille finalement au garage pour lui dire d’arrêter, après quoi il me facture le coût de 999 999 999 pièces cassées
    En tant que petit utilisateur et non grande organisation, il est impossible de lire toute la documentation de réglage dans ses moindres recoins. Je veux une limite fixe qui coupe tout une fois le plafond de dépense atteint, quitte à perdre des données si nécessaire. Mais j’imagine qu’ils ne le font pas parce que si l’utilisateur fait attention à son budget, cela nuit au chiffre d’affaires, et qu’il est parfois difficile d’estimer la facture à l’avance

    • Il y a quand même une différence. Dans l’exemple, le garagiste a lui-même créé la situation, alors que Netlify non, et il peut être difficile de distinguer entre du trafic non désiré et un SaaS qui a décollé du jour au lendemain
      Une analogie plus précise serait qu’une personne connaissant votre plaque d’immatriculation a demandé au garagiste d’effectuer tout ce qu’elle voulait, et que le garagiste s’est contenté d’exécuter

  • J’ai récemment créé une clé d’API OpenAI, et par défaut ils imposent un quota et désactivent la clé une fois la limite atteinte. Quand l’utilisateur est prêt à traiter davantage de requêtes, il augmente manuellement ce quota
    Il est surprenant que davantage d’entreprises ne fassent pas cela par défaut pour éviter ce genre de factures surprises. En y réfléchissant, c’est peut-être simplement parce qu’au final les utilisateurs paient souvent quand même

    • La différence, c’est qu’OpenAI supporte réellement un coût d’inférence, donc il y a un intérêt économique en jeu. Quand Netlify facture la bande passante 1000 fois son coût, le coût réel de fourniture du service est presque nul, donc ils peuvent ne pas vraiment s’en soucier même si l’utilisateur ne paie pas

  • La plus grande horreur du cloud n’est peut-être pas le serverless, mais le fait que nous ayons accepté de payer des frais de trafic inter-zones de disponibilité au motif qu’il faut se prémunir contre une défaillance du fournisseur cloud
    Autrement dit, le fournisseur facture assez cher pour atténuer des problèmes qu’il pourrait lui-même avoir

  • Dans ce fil, tout le monde dit que ce n’est pas un problème de serverless mais un problème de cloud, ce qui est vrai, mais le point essentiel demeure. La bande passante est presque entièrement de la marge nette, et facturer la bande passante à ce niveau tout en ne fournissant aucun outil pour répondre à des attaques échappant au contrôle du client paraît assez sale
    D’après ce fil, Netlify n’offre même pas la possibilité de mettre temporairement le site hors ligne pendant une attaque DDoS : https://answers.netlify.com/t/limiting-bandwidth-traffic-to-...
    Netlify pourrait proposer plusieurs solutions — contrôle de la facturation, limitation de requêtes, plafonds de bande passante, remise sur les dépassements s’il s’agit d’un vrai DDoS — mais ne semble pas intéressé, comme s’il ne voulait pas tuer la poule aux œufs d’or. Il suffit de voir les fonctionnalités proposées par le CDN bunny.net pour comparer : https://support.bunny.net/hc/en-us/articles/360014190440-Und...
    Il est décevant que nous acceptions si facilement les explications des fournisseurs cloud alors qu’il est difficile d’y voir autre chose que de la cupidité

  • Pourquoi l’absence de plafond de dépense serait-elle un problème du serverless ? C’est un problème de cloud
    Cela dit, avec un petit serveur cloud, en cas d’attaque il peut tomber, et si, comme chez AWS, seule la sortie de trafic est facturée, cela joue en faveur de l’utilisateur

    • Le serverless utilise plus souvent une facturation à l’usage que les modèles traditionnels, et il monte aussi mieux en charge jusqu’à de très gros volumes
      Si quelqu’un lance un DDoS sur mon VPS DigitalOcean à 5 dollars par mois, mon coût de calcul n’augmentera pas, et il y a de fortes chances qu’il s’effondre sous la charge avant que les frais de transfert ne s’accumulent fortement. Le transfert chez DigitalOcean est lui aussi facturé à l’usage, mais il atteindra probablement sa limite avant cela
    • Ce n’est pas un problème de cloud. Le cloud, au fond, ce n’est que l’ordinateur de quelqu’un d’autre
      C’est un problème de facturation, ou un problème d’architecture. Il faut permettre de limiter les requêtes pour éviter la surfacturation, ou couper une fois un certain montant atteint
    • C’est un échec d’architecture. Définir des maxima est important. Si vous choisissez une plateforme qui ne prend pas cela en charge, vous en portez aussi la responsabilité
      Dans les environnements traditionnels, il est implicitement plus simple de mettre en place des coupe-circuits, mais il faut quand même absolument y penser. Il faut faire des tests de charge aussi bien pour les cas de succès que d’échec
    • Si l’absence de plafond de dépense est un problème du serverless, c’est parce qu’avec le cloud on peut l’atténuer, alors qu’avec le serverless on ne le peut pas
      Moi, avec des instances cloud, je n’ai pas ce problème et je ne l’aurai pas non plus à l’avenir. Si j’étais en serverless, je l’aurais rencontré