Casos assustadores da tecnologia serverless

 (serverlesshorrors.com)
2 pontos por GN⁺ 2024-03-01 | 1 comentários | Compartilhar no WhatsApp
  • É um site que reúne casos reais para mostrar, por exemplo, o risco de explosão de custos escondido por trás da conveniência da cobrança por uso
  • Dá para comparar cobranças inesperadas ocorridas em serviços como Cloudflare, Vercel, AWS, Firebase, Netlify e BigQuery, por serviço e por causa
  • Como nas cobranças de $36,000 da Cloudflare, $46,485.99 da Vercel e $100,000 por dia da Firebase, até projetos pequenos ou serviços pessoais podem rapidamente resultar em contas altíssimas
  • As causas recorrentes são largura de banda, DDoS/DoS, armazenamento, implementação incorreta, recursão, loop de fila e aumento de uso relacionado a eventos, imagens, documentação e IA
  • Ao usar serviços serverless e de cobrança por consumo, é preciso verificar limites de cobrança, cache, padrões de requisição e loops de automação antes e depois do deploy

Natureza do site e forma de envio de relatos

  • ServerlessHorrors é um blog simples que reúne e publica casos de cobrança excessiva e incidentes ocorridos durante o uso de serverless
  • O criador é Andras, que trabalha com vários projetos open source como Coolify e Jean, além de atividades relacionadas à coolLabs
  • Os relatos podem ser enviados por dois caminhos

Principais casos que resultaram em cobranças altíssimas

  • $36,000: o side project RetainDB recebeu uma cobrança de $36k da Cloudflare quando tinha 81 usuários
    • As causas foram 16B Durable Object writes, runaway queue loop, Durable Object writes não agrupadas em lote e um KV list scan executado a cada requisição
    • Tags: cloudflare, workers, durable-objects, kv, queues
  • $46,485.99: o Jmail ultrapassou 450M pageviews e, mesmo após muitas medidas de mitigação de cache, a cobrança da Vercel subiu para $46k
    • Tags: vercel, bandwidth
  • $100,000.420: um site de upload de jogos WebGL com alguma popularidade sofreu um DoS e a cobrança diária da Firebase chegou a $100k
    • Tags: google, storage, firebase
  • $120,000.420: caso em que a Cloudflare tentou exigir o pagamento de $120k em menos de 24 horas e depois derrubou o site
    • Tags: cloudflare, bandwidth
  • $104,500.123: caso de recebimento de um e-mail de cobrança em atraso de $104,500.00 da Netlify
    • Tags: netlify, bandwidth, ddos
  • $96,280.69: caso de cobrança altíssima relacionada a bandwidth na Vercel
    • Tags: vercel, bandwidth, new
  • $72,000.999: caso de alguém que queimou $72K testando Firebase + Cloud Run e quase foi à falência
    • Tags: google, firebase, cloudrun, wrong-implementation, recursion
  • $70,000.69: um projeto que pagava $50 por mês recebeu um dia uma fatura de $70,000
    • Tags: google, storage, firebase, gcs

