กรณีสยองของเทคโนโลยี Serverless

 (serverlesshorrors.com)
2 คะแนน โดย GN⁺ 2024-03-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นเว็บไซต์ที่รวบรวมกรณีจริงซึ่งแสดงให้เห็น ความเสี่ยงค่าใช้จ่ายพุ่งกระฉูด ที่ซ่อนอยู่เบื้องหลังความสะดวกของการคิดค่าบริการตามการใช้งาน
  • สามารถเปรียบเทียบ บิลที่คาดไม่ถึง ที่เกิดกับ Cloudflare, Vercel, AWS, Firebase, Netlify, BigQuery ฯลฯ แยกตามบริการและสาเหตุได้
  • แม้แต่โปรเจกต์เล็กหรือบริการส่วนบุคคลก็อาจกลายเป็นบิลมูลค่าสูงได้ในพริบตา เช่น บิล Cloudflare $36,000, Vercel $46,485.99 หรือ Firebase $100,000 ในวันเดียว
  • สาเหตุที่เกิดซ้ำคือ แบนด์วิดท์, DDoS/DoS, สตอเรจ, การใช้งานที่ implement ผิด, recursion, queue loop และปริมาณการใช้งานที่เพิ่มขึ้นเกี่ยวกับ event, รูปภาพ, documentation และ AI
  • เมื่อใช้บริการแบบ serverless และ pay-as-you-go ควรตรวจสอบเพดานค่าใช้จ่าย, cache, รูปแบบ request และ loop อัตโนมัติทั้งก่อนและหลัง deploy

ลักษณะของเว็บไซต์และวิธีส่งเคส

  • ServerlessHorrors เป็นบล็อกเรียบง่ายที่รวบรวมให้อ่านกรณีค่าใช้จ่ายและเหตุขัดข้องที่เกิดระหว่างใช้งาน serverless
  • ผู้สร้างคือ Andras ซึ่งทำงานเกี่ยวกับ Coolify, Jean และโปรเจกต์โอเพนซอร์สหลายรายการ รวมถึงงานที่เกี่ยวข้องกับ coolLabs
  • รับการแจ้งเคสผ่าน 2 ช่องทาง

กรณีเด่นที่นำไปสู่บิลมูลค่าสูง

  • $36,000: โปรเจกต์ข้างเคียง RetainDB ได้รับบิล Cloudflare $36k ทั้งที่มีผู้ใช้ 81 คน
    • สาเหตุคือ Durable Object writes 16B ครั้ง, runaway queue loop, Durable Object writes ที่ไม่ได้ batch และ KV list scan ที่รันทุก request
    • แท็ก: cloudflare, workers, durable-objects, kv, queues
  • $46,485.99: Jmail มียอด pageviews เกิน 450M และแม้หลังจากลดผลกระทบด้วย cache จำนวนมากแล้ว บิล Vercel ก็ยังเพิ่มเป็น $46k
    • แท็ก: vercel, bandwidth
  • $100,000.420: เว็บไซต์อัปโหลดเกม WebGL ที่ได้รับความนิยมพอสมควรถูก DoS จนบิล Firebase ในวันเดียวกลายเป็น $100k
    • แท็ก: google, storage, firebase
  • $120,000.420: กรณีที่ Cloudflare พยายามเรียกให้จ่าย $120k ภายใน 24 ชั่วโมง แล้วถอดเว็บไซต์ลง
    • แท็ก: cloudflare, bandwidth
  • $104,500.123: กรณีได้รับอีเมลแจ้งบิลค้างชำระ $104,500.00 จาก Netlify
    • แท็ก: netlify, bandwidth, ddos
  • $96,280.69: กรณีบิลมูลค่าสูงที่เกี่ยวกับ bandwidth ของ Vercel
    • แท็ก: vercel, bandwidth, new
  • $72,000.999: กรณีทดสอบ Firebase + Cloud Run แล้วเผาเงินไป $72K จนเกือบล้มละลาย
    • แท็ก: google, firebase, cloudrun, wrong-implementation, recursion
  • $70,000.69: โปรเจกต์ที่เคยจ่ายเดือนละ $50 อยู่ดี ๆ วันหนึ่งก็มีบิล $70,000 ออกมา
    • แท็ก: google, storage, firebase, gcs

