Serverless तकनीक की डरावनी कहानियां

 (serverlesshorrors.com)
2 पॉइंट द्वारा GN⁺ 2024-03-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • उपयोग-आधारित billing की सुविधा के पीछे छिपे cost runaway risk को वास्तविक मामलों के आधार पर इकट्ठा कर दिखाने वाली साइट
  • Cloudflare, Vercel, AWS, Firebase, Netlify, BigQuery आदि में हुई अप्रत्याशित billing को service और कारण के आधार पर compare किया जा सकता है
  • $36,000 Cloudflare, $46,485.99 Vercel, $100,000 Firebase की एक-दिन की billing जैसे मामलों से पता चलता है कि छोटे projects या personal services भी पल भर में भारी billing में बदल सकते हैं
  • बार-बार दिखने वाले कारण हैं bandwidth, DDoS/DoS, storage, गलत implementation, recursion, queue loop, events·images·documentation·AI से जुड़ी usage में बढ़ोतरी
  • Serverless और pay-as-you-go services इस्तेमाल करते समय deployment से पहले और बाद में billing limits, cache, request patterns और automation loops जांचने चाहिए

साइट का स्वरूप और case submit करने का तरीका

  • ServerlessHorrors एक सरल blog है, जहां serverless इस्तेमाल के दौरान हुई billing और outage जैसी घटनाओं को इकट्ठा कर पढ़ा जा सकता है
  • इसके निर्माता Andras हैं, जो Coolify, Jean जैसे कई open source projects और coolLabs से जुड़े काम करते हैं
  • cases दो तरीकों से submit किए जाते हैं

भारी billing तक पहुंचाने वाले प्रमुख मामले

  • $36,000: RetainDB side project को, 81 users की स्थिति में, Cloudflare की $36k billing मिली
    • कारण थे 16B Durable Object writes, runaway queue loop, batch न किए गए Durable Object writes, और हर request पर चलने वाला KV list scan
    • tags: cloudflare, workers, durable-objects, kv, queues
  • $46,485.99: Jmail ने 450M pageviews पार किए, और कई cache mitigations के बाद भी Vercel billing $46k तक बढ़ गई
    • tags: vercel, bandwidth
  • $100,000.420: कुछ हद तक popular WebGL game upload site पर DoS हुआ और एक दिन की Firebase billing $100k हो गई
    • tags: google, storage, firebase
  • $120,000.420: Cloudflare ने 24 घंटे के अंदर $120k भुगतान मांगने की कोशिश की, जिसके बाद website बंद कर दी गई
    • tags: cloudflare, bandwidth
  • $104,500.123: Netlify से $104,500.00 overdue billing email मिलने का मामला
    • tags: netlify, bandwidth, ddos
  • $96,280.69: Vercel bandwidth से जुड़ी भारी billing का मामला
    • tags: vercel, bandwidth, new
  • $72,000.999: Firebase + Cloud Run test में $72K खर्च हो गए और लगभग दिवालिया होने की नौबत आ गई
    • tags: google, firebase, cloudrun, wrong-implementation, recursion
  • $70,000.69: जिस project पर महीने के $50 लगते थे, उसमें एक दिन $70,000 का bill आ गया
    • tags: google, storage, firebase, gcs