Outros casos incluídos por serviço

  • $23,000.420: o EchoFox sofreu spam, a cobrança da Vercel disparou para $23k e surgiram 56k+ accounts and trials
    • Tags: vercel, bandwidth, ddos
  • $22.639,69: recebeu uma cobrança de 22k USD no BigQuery playground apenas por usar um dataset público
    • Tags: google, bigquery, sql
  • $11,000.69: durante um ataque DoS, foram enviados cerca de $11k em e-mails e o banco de dados foi perdido
    • Tags: ddos, mailgun
  • $4,241.69: caso em que o serviço foi pausado, mas a AWS bloqueou o acesso e exigiu o pagamento dos custos
    • Tags: aws
  • $3,000.69: caso que alerta para tomar cuidado ao testar ou fazer deploy na Vercel
    • Tags: vercel, bandwidth, wrong-implementation
  • $1,300.69: houve custo após criar um bucket AWS S3 vazio, privado e na região desejada
    • Tags: aws, s3, security, ddos
  • $1273.69: houve custo no PostHog após pedir ao Devin AI que alterasse a codebase
    • Tags: posthog, devin, ai, cognition-labs, new
  • ~$1189.420/month: em um plano de $69/month, a Webflow cobrou $1189.420 em um único mês
    • Tags: webflow, bandwidth, image
  • $738.420: mesmo assinando o Vercel Pro por $20/mês e adicionando um $120 spending limit, houve cobrança
    • Tags: vercel, bandwidth, vercels-mistake, spending-limit
  • $620.123: caso da Vercel em que sitemap.txt consumiu centenas de GB/hours
    • Tags: vercel, bandwidth
  • $530.19: caso do PostHog em que nunca havia sido pago nada e, de repente, foi cobrado $530
    • Tags: posthog, events, new
  • $400.69: o Cloudflare Images cobrou $400 por mês em vez dos $110 esperados, incluindo cobrança pré-paga confusa e ausência de suporte por mais de 8 meses
    • Tags: cloudflare, images, billing
  • $383.69: caso da Mintlify com quase $400 cobrados em um site de documentação
    • Tags: mintlify, ai, documentation
  • $250/month: passou a ser necessário pagar $250 por mês, ou $3,000 por ano, por 9,000 page visits
    • Tags: framer, bandwidth, images and videos
  • $103.26: caso da AWS em que $103 já virou um caso assustador em contexto de uso do free tier
    • Tags: aws, dark-pattern, free-tier

Leituras relacionadas