กรณีเพิ่มเติมที่บันทึกไว้แยกตามบริการ

  • $23,000.420: EchoFox ถูกสแปมจนบิล Vercel พุ่งเป็น $23k และเกิด 56k+ accounts and trials
    • แท็ก: vercel, bandwidth, ddos
  • $22.639,69: แค่ใช้ชุดข้อมูลสาธารณะใน BigQuery playground แต่ได้รับบิล 22k USD
    • แท็ก: google, bigquery, sql
  • $11,000.69: ระหว่างถูกโจมตี DoS มีการส่งอีเมลมูลค่า $11k และสูญเสียฐานข้อมูล
    • แท็ก: ddos, mailgun
  • $4,241.69: กรณีที่ระงับบริการชั่วคราวแล้ว แต่ AWS บล็อกและต้องจ่ายค่าใช้จ่าย
    • แท็ก: aws
  • $3,000.69: กรณีเตือนให้ระวังเมื่อทดสอบหรือ deploy บน Vercel
    • แท็ก: vercel, bandwidth, wrong-implementation
  • $1,300.69: เกิดค่าใช้จ่ายหลังสร้าง AWS S3 bucket ที่ว่างและเป็น private ใน region ที่ต้องการ
    • แท็ก: aws, s3, security, ddos
  • $1273.69: เกิดค่าใช้จ่าย PostHog หลังขอให้ Devin AI เปลี่ยนแปลง codebase
    • แท็ก: posthog, devin, ai, cognition-labs, new
  • ~$1189.420/month: ในแผน $69/month Webflow เรียกเก็บ $1189.420 ในเดือนเดียว
    • แท็ก: webflow, bandwidth, image
  • $738.420: สมัคร Vercel Pro เดือนละ $20 และเพิ่ม spending limit $120 แล้ว แต่ก็ยังเกิดบิล
    • แท็ก: vercel, bandwidth, vercels-mistake, spending-limit
  • $620.123: กรณี Vercel ที่ sitemap.txt ใช้งานหลายร้อย GB/hours
    • แท็ก: vercel, bandwidth
  • $530.19: กรณี PostHog ที่ไม่เคยเสียค่าใช้จ่ายมาก่อน แต่จู่ ๆ ถูกเรียกเก็บ $530
    • แท็ก: posthog, events, new
  • $400.69: Cloudflare Images เรียกเก็บ $400 ต่อเดือนแทนที่จะเป็น $110 ตามคาด พร้อมมีการคิดเงินล่วงหน้าที่สับสนและการขาดการสนับสนุนเกิน 8 เดือน
    • แท็ก: cloudflare, images, billing
  • $383.69: กรณี Mintlify ที่ได้รับบิลเกือบ $400 สำหรับเว็บไซต์ documentation
    • แท็ก: mintlify, ai, documentation
  • $250/month: ต้องเสียค่าใช้จ่าย $250 ต่อเดือน หรือ $3,000 ต่อปี สำหรับ 9,000 page visits
    • แท็ก: framer, bandwidth, images and videos
  • $103.26: กรณี AWS ที่ $103 กลายเป็นเคสสยองในสถานการณ์ใช้งาน free tier
    • แท็ก: aws, dark-pattern, free-tier

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-01
ความคิดเห็นจาก Hacker News

  • น่าเสียดายจริง ๆ และรู้สึกเหมือนถอยหลังด้วยซ้ำ ไฟล์ขนาด 3.44MB ไม่ควรกลายเป็นปัญหา และถึงจะเป็นปัญหา คำตอบก็ไม่ควรเป็น “ไปอัปโหลดไว้ที่อื่น”
    ถ้ามีบทเรียนหนึ่งอย่างจากเรื่องนี้ก็คือ ไม่มีอะไรฟรีจริง และความเสียหายใหญ่แบบนี้ควรถูกป้องกันได้ด้วยการตั้งขีดจำกัดในรูปแบบใดรูปแบบหนึ่ง VPS ราคาถูกมากและจัดการง่าย แถมมีขีดจำกัดอัตโนมัติด้วย: https://lowendbox.com/blog/1-vps-1-usd-vps-per-month/

    • คนสงสัยกันว่าทำไมตอนนี้เหลือเว็บไซต์อยู่แค่ไม่กี่แห่งและ long tail หายไป ก็เพราะบน Facebook หรือ Twitter ต่อให้อัปโหลดเสียงขนาด 3.44MB ก็ไม่ต้องกังวลเรื่องโดนเรียกเก็บเงินเลย
    • การบอกว่า VPS “จัดการง่าย” เป็นตัวเลือกที่ค่อนข้างแรงและตั้งอยู่บนสมมติฐานหลายอย่าง

  • ไม่คิดว่ากรณีของ Netlify เกิดจาก สถาปัตยกรรม serverless เอง serverless มีปัญหาทางเทคนิคมากมายก็จริง แต่ปัญหาการได้รับบิลก้อนใหญ่เพราะทราฟฟิกขาเข้านั้นแยกจาก serverless
    ต่อให้เอาเครื่องของตัวเองไปวางแบบ colocation และจ่ายค่าทราฟฟิก ถ้าศูนย์ข้อมูลไม่ช่วยกัน DDoS ให้และคิดเงินเป็นระดับ TB เรื่องเดียวกันก็เกิดขึ้นได้ แน่นอนว่า colocation มีราคาต่อ TB ถูกกว่า Netlify มาก โอกาสได้บิล 100,000 ดอลลาร์จึงต่ำกว่า แต่ถ้าอย่างนั้นประเด็นหลักก็ไม่ควรเป็น “ความสยองของ serverless” แต่ควรเป็น ค่าทราฟฟิกที่แพงเกินเหตุ และการไม่มี DDoS mitigation

    • เมื่อบริการขยายได้ไม่จำกัด อัตราการเผาเงิน ก็ขยายได้ไม่จำกัดเช่นกัน เซิร์ฟเวอร์เดี่ยวใน colocation ถ้าเต็มความจุแล้ว ความเสียหายที่ทำกับกระเป๋าเงินก็ถูกจำกัดไปด้วย

  • Andres ผู้สร้างบล็อกนี้ก็กำลังทำ coolify ซึ่งเป็นทางเลือกแบบ self-hosting แทน Heroku/Netlify ด้วย หลังใช้มาหลายเดือน มันเหมือนซอสลับที่ช่วยให้ self-host ของอย่าง changedetector, jdownloader, vaultwarden ได้ง่ายขึ้น
    ชุมชนก็กำลังเติบโตได้ค่อนข้างดี ผู้คนช่วยกันส่ง template ใหม่ ๆ และช่วยกัน debug ผมลองเพิ่ม template ของ Syncthing ไปด้วย แต่พอดิสก์เต็มบนอินสแตนซ์พื้นที่ 10GB หลายอย่างก็พังลงมา ตรงนี้ถ้ามีการแจ้งเตือนหรือการป้องกันที่ดีกว่านี้ก็น่าจะดี นอกนั้นถือว่าค่อนข้างเสถียร
    https://github.com/coollabsio/coolify

  • อาจจะเป็นการตอบสนองเกินเหตุ แต่ตัดสินใจย้ายเว็บส่วนตัวออกจาก Netlify แล้ว เดิมไม่ได้ต้องการอะไรมากไปกว่าที่สำหรับวาง HTML และคิดว่า Netlify “ดีพอ” แต่ไม่รู้มาก่อนว่ามีปัญหาแบบนี้
    เว็บไซต์ที่เสียหายล่าสุดมีจำนวนผู้เข้าชมต่อวัน ระดับการเป็นที่รู้จัก และลักษณะเฉพาะกลุ่มคล้ายกับเว็บของผม เลยรู้สึกใกล้ตัวมากขึ้น ผมชอบวิธี build HTML ในเครื่องแล้วอัปโหลดไปไว้ที่ไหนสักแห่งอยู่แล้ว ดังนั้นการย้ายจริง ๆ ก็แค่อัปเดต DNS สิ่งที่แปลกคือ ตัวเลือกยอดนิยมส่วนใหญ่ เช่น Netlify, Vercel, Cloudflare ไม่ได้มี ขีดจำกัดการใช้จ่าย ให้จริง ๆ ทั้งที่ดูเหมือนเป็นฟีเจอร์พื้นฐานมาก

    • Cloudflare Pages มีแบนด์วิดท์ฟรีไม่จำกัด ทราฟฟิกจึงฟรี และเลยไม่จำเป็นต้องมีขีดจำกัด
    • ผมทำงานที่ Vercel และ Vercel มี การป้องกัน DDoS กับขีดจำกัดการใช้จ่าย ทั้งสองอย่างกำลังมีการปรับปรุงเพิ่มเติมที่จะเปิดเผยเร็ว ๆ นี้
      https://vercel.com/blog/introducing-spend-management-realtime...
    • Cloudflare มีการป้องกัน DDoS และสามารถตั้งค่าได้ละเอียดจนแทบจะระดับหวาดระแวงได้เลย เมื่อ DDoS เริ่มขึ้น สามารถบังคับให้ทุกคนเจอ CAPTCHA ได้ จึงจำกัดค่าใช้จ่ายได้ค่อนข้างมีประสิทธิภาพ

  • เธรดความคิดเห็นของ Netlify ที่ลิงก์อยู่ในโพสต์ Reddit หนึ่งก็น่าอ่าน: https://answers.netlify.com/t/limit-bandwidth-to-avoid-high-...
    ตัวแทนของ Netlify พูดชัดเจนว่า แม้จะเป็น tier ฟรี หากถูก DDoS ก็จะไม่ทำอะไรเพื่อป้องกันบิลค่าแบนด์วิดท์ที่ไม่สมเหตุสมผล

    • สิ่งที่ไม่ชอบที่สุดในบริการพวกนี้คือไม่มี ฟีเจอร์ที่เทียบได้กับ stop-loss ถ้าตั้งการแจ้งเตือนไว้ก็จะแจ้งให้ทราบ แต่นั่นคือทั้งหมด และหลายครั้งการแจ้งเตือนก็มาหลังจากเกิดความเสียหายไปนานแล้ว
      ตัวชี้วัดการคิดเงินบางอย่างมีรายงานหรือการแจ้งเตือนช้าหลายชั่วโมง ค่าเริ่มต้นควรปลอดภัย และการเพิ่มขีดจำกัดควรทำได้ง่าย
    • เมื่อก่อนก็แค่ปิดเซิร์ฟเวอร์ทิ้ง แต่ตอนนี้กลายเป็นโครงสร้างที่เว็บ serverless โดน DDoS แล้วได้รับ บิล 100,000 ดอลลาร์
      ไม่รู้ว่าโมเดลธุรกิจแบบนี้จะยั่งยืนได้ไหม สมัยที่เราเป็นเจ้าของเซิร์ฟเวอร์ เรายังดึงปลั๊กได้ แต่ตอนนี้ไม่มีทางรู้เลยว่าใครจะเรียก /api หนึ่งล้านครั้งต่อนาที
    • ใช้ tier ฟรีด้วยชื่อปลอมแล้วทิ้งบิลมหาศาลไปเลยไม่ได้หรือ? อยากรู้ว่าพวกเขาตรวจสอบลูกค้ากันอย่างไร
    • สงสัยว่า Netlify กำลังมีปัญหาทางการเงินอยู่หรือเปล่า ถึงเกิดเรื่องแบบนี้ขึ้น เมื่อก่อน Netlify เป็นบริการที่ดีและมีเอกลักษณ์มาก แต่ตอนนี้ GitHub, GitLab, Cloudflare Pages ให้บริการแทบเหมือนกันในราคาถูกกว่า
    • ถ้าเรื่องแบบนี้เกิดใน tier ฟรีควรทำอย่างไร? แค่ไม่จ่ายบิลแล้วจากไปก็ได้ไหม? เขาจะมาตามทวงจริง ๆ หรือเปล่า?

  • การที่ผู้ให้บริการคลาวด์เรียกเก็บเงินเกินควรในรายการที่ตนมีสิทธิ์เรียกเก็บ รู้สึกคล้ายกับช่างซ่อมรถที่ระหว่างตรวจเช็ก routine เจอว่าชิ้นส่วนเล็ก ๆ เสีย แล้วอะไหล่ที่เปลี่ยนก็เสียต่อเนื่องด้วยเหตุผลเดียวกัน จึงเปลี่ยนวนซ้ำไม่รู้จบโดยไม่แจ้งข้อมูลอะไรเลยเป็นเวลา 2 สัปดาห์ สุดท้ายพอผมไปที่อู่แล้วบอกให้หยุด ก็เรียกเก็บค่า ชิ้นส่วนที่เสีย 999,999,999 ชิ้น
    ในฐานะผู้ใช้รายเล็กที่ไม่ใช่องค์กรขนาดใหญ่ เราไม่สามารถอ่านเอกสารการปรับแต่งทุกซอกทุกมุมได้หมด ต้องการเพดานแบบตายตัวที่เมื่อถึงวงเงินใช้จ่ายที่กำหนดไว้ก็ปิดทุกอย่างไปเลย และถ้าจำเป็นถึงขั้นข้อมูลหายก็ยอมได้ แต่ดูเหมือนพวกเขาจะไม่ทำแบบนั้น เพราะถ้าผู้ใช้ระวังงบประมาณ รายได้ก็จะเสียหาย และบางกรณีก็คำนวณยอดเรียกเก็บล่วงหน้าได้ยากด้วย

    • มีความต่างอยู่ ช่างในตัวอย่างเป็นคนสร้างสถานการณ์นั้นเอง แต่ Netlify ไม่ได้ทำ และอาจแยกแยะได้ยากระหว่างทราฟฟิกที่ไม่ต้องการกับ SaaS ที่ดังขึ้นมาภายในคืนเดียว
      อุปมาที่แม่นกว่าคือมีคนที่รู้เลขทะเบียนรถไปบอกช่างให้ทำตามคำขออะไรก็ได้ แล้วช่างก็ทำตามนั้น

  • เมื่อไม่นานมานี้ผมสร้างคีย์ OpenAI API ซึ่งโดยค่าเริ่มต้นจะบังคับใช้ โควตา และเมื่อถึงลิมิตก็จะปิดใช้งานคีย์ หากผู้ใช้พร้อมรับคำขอมากขึ้น จึงค่อยเพิ่มโควตาด้วยตนเอง
    น่าแปลกที่บริษัทจำนวนมากกว่านี้ไม่ตั้งค่าเริ่มต้นแบบนี้เพื่อกันบิลเซอร์ไพรส์พวกนี้ พอมาคิดดูแล้ว อาจเป็นเพราะสุดท้ายผู้ใช้ก็มักจะยอมจ่ายเงินนั่นแหละ

    • ความต่างคือ OpenAI มีต้นทุนการ inference จริง ๆ จึงมีผลประโยชน์เกี่ยวข้องโดยตรง แต่เมื่อ Netlify คิดค่าแบนด์วิดท์แพงขึ้น 1000 เท่า ต้นทุนการให้บริการแทบไม่มี ดังนั้นต่อให้ผู้ใช้ไม่จ่าย ก็อาจไม่ได้แคร์มากนักในทางปฏิบัติ

  • ผมมองว่าความน่ากลัวที่สุดของคลาวด์อาจไม่ใช่ serverless แต่เป็นการที่เรายอมรับการจ่าย ค่าใช้จ่ายทราฟฟิกข้าม availability zone ด้วยเหตุผลว่าเป็นการเตรียมรับมือหากผู้ให้บริการคลาวด์ล้มเหลว
    กล่าวอีกอย่างคือ ผู้ให้บริการกำลังเรียกเก็บเงินจำนวนไม่น้อยสำหรับค่าใช้จ่ายในการบรรเทาปัญหาที่ตัวผู้ให้บริการเองอาจมี

  • ในเธรดนี้ทุกคนบอกว่านี่ไม่ใช่ปัญหา serverless แต่เป็นปัญหาคลาวด์ ซึ่งก็ถูก แต่ประเด็นหลักยังคงอยู่ แบนด์วิดท์แทบจะเป็นกำไรสุทธิ และการคิดค่าแบนด์วิดท์แพงขนาดนี้พร้อมกับไม่ให้เครื่องมือแก่ลูกค้าเพื่อรับมือการโจมตีที่อยู่นอกเหนือการควบคุมของลูกค้า ดูค่อนข้างแย่
    ตามเธรดนี้ Netlify ไม่มีแม้แต่ตัวเลือกให้ปิดไซต์ชั่วคราวระหว่างถูก DDoS: https://answers.netlify.com/t/limiting-bandwidth-traffic-to-...
    Netlify อาจมีวิธีแก้หลายอย่างได้ เช่น การควบคุมการเรียกเก็บเงิน การจำกัดคำขอ เพดานแบนด์วิดท์ หรือถ้าเป็น DDoS จริงก็ยกเว้นส่วนที่เกินให้ แต่ดูเหมือนไม่สนใจ เพราะจะเหมือนฆ่าห่านที่ออกไข่ทองคำ แค่ดูฟีเจอร์ที่ CDN ของ bunny.net มีให้ก็เทียบได้แล้ว: https://support.bunny.net/hc/en-us/articles/360014190440-Und...
    น่าผิดหวังที่เราออกจะยอมรับคำอธิบายของผู้ให้บริการคลาวด์ง่ายเกินไป ทั้งที่อธิบายด้วยอย่างอื่นนอกจากความโลภได้ยาก

  • ทำไมการไม่มีเพดานค่าใช้จ่ายถึงเป็นปัญหา serverless? นั่นคือ ปัญหาคลาวด์ ต่างหาก
    อย่างไรก็ตาม ถ้าเป็นเซิร์ฟเวอร์คลาวด์ขนาดเล็ก เมื่อถูกโจมตีก็อาจล่มได้ และถ้าเหมือน AWS ที่คิดเงินเฉพาะทราฟฟิกขาออก นั่นก็เป็นผลดีกับผู้ใช้

    • เพราะ serverless มักใช้ การคิดเงินตามการใช้งาน บ่อยกว่าโมเดลดั้งเดิม และยัง scale ไปถึงการใช้งานขนาดใหญ่ได้ดีกว่า
      ต่อให้ DDoS VPS DigitalOcean เดือนละ 5 ดอลลาร์ของผม ต้นทุนคอมพิวต์ก็ไม่เพิ่ม และมีแนวโน้มจะรับโหลดไม่ไหวแล้วล่มก่อนที่ค่าโอนข้อมูลจะสะสมมากนัก ปริมาณโอนข้อมูลของ DigitalOcean ก็คิดตามการใช้งานเช่นกัน แต่ก็น่าจะชนเพดานก่อนหน้านั้น
    • นี่ไม่ใช่ปัญหาคลาวด์ คลาวด์สุดท้ายก็เป็นแค่คอมพิวเตอร์ของคนอื่น
      นี่คือ ปัญหาการเรียกเก็บเงิน หรือปัญหาสถาปัตยกรรม ควรให้จำกัดคำขอเพื่อป้องกันการเรียกเก็บเกิน หรือให้ตัดเมื่อถึงยอดเงินที่กำหนด
    • นี่คือ ความล้มเหลวด้านสถาปัตยกรรม การกำหนดค่าสูงสุดเป็นเรื่องสำคัญ ถ้าเลือกแพลตฟอร์มที่ไม่รองรับฟีเจอร์แบบนั้น ตัวเองก็มีส่วนรับผิดชอบด้วย
      ในสภาพแวดล้อมแบบดั้งเดิม การวาง circuit breaker ทำได้ง่ายกว่าโดยนัย แต่ก็ยังต้องพิจารณาอยู่ดี ต้องทำ load test ทั้งกรณีสำเร็จและล้มเหลว
    • เหตุผลที่การไม่มีเพดานค่าใช้จ่ายเป็นปัญหา serverless คือ เมื่อใช้คลาวด์เราสามารถบรรเทาได้ แต่ใน serverless บรรเทาไม่ได้
      ผมใช้คลาวด์อินสแตนซ์ จึงไม่มีปัญหานี้และจะไม่มีต่อไป ถ้าเป็น serverless ก็คงเจอปัญหานี้แล้ว