Những câu chuyện kinh hoàng về công nghệ serverless

 (serverlesshorrors.com)
2 điểm bởi GN⁺ 2024-03-01 | 1 bình luận | Chia sẻ qua WhatsApp
  • Đây là một trang tổng hợp các ví dụ thực tế cho thấy rủi ro chi phí tăng vọt ẩn sau sự tiện lợi của mô hình tính phí theo mức sử dụng
  • Có thể so sánh các khoản hóa đơn ngoài dự kiến phát sinh trên Cloudflare, Vercel, AWS, Firebase, Netlify, BigQuery... theo dịch vụ và nguyên nhân
  • Ngay cả dự án nhỏ hoặc dịch vụ cá nhân cũng có thể nhanh chóng dẫn tới hóa đơn lớn, như hóa đơn một ngày $36,000 trên Cloudflare, $46,485.99 trên Vercel, $100,000 trên Firebase
  • Các nguyên nhân lặp lại gồm băng thông, DDoS/DoS, lưu trữ, triển khai sai, đệ quy, vòng lặp queue, mức sử dụng tăng do sự kiện·hình ảnh·tài liệu·AI
  • Khi dùng serverless và dịch vụ tính tiền theo mức sử dụng, cần kiểm tra hạn mức tính phí, cache, pattern request và các vòng lặp tự động trước và sau khi triển khai

Tính chất của trang và cách gửi câu chuyện

  • ServerlessHorrors là một blog đơn giản để đọc các câu chuyện về hóa đơn và sự cố phát sinh khi dùng serverless
  • Người tạo là Andras, hiện làm các công việc liên quan đến coolLabs và nhiều dự án mã nguồn mở như Coolify, Jean
  • Câu chuyện được tiếp nhận qua hai kênh

Các trường hợp tiêu biểu dẫn tới hóa đơn lớn

  • $36,000: Dự án phụ RetainDB nhận hóa đơn Cloudflare $36k khi mới có 81 người dùng
    • Nguyên nhân là 16B Durable Object writes, runaway queue loop, Durable Object writes không được batch, và KV list scan chạy trên mỗi request
    • Thẻ: cloudflare, workers, durable-objects, kv, queues
  • $46,485.99: Jmail vượt 450M pageviews, và dù đã thực hiện nhiều biện pháp giảm nhẹ bằng cache, hóa đơn Vercel vẫn tăng lên $46k
    • Thẻ: vercel, bandwidth
  • $100,000.420: Một trang upload game WebGL khá phổ biến bị DoS, khiến hóa đơn Firebase trong một ngày lên $100k
    • Thẻ: google, storage, firebase
  • $120,000.420: Trường hợp Cloudflare gỡ website xuống sau khi định yêu cầu trả $120k trong vòng 24 giờ
    • Thẻ: cloudflare, bandwidth
  • $104,500.123: Trường hợp nhận email đòi thanh toán quá hạn $104,500.00 từ Netlify
    • Thẻ: netlify, bandwidth, ddos
  • $96,280.69: Trường hợp hóa đơn lớn liên quan đến bandwidth trên Vercel
    • Thẻ: vercel, bandwidth, new
  • $72,000.999: Trường hợp đốt $72K khi thử nghiệm Firebase + Cloud Run và suýt phá sản
    • Thẻ: google, firebase, cloudrun, wrong-implementation, recursion
  • $70,000.69: Một dự án vốn trả $50/tháng bỗng nhận hóa đơn $70,000 vào một ngày nọ
    • Thẻ: google, storage, firebase, gcs

