Serverless teknolojisinin korku vakaları

 (serverlesshorrors.com)
2 puan yazan GN⁺ 2024-03-01 | 1 yorum | WhatsApp'ta paylaş
  • Kullanım bazlı ücretlendirmenin sunduğu rahatlığın arkasına gizlenen maliyet patlaması riskini gerçek örnekler üzerinden bir araya getirip gösteren bir site
  • Cloudflare, Vercel, AWS, Firebase, Netlify, BigQuery gibi hizmetlerde yaşanan beklenmedik faturaları servis ve neden bazında karşılaştırabiliyorsunuz
  • $36,000 Cloudflare, $46,485.99 Vercel, günlük $100,000 Firebase faturası gibi örneklerde küçük projeler veya kişisel servisler bile bir anda çok yüksek ücretlere yol açabiliyor
  • Tekrarlayan nedenler arasında bant genişliği, DDoS/DoS, depolama, hatalı uygulama, özyineleme, kuyruk döngüsü, etkinlik·görsel·dokümantasyon·yapay zeka ile ilgili kullanım artışı yer alıyor
  • Serverless ve kullandıkça öde hizmetleri kullanırken, dağıtımdan önce ve sonra fatura limitlerini, cache'i, istek kalıplarını ve otomasyon döngülerini kontrol etmek gerekiyor

Sitenin niteliği ve bildirim yöntemi

  • ServerlessHorrors, serverless kullanımı sırasında ortaya çıkan faturalandırma ve kesinti benzeri vakaları derleyip okunabilir hale getiren basit bir blog
  • Yapımcısı Andras; Coolify, Jean gibi çeşitli açık kaynak projeler ve coolLabs ile ilgili çalışmalar yürütüyor
  • Vaka bildirimleri iki kanaldan alınıyor

Yüksek tutarlı faturalara yol açan başlıca vakalar

  • $36,000: RetainDB yan projesi, 81 kullanıcıdayken Cloudflare'dan $36k fatura aldı
    • Nedenler: 16B Durable Object writes, runaway queue loop, batch edilmemiş Durable Object writes ve her istekte çalıştırılan KV list scan
    • Etiketler: cloudflare, workers, durable-objects, kv, queues
  • $46,485.99: Jmail 450M pageviews'u aştı ve yoğun cache azaltımına rağmen Vercel faturası $46k'ye çıktı
    • Etiketler: vercel, bandwidth
  • $100,000.420: Bir ölçüde popüler olan bir WebGL oyun yükleme sitesi DoS saldırısına uğradı ve günlük Firebase faturası $100k oldu
    • Etiketler: google, storage, firebase
  • $120,000.420: Cloudflare'ın 24 saat içinde $120k ödemesini istemesinin ardından web sitesinin kapatıldığı bir vaka
    • Etiketler: cloudflare, bandwidth
  • $104,500.123: Netlify'dan $104,500.00 gecikmiş ödeme faturası e-postası alan bir vaka
    • Etiketler: netlify, bandwidth, ddos
  • $96,280.69: Vercel bandwidth ile ilgili yüksek tutarlı fatura vakası
    • Etiketler: vercel, bandwidth, new
  • $72,000.999: Firebase + Cloud Run testiyle $72K harcayıp neredeyse iflas eden bir vaka
    • Etiketler: google, firebase, cloudrun, wrong-implementation, recursion
  • $70,000.69: Aylık $50 ödeyen bir projeye bir gün $70,000 fatura çıktı
    • Etiketler: google, storage, firebase, gcs