1 comentários

 
GN⁺ 2024-03-01
Opiniões no Hacker News

  • É realmente lamentável e dá até a sensação de estarmos andando para trás. Um arquivo de 3,44 MB não deveria ser um problema e, mesmo que fosse, “hospede em outro lugar” não deveria ser a resposta.
    Se há uma lição a tirar daqui, é que não existe almoço grátis, e perdas grandes como essa deveriam poder ser evitadas com algum tipo de limite. VPS é muito barato, fácil de administrar e também tem limites automáticos: https://lowendbox.com/blog/1-vps-1-usd-vps-per-month/

    • As pessoas se perguntam por que hoje restam tão poucos sites e a cauda longa desapareceu, mas é porque, no Facebook ou no Twitter, você pode subir um áudio de 3,44 MB sem nunca se preocupar com uma cobrança
    • Dizer que VPS é “fácil de administrar” é uma opção bem forte, que parte de várias premissas

  • Não acho que o caso da Netlify tenha acontecido por causa de arquitetura serverless. Serverless tem muitos problemas técnicos, mas o problema de receber uma conta enorme por causa de tráfego de entrada é independente de serverless.
    Mesmo colocando seu próprio equipamento em colocation e pagando pelo tráfego, se o datacenter não bloquear DDoS e cobrar por TB, a mesma coisa pode acontecer. Claro, em colocation o preço por TB é muito mais barato do que na Netlify, então é menos provável surgir uma conta de 100 mil dólares; mas, nesse caso, o ponto central não deveria ser “terror serverless”, e sim custos de tráfego absurdamente caros e ausência de mitigação de DDoS

    • Se o serviço escala infinitamente, a velocidade com que o dinheiro queima também escala infinitamente. Um único servidor em colocation, ao saturar, também limita o dano que pode causar ao seu bolso

  • Andres, que criou este blog, também está fazendo o coolify, uma alternativa self-hosted ao Heroku/Netlify. Depois de usá-lo por alguns meses, ele virou uma espécie de ingrediente secreto que facilita fazer self-hosting de coisas como changedetector, jdownloader e vaultwarden.
    A comunidade também vem crescendo bem: as pessoas contribuem com novos templates e ajudam umas às outras a depurar. Também tentei adicionar um template do Syncthing. Porém, quando o disco encheu em uma instância com 10 GB de armazenamento, várias coisas começaram a quebrar; seria bom melhorar alertas ou prevenção nessa parte. Fora isso, é bastante estável.
    https://github.com/coollabsio/coolify

  • Pode ser uma reação exagerada, mas decidi tirar meu site pessoal da Netlify. Eu não precisava de nada além de um lugar para jogar HTML, e achava que a Netlify era “boa o suficiente”, mas não sabia que existia esse tipo de problema.
    O site afetado recentemente se parece com o meu em visitas diárias, reconhecimento e caráter de nicho, então isso pareceu mais real. Como prefiro compilar o HTML localmente e enviá-lo para algum lugar, a migração em si deve exigir basicamente atualizar o DNS. O estranho é que a maioria das opções populares, como Netlify, Vercel e Cloudflare, não oferece de fato limite de gastos. Parece uma funcionalidade básica demais

    • No Cloudflare Pages, a banda gratuita é ilimitada, então o tráfego é gratuito e, por isso, não é necessário um limite
    • Trabalho na Vercel, e a Vercel tem proteção contra DDoS e limite de gastos. Estamos trabalhando para anunciar melhorias em breve para ambos.
      https://vercel.com/blog/introducing-spend-management-realtime...
    • A Cloudflare tem proteção contra DDoS e dá para configurá-la em um nível quase paranoico. Quando um DDoS começa, você pode fazer todo mundo ver um CAPTCHA, o que limita os gastos de forma bastante eficaz

  • Também vale ver a thread de comentários da Netlify linkada em um dos posts do Reddit: https://answers.netlify.com/t/limit-bandwidth-to-avoid-high-...
    Um representante da Netlify diz explicitamente que, mesmo no plano gratuito, se você sofrer um DDoS, eles não farão nada para evitar uma cobrança absurda de banda

    • O que eu menos gosto nesses serviços é que não existe uma funcionalidade equivalente a stop-loss. Se você configurar alertas, eles avisam, mas só isso; em muitos casos, o alerta chega muito tempo depois do prejuízo.
      Alguns indicadores de cobrança podem ter relatórios ou alertas atrasados por horas. O padrão deveria ser seguro, e aumentar limites deveria ser fácil
    • Antes, derrubavam o servidor; agora, a estrutura é sofrer DDoS em um site serverless e receber uma conta de 100 mil dólares.
      Não sei se esse modelo de negócio é sustentável. Na época em que você era dono do servidor, podia tirar da tomada, mas agora não há como saber quem vai chamar /api um milhão de vezes por minuto
    • Não daria para usar o plano gratuito com um nome falso e simplesmente largar uma cobrança absurda? Fico curioso sobre como eles verificam os clientes
    • Fico me perguntando se isso acontece porque a Netlify está passando por dificuldades financeiras. A Netlify de antes era um serviço muito bom e único, mas agora GitHub, GitLab e Cloudflare Pages oferecem praticamente o mesmo serviço por menos
    • O que fazer se isso acontecer no plano gratuito? É só não pagar a fatura e ir embora? Será que eles realmente vão acionar cobrança?

  • O fato de um provedor de nuvem cobrar em excesso por itens que tem o direito de cobrar parece um pouco como um mecânico que, durante uma revisão de rotina, descobre que uma pecinha quebrou e que, pelo mesmo motivo, as peças de reposição continuam quebrando; então ele fica trocando em um loop infinito, não dá nenhuma informação por duas semanas e, no fim, quando eu vou até a garagem e mando parar, cobra o custo de 999.999.999 peças quebradas
    Como usuário pequeno, e não uma grande organização, não dá para ler toda a documentação de ajuste de cada cantinho. Eu quero um limite fixo que, ao atingir um teto de gasto definido, derrube tudo, mesmo que, se necessário, eu perca até os dados. Mas, se o usuário for cuidadoso com o orçamento, isso prejudica a receita; e também há casos em que é difícil calcular a cobrança antecipadamente, então parece que eles não oferecem isso.

    • Há uma diferença. No exemplo, o mecânico criou a situação, mas a Netlify não; e pode ser difícil distinguir tráfego indesejado de um SaaS que fez sucesso da noite para o dia
      Uma analogia mais precisa seria algo como eu dizer ao mecânico para atender qualquer pedido feito por alguém que saiba a placa, e o mecânico simplesmente executar isso.

  • Recentemente criei uma chave da API da OpenAI e, por padrão, ela impõe uma cota e desativa a chave quando o limite é atingido. Quando o usuário estiver pronto para lidar com mais requisições, ele aumenta manualmente a cota
    É surpreendente que mais empresas não façam isso como padrão para evitar essas faturas-surpresa. Pensando bem, talvez seja porque, no fim, muitas vezes o usuário simplesmente paga.

    • A diferença é que a OpenAI realmente tem custos de inferência, então há interesses em jogo. Quando a Netlify cobra 1.000 vezes mais pela largura de banda, o custo de prestar o serviço é quase nulo; então, se o usuário não pagar, talvez ela realmente não se importe muito.

  • Acho que o maior terror da nuvem talvez nem seja serverless, mas o fato de termos aceitado pagar por tráfego entre zonas de disponibilidade sob a justificativa de nos prepararmos para uma falha do provedor de nuvem
    Em outras palavras, o provedor cobra bastante pelos custos de mitigar problemas que ele próprio pode vir a ter.

  • Nesta thread, todo mundo está dizendo que isso não é um problema de serverless, e sim de nuvem; isso está certo, mas o ponto central continua. Largura de banda é quase margem líquida, e cobrar tão caro por largura de banda sem oferecer aos clientes ferramentas para responder a ataques fora do controle deles parece bem sujo
    Segundo esta thread, a Netlify nem sequer oferece a opção de tirar o site temporariamente do ar durante um ataque DDoS: https://answers.netlify.com/t/limiting-bandwidth-traffic-to-...
    A Netlify poderia ter várias soluções, como controle de cobrança, limitação de requisições, limite de largura de banda, isenção de excedentes em caso de DDoS real etc., mas parece não ter interesse, pois isso seria matar a galinha dos ovos de ouro. Basta comparar com os recursos oferecidos pela CDN da bunny.net: https://support.bunny.net/hc/en-us/articles/360014190440-Und...
    É decepcionante como aceitamos tão facilmente isso, apesar de ser difícil explicar a postura dos provedores de nuvem por algo que não seja ganância.

  • Por que a falta de um limite de gastos seria um problema de serverless? Isso é um problema de nuvem
    Dito isso, se for um servidor de nuvem pequeno, ele pode cair ao ser atacado; e, se só for cobrado o tráfego de saída, como na AWS, isso favorece o usuário.

    • Porque serverless usa cobrança baseada em uso com mais frequência do que o modelo tradicional, e escala melhor até volumes de uso muito grandes
      Mesmo que façam DDoS no meu VPS de US$ 5 por mês na DigitalOcean, meu custo de computação não aumenta, e é provável que ele caia por não aguentar a carga antes que os custos de transferência se acumulem muito. A transferência da DigitalOcean também é baseada em uso, mas eu atingiria algum limite antes disso.
    • Isso não é um problema de nuvem. No fim das contas, nuvem é só o computador de outra pessoa
      Isso é um problema de cobrança ou um problema de arquitetura. Eles deveriam permitir limitar requisições para evitar cobrança excessiva, ou cortar o serviço quando um determinado valor for atingido.
    • Isso é uma falha de arquitetura. Definir máximos é importante. Se você escolhe uma plataforma que não oferece suporte a esse recurso, também há responsabilidade sua
      Em ambientes tradicionais, é implicitamente mais fácil colocar disjuntores, mas ainda assim isso precisa ser considerado. É preciso fazer testes de carga tanto para sucesso quanto para falha.
    • O motivo de a falta de limite de gastos ser um problema de serverless é que, usando nuvem, dá para mitigar; em serverless, não dá
      Usando instâncias de nuvem, eu não tenho esse problema e nunca terei. Se fosse serverless, eu teria enfrentado esse problema.