service के हिसाब से शामिल अतिरिक्त मामले

  • $23,000.420: EchoFox को spam मिला, जिससे Vercel billing $23k तक उछल गई और 56k+ accounts and trials बने
    • tags: vercel, bandwidth, ddos
  • $22.639,69: BigQuery playground में केवल public dataset इस्तेमाल करने पर 22k USD की billing मिली
    • tags: google, bigquery, sql
  • $11,000.69: DoS attack के दौरान $11k के email भेजे गए और database खो गया
    • tags: ddos, mailgun
  • $4,241.69: service को temporarily suspend किया था, लेकिन AWS ने block किया और cost चुकानी पड़ी
    • tags: aws
  • $3,000.69: Vercel पर test या deploy करते समय सावधान रहने की चेतावनी वाला मामला
    • tags: vercel, bandwidth, wrong-implementation
  • $1,300.69: इच्छित region में एक खाली और private AWS S3 bucket बनाने के बाद cost लग गई
    • tags: aws, s3, security, ddos
  • $1273.69: Devin AI से codebase में बदलाव करवाने के बाद PostHog cost लगी
    • tags: posthog, devin, ai, cognition-labs, new
  • ~$1189.420/month: $69/month plan पर Webflow ने एक ही महीने में $1189.420 charge किया
    • tags: webflow, bandwidth, image
  • $738.420: Vercel Pro को $20/month पर subscribe किया और $120 spending limit भी जोड़ी, फिर भी billing हुई
    • tags: vercel, bandwidth, vercels-mistake, spending-limit
  • $620.123: sitemap.txt ने सैकड़ों GB/hours इस्तेमाल किए, ऐसा Vercel मामला
    • tags: vercel, bandwidth
  • $530.19: पहले कभी payment नहीं किया था, फिर अचानक $530 charge हो गया — PostHog का मामला
    • tags: posthog, events, new
  • $400.69: Cloudflare Images ने expected $110 के बजाय महीने के $400 charge किए; इसमें उलझाने वाली prepaid billing और 8 महीने से ज्यादा support की कमी भी शामिल थी
    • tags: cloudflare, images, billing
  • $383.69: documentation site पर लगभग $400 billing मिलने वाला Mintlify मामला
    • tags: mintlify, ai, documentation
  • $250/month: 9,000 page visits के लिए $250/month, यानी $3,000/year cost की जरूरत पड़ गई
    • tags: framer, bandwidth, images and videos
  • $103.26: free tier usage की स्थिति में $103 डरावना मामला बन गया — AWS case
    • tags: aws, dark-pattern, free-tier

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-03-01
Hacker News की राय

  • सचमुच अफसोसजनक है, और उल्टा पीछे जाने जैसा लगता है। 3.44MB फ़ाइल कोई समस्या नहीं होनी चाहिए, और अगर समस्या हो भी, तो “इसे कहीं और अपलोड करो” जवाब नहीं होना चाहिए
    अगर यहां से सीखने वाली एक बात है तो वह यह है कि मुफ्त जैसी कोई चीज़ नहीं होती, और इतने बड़े नुकसान को किसी न किसी तरह की सीमा लगाकर रोका जा सकना चाहिए। VPS बहुत सस्ते हैं, मैनेज करना भी आसान है, और उनमें automatic limits भी होती हैं: https://lowendbox.com/blog/1-vps-1-usd-vps-per-month/

    • लोग हैरान होते हैं कि अब वेब पर बस कुछ ही वेबसाइटें क्यों बची हैं और long tail क्यों गायब हो गई है; इसकी वजह यह है कि Facebook या Twitter पर 3.44MB ऑडियो अपलोड करने पर आपको बिलिंग की चिंता कभी नहीं करनी पड़ती
    • VPS को “मैनेज करना आसान” कहना कई पूर्वधारणाओं पर टिका हुआ, काफ़ी मजबूत विकल्प है

  • मुझे नहीं लगता कि Netlify वाला मामला serverless architecture की वजह से हुआ। serverless में कई तकनीकी समस्याएं हैं, लेकिन incoming traffic की वजह से बड़ा बिल आना serverless से स्वतंत्र समस्या है
    अगर आप अपना हार्डवेयर colocation में रखें और traffic cost दें, तब भी अगर datacenter DDoS नहीं रोकता और TB के हिसाब से बिल करता है, तो वही चीज़ हो सकती है। बेशक colocation में प्रति TB दर Netlify से बहुत सस्ती होती है, इसलिए 100,000 डॉलर का बिल आने की संभावना कम है, लेकिन तब मुद्दा “serverless horror” नहीं बल्कि बेहद महंगी traffic cost और DDoS mitigation की कमी होना चाहिए

    • अगर सेवा अनंत रूप से scale करती है, तो पैसा जलने की रफ्तार भी अनंत रूप से scale करती है। colocation में एक single server saturate हो जाए तो वह आपके wallet को होने वाला नुकसान भी सीमित कर देता है

  • इस ब्लॉग को बनाने वाले Andres, Heroku/Netlify के self-hosted विकल्प coolify पर भी काम कर रहे हैं। कई महीनों से इस्तेमाल करने पर यह changedetector, jdownloader, vaultwarden जैसी चीज़ों को self-host करना आसान बनाने वाला कोई secret sauce जैसा लगा
    community भी काफी अच्छी तरह बढ़ रही है, लोग नए templates contribute कर रहे हैं और एक-दूसरे को debugging में मदद कर रहे हैं। मैंने Syncthing template भी जोड़कर देखा। हालांकि 10GB storage instance में disk भरते ही कई चीज़ें टूटने लगीं, और इस हिस्से में बेहतर alerts या prevention हो तो अच्छा होगा। इसके अलावा यह काफी stable है
    https://github.com/coollabsio/coolify

  • शायद यह overreaction हो, लेकिन मैंने अपनी personal site Netlify से हटाने का फैसला किया। मुझे HTML डालने की जगह से ज़्यादा कुछ नहीं चाहिए था और मैं Netlify को “काफी अच्छा” मानता था, लेकिन मुझे नहीं पता था कि ऐसी समस्या भी है
    हाल में जिस site को नुकसान हुआ, वह daily visitors, पहचान और niche nature के मामले में मेरी site जैसी ही थी, इसलिए बात ज्यादा वास्तविक लगी। मैं HTML local में build करके कहीं upload करने वाला तरीका पसंद करता हूं, इसलिए migration के लिए DNS update ही काफी होगा। अजीब बात यह लगी कि Netlify, Vercel, Cloudflare जैसे ज्यादातर popular विकल्प असल में spending limit देते ही नहीं। यह तो बहुत basic feature जैसा लगता है

    • Cloudflare Pages में free bandwidth unlimited है, इसलिए traffic free है और limit की जरूरत नहीं पड़ती
    • मैं Vercel में काम करता हूं, और Vercel में DDoS protection और spending limits हैं। हम दोनों में जल्द ही और सुधार जारी करने पर काम कर रहे हैं
      https://vercel.com/blog/introducing-spend-management-realtime...
    • Cloudflare में DDoS protection है, और इसे लगभग paranoid level तक configure किया जा सकता है। DDoS शुरू होने पर आप सबको CAPTCHA दिखा सकते हैं, जिससे खर्च काफी प्रभावी ढंग से सीमित हो जाता है

  • Reddit पोस्ट में link किए गए Netlify comment thread को भी देखना चाहिए: https://answers.netlify.com/t/limit-bandwidth-to-avoid-high-...
    Netlify का प्रतिनिधि साफ़ तौर पर कह रहा है कि free tier पर भी अगर DDoS हो जाए, तो बेतुके bandwidth bill को रोकने के लिए वे कुछ नहीं करेंगे

    • इन services में मुझे सबसे ज्यादा नापसंद चीज़ यह है कि stop-loss जैसी कोई सुविधा नहीं है। आप alerts set करें तो वे बता देते हैं, लेकिन बस इतना ही, और कई मामलों में alert नुकसान हो जाने के काफी देर बाद आता है
      कुछ billing metrics में reports या alerts कई घंटे late हो सकते हैं। default सुरक्षित होना चाहिए, और limits बढ़ाना आसान होना चाहिए
    • पहले server को बंद कर दिया जाता था, अब संरचना ऐसी हो गई है कि serverless website पर DDoS पड़ता है और 100,000 डॉलर का bill आ जाता है
      मुझे नहीं पता यह business model sustainable है या नहीं। जब server आपके अपने होते थे, तो plug खींच सकते थे, लेकिन अब यह जानने का कोई तरीका नहीं कि कोई /api को प्रति मिनट दस लाख बार call करेगा या नहीं
    • क्या free tier को fake name से इस्तेमाल करके बेतुके bill को छोड़ नहीं सकते? जानना चाहूंगा कि वे customer verification कैसे करते हैं
    • मुझे लगता है शायद Netlify funding crunch से गुजर रहा है, इसलिए ऐसी चीज़ हो रही है। पहले Netlify बहुत अच्छा और unique service था, लेकिन अब GitHub, GitLab, Cloudflare Pages लगभग वही service सस्ते में देते हैं
    • free tier पर ऐसा हो जाए तो क्या करना चाहिए? बस bill न चुकाकर चले जाएं? क्या वे सचमुच collection के लिए आएंगे?

  • क्लाउड provider उन चीज़ों के लिए ज़रूरत से ज़्यादा बिल करे जिनके लिए उसे बिल करने का अधिकार है, तो यह कुछ ऐसा लगता है जैसे कार mechanic routine चेकअप के दौरान कहे कि एक छोटा पार्ट खराब हो गया है, और उसी वजह से replacement भी लगातार खराब होते जा रहे हैं, इसलिए वह अनंत loop में उन्हें बदलता रहे, 2 हफ्ते तक कोई जानकारी न दे, और आखिर में जब मैं garage जाकर रुकने को कहूँ तो खराब हुए 999,999,999 पार्ट्स की लागत बिल कर दे
    एक बड़े संगठन के बजाय छोटे user के रूप में मैं हर कोने-कोने की tuning documentation नहीं पढ़ सकता। मैं एक fixed limit चाहता हूँ, जहाँ तय spending limit पर पहुँचते ही सब कुछ kill हो जाए, और ज़रूरत पड़े तो data भी खोना स्वीकार हो। लेकिन शायद ऐसा इसलिए नहीं किया जाता क्योंकि अगर users budget को लेकर सावधान रहें तो revenue को नुकसान होता है, और कभी-कभी bill पहले से calculate करना मुश्किल भी होता है

    • फर्क है। उदाहरण वाले mechanic ने स्थिति खुद बनाई थी, लेकिन Netlify ने ऐसा नहीं किया, और unwanted traffic और रातों-रात सफल हुए SaaS में फर्क करना भी मुश्किल हो सकता है
      ज्यादा सटीक analogy यह होगी कि कोई भी व्यक्ति जिसे license plate पता हो, mechanic से जो चाहे request करने को कहे, और mechanic उसे वैसा ही कर दे

  • हाल ही में मैंने OpenAI API key बनाई, और default रूप से यह quota enforce करती है और limit पर पहुँचते ही key को disable कर देती है। जब user ज्यादा requests संभालने के लिए तैयार हो, तो वह manually quota बढ़ाता है
    ऐसे surprise bills रोकने के लिए ज्यादा कंपनियाँ default रूप से ऐसा नहीं करतीं, यह हैरान करने वाला है। सोचें तो शायद इसलिए कि आखिरकार कई बार user बस पैसे दे देता है

    • फर्क यह है कि OpenAI की inference cost सच में लगती है, इसलिए उसके हित जुड़े हैं। जब Netlify bandwidth पर 1000x charge करता है, तो service देने की लागत लगभग नहीं होती, इसलिए अगर user न भी दे तो शायद उन्हें वास्तव में बहुत फर्क न पड़े

  • मेरे हिसाब से सबसे बड़ा cloud horror serverless न भी हो सकता है; बल्कि यह कि हमने cloud provider के fail होने की स्थिति से बचाव के नाम पर availability zones के बीच traffic cost देना स्वीकार कर लिया है
    दूसरे शब्दों में, provider अपने संभावित problems को mitigate करने की cost भी users से काफी ज्यादा वसूल रहा है

  • इस thread में सब कह रहे हैं कि यह serverless problem नहीं, cloud problem है; बात सही है, लेकिन core मुद्दा फिर भी रहता है। Bandwidth लगभग pure margin है, और bandwidth के लिए इतना महंगा charge करते हुए customer के control से बाहर के attacks से निपटने के tools न देना काफी गंदा लगता है
    इस thread के मुताबिक, Netlify में DDoS attack के दौरान site को थोड़ी देर के लिए नीचे करने का option भी नहीं है: https://answers.netlify.com/t/limiting-bandwidth-traffic-to-...
    Netlify के पास billing controls, request limiting, bandwidth cap, अगर असली DDoS हो तो overage waiver जैसे कई solutions हो सकते हैं, लेकिन ऐसा करना सोने के अंडे देने वाली मुर्गी को मारने जैसा होगा, इसलिए उसमें उनकी दिलचस्पी नहीं दिखती। bunny.net CDN जो features देता है, उसे देखना ही तुलना के लिए काफी है: https://support.bunny.net/hc/en-us/articles/360014190440-Und...
    cloud providers की explanation को greed के अलावा किसी और चीज़ से समझाना मुश्किल है, फिर भी हम इसे इतनी आसानी से स्वीकार कर लेते हैं—यह निराशाजनक है

  • Spending cap न होना serverless problem क्यों है? यह तो cloud problem है
    हालांकि छोटा cloud server हो तो attack होने पर down हो सकता है, और अगर AWS की तरह केवल outgoing traffic के लिए charge हो, तो वह user के पक्ष में है

    • क्योंकि serverless traditional model की तुलना में usage-based billing ज्यादा बार इस्तेमाल करता है, और बड़े पैमाने की usage तक बेहतर scale भी हो जाता है
      मेरे $5/month वाले DigitalOcean VPS को DDoS करें तो compute cost नहीं बढ़ेगी, और transfer cost बहुत जमा होने से पहले ही यह संभवतः load नहीं झेल पाएगा और गिर जाएगा। DigitalOcean transfer भी usage-based है, लेकिन उससे पहले ही limit आ जाएगी
    • यह cloud problem नहीं है। cloud आखिरकार किसी और का computer ही है
      यह billing problem है या architecture problem। overbilling रोकने के लिए requests limit करने की सुविधा देनी चाहिए, या एक खास amount पर पहुँचते ही disconnect कर देना चाहिए
    • यह architecture failure है। maximum सेट करना जरूरी है। अगर आप ऐसा platform चुनते हैं जो यह feature support नहीं करता, तो इसमें आपकी भी जिम्मेदारी है
      traditional environments में circuit breaker लगाना implicitly ज्यादा आसान होता है, लेकिन फिर भी इसे जरूर consider करना चाहिए। success और failure, दोनों स्थितियों के लिए load testing करनी चाहिए
    • Spending cap न होना serverless problem इसलिए है क्योंकि cloud इस्तेमाल करने पर इसे mitigate किया जा सकता है, लेकिन serverless में नहीं
      cloud instances इस्तेमाल करने वाले मुझे यह problem नहीं है और आगे भी नहीं होगी। अगर serverless होता, तो मैं इस problem से गुजरता