Hizmetlere göre yer alan ek vakalar

  • $23,000.420: EchoFox spam aldı, Vercel faturası $23k'ye fırladı ve 56k+ accounts and trials oluştu
    • Etiketler: vercel, bandwidth, ddos
  • $22.639,69: BigQuery playground'da sadece herkese açık bir dataset kullanmasına rağmen 22k USD fatura geldi
    • Etiketler: google, bigquery, sql
  • $11,000.69: DoS saldırısı sırasında $11k değerinde e-posta gönderildi ve veritabanı kaybedildi
    • Etiketler: ddos, mailgun
  • $4,241.69: Servisi duraklatmasına rağmen AWS'nin erişimi engelleyip ödeme talep ettiği bir vaka
    • Etiketler: aws
  • $3,000.69: Vercel'de test ederken veya dağıtım yaparken dikkat edilmesi gerektiğini gösteren bir vaka
    • Etiketler: vercel, bandwidth, wrong-implementation
  • $1,300.69: İstenen bölgede boş ve özel bir AWS S3 bucket oluşturduktan sonra maliyet oluşan bir vaka
    • Etiketler: aws, s3, security, ddos
  • $1273.69: Devin AI'dan kod tabanında değişiklik yapmasını istedikten sonra PostHog maliyeti oluştu
    • Etiketler: posthog, devin, ai, cognition-labs, new
  • ~$1189.420/month: $69/month planda, tek bir ay için Webflow $1189.420 fatura kesti
    • Etiketler: webflow, bandwidth, image
  • $738.420: Vercel Pro'ya aylık $20 ödeyip ayrıca $120 spending limit eklenmesine rağmen yine de fatura çıktı
    • Etiketler: vercel, bandwidth, vercels-mistake, spending-limit
  • $620.123: sitemap.txt yüzünden yüzlerce GB/saat kullanım oluşan bir Vercel vakası
    • Etiketler: vercel, bandwidth
  • $530.19: Daha önce hiç ücret ödememişken bir anda $530 fatura gelen PostHog vakası
    • Etiketler: posthog, events, new
  • $400.69: Cloudflare Images, beklenen $110 yerine aylık $400 ücret çıkardı; buna kafa karıştırıcı peşin ücretlendirme ve 8 aydan uzun destek eksikliği de dahildi
    • Etiketler: cloudflare, images, billing
  • $383.69: Dokümantasyon sitesinde neredeyse $400 fatura gelen Mintlify vakası
    • Etiketler: mintlify, ai, documentation
  • $250/month: 9,000 page visits için aylık $250, yıllık $3,000 maliyet gerektiren bir durum
    • Etiketler: framer, bandwidth, images and videos
  • $103.26: free tier kullanımı sırasında $103'ün korku vakasına dönüştüğü bir AWS örneği
    • Etiketler: aws, dark-pattern, free-tier

İlgili okumalar