Các trường hợp bổ sung được ghi nhận theo dịch vụ

  • $23,000.420: EchoFox bị spam, khiến hóa đơn Vercel tăng vọt lên $23k và phát sinh 56k+ accounts and trials
    • Thẻ: vercel, bandwidth, ddos
  • $22.639,69: Chỉ dùng dataset công khai trong BigQuery playground nhưng nhận hóa đơn 22k USD
    • Thẻ: google, bigquery, sql
  • $11,000.69: Trong một cuộc tấn công DoS, email trị giá $11k được gửi đi và cơ sở dữ liệu bị mất
    • Thẻ: ddos, mailgun
  • $4,241.69: Trường hợp đã tạm dừng dịch vụ nhưng AWS chặn và vẫn phải trả chi phí
    • Thẻ: aws
  • $3,000.69: Trường hợp cảnh báo cần cẩn thận khi thử nghiệm hoặc triển khai trên Vercel
    • Thẻ: vercel, bandwidth, wrong-implementation
  • $1,300.69: Phát sinh chi phí sau khi tạo một AWS S3 bucket trống và private ở region mong muốn
    • Thẻ: aws, s3, security, ddos
  • $1273.69: Phát sinh chi phí PostHog sau khi yêu cầu Devin AI thay đổi codebase
    • Thẻ: posthog, devin, ai, cognition-labs, new
  • ~$1189.420/month: Webflow tính $1189.420 trong một tháng dù đang ở gói $69/month
    • Thẻ: webflow, bandwidth, image
  • $738.420: Dù đăng ký Vercel Pro với $20/tháng và thêm spending limit $120, hóa đơn vẫn phát sinh
    • Thẻ: vercel, bandwidth, vercels-mistake, spending-limit
  • $620.123: Trường hợp Vercel trong đó sitemap.txt đã dùng hàng trăm GB/hours
    • Thẻ: vercel, bandwidth
  • $530.19: Trường hợp PostHog trước đó chưa từng trả phí nhưng bỗng bị tính $530
    • Thẻ: posthog, events, new
  • $400.69: Cloudflare Images tính $400/tháng thay vì mức dự kiến $110, kèm cơ chế tính phí trả trước gây khó hiểu và hơn 8 tháng không có hỗ trợ
    • Thẻ: cloudflare, images, billing
  • $383.69: Trường hợp Mintlify nhận hóa đơn gần $400 cho trang tài liệu
    • Thẻ: mintlify, ai, documentation
  • $250/month: Với 9,000 page visits, chi phí trở thành $250/tháng, tức $3,000/năm
    • Thẻ: framer, bandwidth, images and videos
  • $103.26: Trường hợp AWS trong đó $103 trở thành một câu chuyện kinh hoàng khi đang dùng free tier
    • Thẻ: aws, dark-pattern, free-tier

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-03-01
Ý kiến trên Hacker News

  • Thật đáng tiếc, và thậm chí có cảm giác như đang đi lùi. Một tệp 3,44MB lẽ ra không nên là vấn đề, và kể cả có là vấn đề thì câu trả lời cũng không nên là “hãy đưa nó lên chỗ khác”
    Nếu có một điều rút ra ở đây thì đó là không có gì là miễn phí, và những tổn thất lớn như vậy đáng lẽ phải có thể được ngăn bằng cách đặt giới hạn dưới một hình thức nào đó. VPS rất rẻ, cũng dễ quản lý, và có giới hạn tự động: https://lowendbox.com/blog/1-vps-1-usd-vps-per-month/

    • Mọi người thắc mắc vì sao giờ đây chỉ còn lại vài website và long tail đã biến mất; đó là vì nếu bạn tải một file audio 3,44MB lên Facebook hay Twitter thì tuyệt đối không phải lo bị tính phí
    • Nói VPS “dễ quản lý” là một lựa chọn khá mạnh, dựa trên nhiều giả định

  • Tôi không nghĩ trường hợp Netlify xảy ra là do kiến trúc serverless. Serverless có nhiều vấn đề kỹ thuật, nhưng chuyện nhận hóa đơn lớn vì lưu lượng truy cập đến là vấn đề độc lập với serverless
    Ngay cả khi bạn đặt thiết bị của mình trong colocation và trả phí traffic, nếu trung tâm dữ liệu không chặn DDoS và tính phí theo đơn vị TB thì chuyện tương tự cũng có thể xảy ra. Tất nhiên, với colocation thì đơn giá mỗi TB rẻ hơn Netlify rất nhiều nên khả năng có hóa đơn 100.000 đô la là thấp, nhưng nếu vậy trọng tâm nên là chi phí traffic đắt phi lý và thiếu giảm thiểu DDoS, chứ không phải “nỗi kinh hoàng serverless”

    • Nếu dịch vụ mở rộng vô hạn thì tốc độ đốt tiền cũng mở rộng vô hạn. Một máy chủ đơn lẻ trong colocation khi bị bão hòa thì mức thiệt hại có thể gây ra cho ví tiền của bạn cũng bị giới hạn

  • Andres, người tạo blog này, cũng đang làm coolify, một lựa chọn self-host thay thế cho Heroku/Netlify. Sau vài tháng sử dụng, nó giống như thứ “gia vị bí mật” giúp self-host các thứ như changedetector, jdownloader, vaultwarden trở nên dễ dàng hơn
    Cộng đồng cũng đang phát triển khá tốt: mọi người đóng góp template mới và giúp nhau debug. Tôi cũng đã thử thêm template Syncthing. Tuy nhiên khi ổ đĩa bị đầy trên một instance có 10GB dung lượng lưu trữ thì nhiều thứ bắt đầu sụp đổ; phần này sẽ tốt hơn nếu có cảnh báo hoặc biện pháp phòng ngừa tốt hơn. Ngoài ra thì nó khá ổn định
    https://github.com/coollabsio/coolify

  • Có thể là phản ứng thái quá, nhưng tôi đã quyết định chuyển website cá nhân của mình khỏi Netlify. Tôi không cần gì hơn ngoài một nơi để ném HTML lên, và từng nghĩ Netlify là “đủ tốt”, nhưng không biết lại có vấn đề như thế này
    Website bị ảnh hưởng gần đây khá giống website của tôi về số lượt truy cập hằng ngày, độ nhận diện và tính chất ngách, nên cảm giác rất thực tế. Tôi thích build HTML ở local rồi upload lên đâu đó, nên việc chuyển đi về cơ bản chỉ cần cập nhật DNS. Điều kỳ lạ là hầu hết các lựa chọn phổ biến như Netlify, Vercel, Cloudflare đều không thực sự cung cấp giới hạn chi tiêu. Nó trông như một tính năng quá cơ bản

    • Cloudflare Pages có băng thông miễn phí không giới hạn, nên traffic là miễn phí và vì vậy không cần giới hạn
    • Tôi đang làm việc tại Vercel, và Vercel có bảo vệ DDoS cùng giới hạn chi tiêu. Chúng tôi đang chuẩn bị công bố thêm các cải tiến cho cả hai
      https://vercel.com/blog/introducing-spend-management-realtime...
    • Cloudflare có bảo vệ DDoS, và có thể cấu hình gần như ở mức hoang tưởng. Khi DDoS bắt đầu, bạn có thể buộc CAPTCHA hiện ra cho tất cả mọi người, nhờ đó hạn chế chi tiêu khá hiệu quả

  • Chuỗi bình luận của Netlify được liên kết trong một bài Reddit cũng đáng xem: https://answers.netlify.com/t/limit-bandwidth-to-avoid-high-...
    Đại diện Netlify nói rõ rằng ngay cả ở gói miễn phí, nếu bị DDoS thì họ sẽ không làm gì để ngăn các hóa đơn băng thông phi lý

    • Điều tôi không thích nhất ở các dịch vụ kiểu này là không có tính năng tương đương stop-loss. Bạn đặt cảnh báo thì họ sẽ báo, nhưng chỉ có vậy; trong nhiều trường hợp cảnh báo chỉ đến khá lâu sau khi thiệt hại đã xảy ra
      Một số chỉ số tính phí còn bị trễ vài giờ trong báo cáo hoặc cảnh báo. Mặc định nên an toàn, và việc nâng giới hạn nên dễ dàng
    • Trước đây thì người ta hạ server xuống, còn giờ cấu trúc đã thành: website serverless bị DDoS và nhận hóa đơn 100.000 đô la
      Tôi không biết mô hình kinh doanh này có bền vững không. Thời còn sở hữu server thì có thể rút phích cắm, nhưng giờ không có cách nào biết ai sẽ gọi /api một triệu lần mỗi phút
    • Không thể dùng gói miễn phí bằng tên giả rồi bỏ mặc hóa đơn vô lý sao? Tôi tò mò họ xác minh khách hàng như thế nào
    • Tôi tự hỏi có phải Netlify đang gặp khó khăn tài chính nên những chuyện như thế này mới xảy ra không. Netlify trước đây là một dịch vụ rất tốt và độc đáo, nhưng giờ GitHub, GitLab, Cloudflare Pages cung cấp dịch vụ gần như tương tự với giá rẻ hơn
    • Nếu chuyện này xảy ra ở gói miễn phí thì nên làm gì? Cứ không trả hóa đơn rồi bỏ đi là được à? Họ có thật sự đến đòi nợ không?

  • Việc nhà cung cấp đám mây tính phí quá mức cho những hạng mục mà họ có quyền tính phí khiến tôi cảm thấy giống như một thợ sửa ô tô, trong lúc kiểm tra routine, phát hiện một linh kiện nhỏ bị hỏng, rồi vì cùng lý do đó linh kiện thay thế cũng liên tục hỏng, cứ thế thay đi thay lại vô hạn mà không báo gì trong 2 tuần; cuối cùng khi tôi đến gara bảo dừng lại thì họ tính tiền 999.999.999 linh kiện bị hỏng
    Với tư cách là một người dùng nhỏ lẻ, không phải tổ chức lớn, tôi không thể đọc hết mọi tài liệu điều chỉnh ở mọi ngóc ngách. Tôi muốn có một hạn mức cứng: khi chạm đến giới hạn chi tiêu đã định thì tắt toàn bộ, và nếu cần thì mất cả dữ liệu cũng được. Nhưng có lẽ họ không làm vậy vì nếu người dùng cẩn thận với ngân sách thì sẽ hại doanh thu, và cũng có những trường hợp khó tính trước số tiền phải trả

    • Có khác biệt. Người thợ sửa trong ví dụ đã trực tiếp tạo ra tình huống đó, còn Netlify thì không; cũng có thể khó phân biệt giữa lưu lượng không mong muốn và một SaaS thành công chỉ sau một đêm
      Một phép so sánh chính xác hơn là: bạn nói với thợ sửa rằng ai biết biển số xe thì yêu cầu gì cũng làm, và thợ sửa cứ thế thực hiện

  • Gần đây tôi tạo khóa OpenAI API, và mặc định nó cưỡng chế quota, khi đạt giới hạn thì vô hiệu hóa khóa. Khi người dùng sẵn sàng xử lý nhiều yêu cầu hơn thì tự tăng quota thủ công
    Thật ngạc nhiên là không có nhiều công ty đặt mặc định như vậy để tránh các hóa đơn bất ngờ kiểu này. Nghĩ lại thì có lẽ vì cuối cùng người dùng thường vẫn trả tiền

    • Khác biệt là OpenAI thực sự phát sinh chi phí suy luận, nên họ có lợi ích liên quan. Khi Netlify tính phí băng thông gấp 1000 lần, chi phí cung cấp dịch vụ gần như không đáng kể, nên dù người dùng không trả họ có thể cũng không thực sự bận tâm lắm

  • Nỗi kinh hoàng lớn nhất của đám mây có lẽ không phải serverless, mà là việc chúng ta đã chấp nhận trả chi phí lưu lượng giữa các vùng khả dụng với lý do chuẩn bị cho trường hợp nhà cung cấp đám mây gặp sự cố
    Nói cách khác, nhà cung cấp đang tính phí khá nhiều cho chi phí nhằm giảm nhẹ vấn đề mà chính họ có thể gặp phải

  • Trong luồng này mọi người đều nói đây không phải vấn đề serverless mà là vấn đề đám mây; điều đó đúng, nhưng điểm cốt lõi vẫn còn. Băng thông gần như là lợi nhuận thuần, và việc tính phí băng thông đắt như vậy trong khi không cung cấp công cụ để khách hàng đối phó với các cuộc tấn công ngoài tầm kiểm soát của họ trông khá bẩn
    Theo luồng này, Netlify thậm chí không có tùy chọn tạm thời gỡ site xuống trong lúc bị tấn công DDoS: https://answers.netlify.com/t/limiting-bandwidth-traffic-to-...
    Netlify có thể có nhiều giải pháp như kiểm soát hóa đơn, giới hạn yêu cầu, giới hạn băng thông, miễn phần vượt mức nếu đúng là DDoS, v.v., nhưng có vẻ họ không quan tâm vì như thế chẳng khác nào giết con ngỗng đẻ trứng vàng. Chỉ cần nhìn các tính năng mà CDN bunny.net cung cấp là thấy sự tương phản: https://support.bunny.net/hc/en-us/articles/360014190440-Und...
    Thật đáng thất vọng khi chúng ta quá dễ dàng chấp nhận điều này, dù khó giải thích hành xử của các nhà cung cấp đám mây bằng điều gì khác ngoài lòng tham

  • Vì sao việc không có giới hạn chi tiêu lại là vấn đề serverless? Đó là vấn đề đám mây
    Tuy nhiên, nếu là một máy chủ đám mây nhỏ thì khi bị tấn công nó có thể sập, và nếu chỉ tính phí lưu lượng đi ra như AWS thì điều đó có lợi cho người dùng

    • Vì serverless thường dùng tính phí theo mức sử dụng nhiều hơn mô hình truyền thống, và cũng mở rộng tốt hơn tới mức sử dụng quy mô lớn
      DDoS chiếc VPS DigitalOcean 5 USD/tháng của tôi thì chi phí tính toán cũng không tăng, và nhiều khả năng nó sẽ không chịu nổi tải mà sập trước khi chi phí truyền tải tích lũy đáng kể. Lưu lượng truyền của DigitalOcean cũng tính theo mức sử dụng, nhưng chắc sẽ chạm giới hạn trước đó
    • Đây không phải vấn đề đám mây. Đám mây rốt cuộc chỉ là máy tính của người khác
      Đây là vấn đề thanh toán hoặc vấn đề kiến trúc. Họ cần cho phép giới hạn yêu cầu để ngăn bị tính phí quá mức, hoặc ngắt khi đạt một số tiền nhất định
    • Đây là thất bại kiến trúc. Việc đặt mức tối đa là rất quan trọng. Nếu chọn một nền tảng không hỗ trợ tính năng đó thì bản thân bạn cũng có trách nhiệm
      Trong môi trường truyền thống, việc đặt cầu dao ngắt mạch thường ngầm dễ hơn, nhưng dù vậy vẫn phải cân nhắc. Cần kiểm thử tải cho cả hai kịch bản thành công và thất bại
    • Lý do việc không có giới hạn chi tiêu là vấn đề serverless là vì khi dùng đám mây thì có thể giảm nhẹ, nhưng trong serverless thì không thể
      Tôi dùng instance đám mây nên không có vấn đề này và sau này cũng sẽ không có. Nếu là serverless thì tôi đã gặp vấn đề này rồi