1 yorum

 
GN⁺ 2024-03-01
Hacker News yorumları

  • Gerçekten çok üzücü; hatta geriye gidiyormuşuz gibi hissettiriyor. 3,44 MB’lık bir dosya sorun olmamalı; sorun olsa bile cevap “başka yere yükle” olmamalı.
    Buradan çıkarılacak tek bir ders varsa o da bedava diye bir şey olmadığı; bu kadar büyük kayıpların bir şekilde limit konularak engellenebilmesi gerekir. VPS’ler çok ucuz, yönetmesi de kolay ve otomatik limitleri de var: https://lowendbox.com/blog/1-vps-1-usd-vps-per-month/

    • İnsanlar neden artık yalnızca birkaç web sitesi kaldığını ve long tail’in yok olduğunu merak ediyor; çünkü Facebook’a ya da Twitter’a 3,44 MB’lık bir ses dosyası yüklediğinizde asla fatura kesilecek diye endişelenmeniz gerekmiyor.
    • VPS’nin “yönetmesi kolay” olduğu iddiası, altında birçok varsayım barındıran epey güçlü bir tercih.

  • Netlify örneğinin sunucusuz mimari yüzünden ortaya çıktığını düşünmüyorum. Sunucusuzun pek çok teknik sorunu var, ancak gelen trafik nedeniyle büyük fatura çıkması sorunu sunucusuzdan bağımsız.
    Kendi donanımınızı colocational bir tesise koyup trafik ücreti ödediğinizde de, veri merkezi DDoS’u engellemez ve TB bazında ücretlendirirse aynı şey yaşanabilir. Elbette colocation’da TB başına fiyat Netlify’dan çok daha ucuz olduğu için 100 bin dolarlık bir faturanın çıkma ihtimali düşük; ama o zaman asıl mesele “sunucusuz korku hikâyesi” değil, akıl almaz derecede pahalı trafik ücretleri ve DDoS azaltmanın olmaması olmalı.

    • Hizmet sonsuza kadar ölçeklenirse, paranın yanma hızı da sonsuza kadar ölçeklenir. Colocation’daki tek bir sunucu doyuma ulaştığında cüzdana verebileceği zarar da sınırlanır.

  • Bu blogu yapan Andres, Heroku/Netlify’a self-hosting alternatifi olan coolify’ı da geliştiriyor. Birkaç aydır kullanıyorum; changedetector, jdownloader, vaultwarden gibi şeyleri self-host etmeyi kolaylaştıran gizli sos gibi bir şey oldu.
    Topluluk da oldukça iyi büyüyor; insanlar yeni şablonlar katkılıyor, birbirlerinin hata ayıklamasına yardım ediyor. Ben de Syncthing şablonu eklemeyi denedim. Ancak 10 GB depolama alanına sahip instance’ta disk dolunca çeşitli şeyler çöktü; bu konuda uyarıların ya da önlemlerin daha iyi olmasını isterdim. Onun dışında oldukça stabil.
    https://github.com/coollabsio/coolify

  • Aşırı tepki veriyor olabilirim ama kişisel sitemi Netlify’dan taşımaya karar verdim. HTML’i bırakacağım bir yerden fazlasına ihtiyacım yoktu ve Netlify’ın “yeterince iyi” olduğunu düşünüyordum; böyle bir sorun olduğunu bilmiyordum.
    Son dönemde zarar gören sitenin günlük ziyaretçi sayısı, bilinirliği ve niş yapısı benim siteme benzediği için durum daha gerçekçi geldi. HTML’i yerelde derleyip bir yere yükleme yöntemini tercih ettiğimden taşınmanın kendisi DNS güncellemesi kadar basit olmalı. Garip olan, Netlify, Vercel, Cloudflare gibi popüler seçeneklerin çoğunun gerçekten harcama limiti sunmamasıydı. Çok temel bir özellik gibi görünüyor.

    • Cloudflare Pages’te ücretsiz bant genişliği sınırsız olduğu için trafik ücretsizdir; bu yüzden limite gerek yoktur.
    • Vercel’de çalışıyorum; Vercel’de DDoS koruması ve harcama limitleri var. İkisi için de yakında ek iyileştirmeler duyurmak üzere çalışıyoruz.
      https://vercel.com/blog/introducing-spend-management-realtime...
    • Cloudflare’da DDoS koruması var ve neredeyse paranoyakça ayarlanabiliyor. DDoS başladığında herkese CAPTCHA gösterilmesini sağlayabiliyorsunuz; bu da harcamayı oldukça etkili biçimde sınırlar.

  • Reddit gönderilerinden birinde bağlantısı verilen Netlify yorum başlığı da görülmeye değer: https://answers.netlify.com/t/limit-bandwidth-to-avoid-high-...
    Netlify temsilcisi, ücretsiz katmanda bile DDoS’a uğranırsa saçma derecede yüksek bant genişliği faturasını engellemek için hiçbir şey yapmayacaklarını açıkça söylüyor.

    • Bu tür servislerde en hoşuma gitmeyen şey, zararı durdurmaya denk gelen bir özelliğin olmaması. Uyarı kurarsanız haber veriyorlar, ama hepsi bu; çoğu durumda uyarı, zarar oluştuktan epey sonra geliyor.
      Bazı ücretlendirme metriklerinde raporlama ya da uyarılar saatlerce gecikebiliyor. Varsayılanlar güvenli olmalı, limiti artırmak ise kolay yapılabilmeli.
    • Eskiden sunucuyu kapatırlardı; şimdi ise sunucusuz web sitenize DDoS yiyorsunuz ve 100 bin dolarlık fatura alıyorsunuz.
      Böyle bir iş modelinin sürdürülebilir olup olmadığını bilmiyorum. Sunucuya sahip olunan dönemde fişi çekebiliyordunuz; şimdi ise birinin /api’yi dakikada bir milyon kez çağırıp çağırmayacağını bilmenin yolu yok.
    • Ücretsiz katmanı sahte isimle kullanıp saçma faturayı çöpe atmak mümkün değil mi? Müşteri doğrulamasını nasıl yaptıklarını merak ediyorum.
    • Netlify’ın nakit sıkıntısı yaşadığı için bunlar oluyor olabilir mi diye düşünüyorum. Eski Netlify çok iyi ve özgün bir hizmetti; ama artık GitHub, GitLab ve Cloudflare Pages neredeyse aynı hizmeti daha ucuza sunuyor.
    • Ücretsiz katmanda böyle bir şey olursa ne yapmak gerekir? Faturayı ödemeyip çekip gitmek yeterli mi? Gerçekten tahsilata mı gelirler?

  • Bir bulut sağlayıcısının faturalandırma hakkı olan kalemleri aşırı ücretlendirmesi, bana biraz şuna benziyor: Bir oto tamircisi rutin kontrol sırasında küçük bir parçanın bozulduğunu söylüyor; aynı nedenle yedek parçalar da sürekli bozulduğu için sonsuz döngü halinde değiştiriyor, iki hafta boyunca hiçbir bilgi vermiyor ve sonunda garaja gidip durmasını söylediğimde bozulan 999.999.999 parçanın ücretini çıkarıyor.
    Büyük bir kuruluş değil, küçük bir kullanıcı olarak her köşedeki tüm ayar belgelerini okuyamam. Belirlenmiş harcama limitine ulaşılınca her şeyi kapatan, gerekirse veriyi bile kaybetmeyi göze alabileceğim sabit bir limit istiyorum. Ama kullanıcı bütçeye dikkat ederse gelirlerine zarar verir; ayrıca faturayı önceden hesaplamanın zor olduğu durumlar da var, bu yüzden bunu yapmıyorlar gibi görünüyor

    • Bir fark var. Örnekteki tamirci durumu bizzat yaratmıştı, Netlify ise yaratmadı; istenmeyen trafik ile bir gecede başarıya ulaşmış bir SaaS'ı ayırt etmek de zor olabilir.
      Daha doğru benzetme, plakasını bilen birinin ne isterse istesin tamirciye hepsini yapmasını söylemiş olması ve tamircinin de aynen uygulaması olurdu

  • Yakın zamanda bir OpenAI API anahtarı oluşturdum; varsayılan olarak kota zorunlu tutuluyor ve limite ulaşılınca anahtar devre dışı bırakılıyor. Daha fazla isteği karşılamaya hazır olduğunuzda kotayı kullanıcı olarak elle artırıyorsunuz.
    Böyle sürpriz faturaları önlemek için daha fazla şirketin bunu varsayılan olarak yapmaması şaşırtıcı. Düşününce, belki de sonunda kullanıcıların çoğu parayı ödeyip geçtiği içindir

    • Fark şu: OpenAI'de çıkarım maliyeti gerçekten var, yani ortada bir çıkar ilişkisi bulunuyor. Netlify bant genişliğine 1000 kat ücret yazdığında ise hizmeti sağlamanın maliyeti neredeyse yok; bu yüzden kullanıcı ödemezse gerçekte çok da umursamayabilirler

  • En büyük bulut korkusunun serverless olmayabileceğini; asıl meselenin, bulut sağlayıcısı başarısız olursa diye erişilebilirlik bölgeleri arası trafik ücretini ödemeyi kabullenmiş olmamız olduğunu düşünüyorum.
    Başka bir deyişle, sağlayıcının yaşayabileceği bir sorunu hafifletmenin maliyetini sağlayıcı bize epey yüksek biçimde faturalandırıyor

  • Bu başlıkta herkes bunun bir serverless sorunu değil, bulut sorunu olduğunu söylüyor; doğru, ama asıl nokta hâlâ duruyor. Bant genişliği neredeyse tamamen net kâr ve bant genişliğini bu kadar pahalı ücretlendirip müşterinin kontrolü dışındaki saldırılara karşı araç sunmamak epey kirli görünüyor.
    Bu başlığa göre Netlify, DDoS saldırısı sırasında siteyi geçici olarak kapatma seçeneğini bile sunmuyor: https://answers.netlify.com/t/limiting-bandwidth-traffic-to-...
    Netlify'nin fatura kontrolü, istek sınırlama, bant genişliği limiti, gerçekten DDoS ise aşımı affetme gibi birçok çözümü olabilir; ama altın yumurtlayan kazı kesmek gibi olacağı için ilgilenmiyor gibi görünüyor. bunny.net CDN'in sunduğu özelliklere bakmak bile karşılaştırma için yeterli: https://support.bunny.net/hc/en-us/articles/360014190440-Und...
    Bulut sağlayıcılarının açıklamasını açgözlülük dışında anlamlandırmak zor olduğu hâlde bunu bu kadar kolay kabullenmemiz hayal kırıklığı

  • Harcama limitinin olmaması neden serverless sorunu olsun? Bu bir bulut sorunu.
    Yine de küçük bir bulut sunucusu saldırı altında kalırsa çökebilir; AWS gibi yalnızca çıkış trafiğini ücretlendiriyorsa bu kullanıcının lehinedir

    • Çünkü serverless, geleneksel modele göre kullanıma dayalı ücretlendirmeyi daha sık kullanıyor ve büyük ölçekli kullanıma daha iyi ölçekleniyor.
      Aylık 5 dolarlık DigitalOcean VPS'ime DDoS yapsanız da işlem maliyeti artmaz; aktarım maliyeti ciddi biçimde birikmeden önce muhtemelen yükü kaldıramayıp çöker. DigitalOcean aktarımı da kullanıma dayalı olsa da o noktadan önce sınıra çarpacaktır
    • Bu bir bulut sorunu değil. Bulut nihayetinde başkasının bilgisayarından ibaret.
      Bu bir faturalandırma sorunu ya da mimari sorunu. Aşırı faturalandırmayı önlemek için istekleri sınırlamaya izin vermeli veya belirli bir tutara ulaşıldığında kesmeliler
    • Bu bir mimari başarısızlık. Maksimumları belirlemek önemlidir. Böyle bir özelliği desteklemeyen bir platform seçerseniz bunda sizin de sorumluluğunuz var.
      Geleneksel ortamlarda devre kesici koymak örtük olarak daha kolaydır; yine de mutlaka dikkate alınmalıdır. Hem başarı hem de başarısızlık senaryoları için yük testi yapılmalı
    • Harcama limitinin olmamasının serverless sorunu olmasının nedeni, bulut kullanırken bunun hafifletilebilmesi ama serverless'ta hafifletilememesidir.
      Bulut instance'ı kullanan biri olarak bende bu sorun yok ve gelecekte de olmayacak. Serverless kullansaydım bu sorunu yaşardım