Kisah-Kisah Horor Teknologi Serverless

 (serverlesshorrors.com)
2 poin oleh GN⁺ 2024-03-01 | 1 komentar | Bagikan ke WhatsApp
  • Ini adalah situs yang mengumpulkan contoh nyata risiko biaya membengkak yang tersembunyi di balik kemudahan penagihan berbasis penggunaan
  • Dapat membandingkan tagihan tak terduga yang terjadi di Cloudflare, Vercel, AWS, Firebase, Netlify, BigQuery, dan lainnya berdasarkan layanan serta penyebabnya
  • Proyek kecil atau layanan pribadi pun bisa seketika berujung pada tagihan besar, seperti tagihan harian $36,000 di Cloudflare, $46,485.99 di Vercel, dan $100,000 di Firebase
  • Penyebab yang berulang meliputi bandwidth, DDoS/DoS, storage, implementasi yang salah, rekursi, loop antrean, serta lonjakan penggunaan terkait event, gambar, dokumentasi, dan AI
  • Saat menggunakan layanan serverless dan pay-as-you-go, batas penagihan, cache, pola request, dan loop otomatisasi perlu diperiksa sebelum maupun sesudah deployment

Karakter situs dan cara melapor

  • ServerlessHorrors adalah blog sederhana tempat membaca kumpulan kasus penagihan dan gangguan yang terjadi saat menggunakan serverless
  • Pembuatnya adalah Andras, yang mengerjakan Coolify, Jean, berbagai proyek open source lain, serta pekerjaan terkait coolLabs
  • Laporan kasus diterima melalui dua jalur

Kasus utama yang berujung pada tagihan besar

  • $36,000: Proyek sampingan RetainDB menerima tagihan Cloudflare $36k saat jumlah penggunanya 81 orang
    • Penyebabnya adalah 16B Durable Object writes, runaway queue loop, Durable Object writes yang tidak di-batch, dan KV list scan yang dijalankan pada setiap request
    • Tag: cloudflare, workers, durable-objects, kv, queues
  • $46,485.99: Jmail melampaui 450M pageviews, dan meski banyak mitigasi cache dilakukan, tagihan Vercel tetap meningkat menjadi $46k
    • Tag: vercel, bandwidth
  • $100,000.420: Sebuah situs unggah game WebGL yang cukup populer terkena DoS sehingga tagihan Firebase dalam sehari menjadi $100k
    • Tag: google, storage, firebase
  • $120,000.420: Kasus ketika Cloudflare mencoba menuntut pembayaran $120k dalam 24 jam, lalu menurunkan situs webnya
    • Tag: cloudflare, bandwidth
  • $104,500.123: Kasus menerima email tagihan tunggakan $104,500.00 dari Netlify
    • Tag: netlify, bandwidth, ddos
  • $96,280.69: Kasus tagihan besar terkait bandwidth Vercel
    • Tag: vercel, bandwidth, new
  • $72,000.999: Kasus hampir bangkrut setelah membakar $72K lewat pengujian Firebase + Cloud Run
    • Tag: google, firebase, cloudrun, wrong-implementation, recursion
  • $70,000.69: Proyek yang biasanya membayar $50 per bulan suatu hari menerima tagihan $70,000
    • Tag: google, storage, firebase, gcs

Kasus tambahan yang dicantumkan berdasarkan layanan

  • $23,000.420: EchoFox menerima spam sehingga tagihan Vercel melonjak menjadi $23k dan muncul 56k+ accounts and trials
    • Tag: vercel, bandwidth, ddos
  • $22.639,69: Hanya menggunakan dataset publik di BigQuery playground, tetapi menerima tagihan 22k USD
    • Tag: google, bigquery, sql
  • $11,000.69: Email senilai $11k terkirim selama serangan DoS dan database hilang
    • Tag: ddos, mailgun
  • $4,241.69: Kasus ketika layanan sempat dihentikan sementara, tetapi AWS memblokirnya dan biaya tetap harus dibayar
    • Tag: aws
  • $3,000.69: Kasus yang memperingatkan agar berhati-hati saat menguji atau melakukan deployment di Vercel
    • Tag: vercel, bandwidth, wrong-implementation
  • $1,300.69: Biaya muncul setelah membuat AWS S3 bucket yang kosong dan privat di region yang diinginkan
    • Tag: aws, s3, security, ddos
  • $1273.69: Biaya PostHog muncul setelah meminta Devin AI mengubah codebase
    • Tag: posthog, devin, ai, cognition-labs, new
  • ~$1189.420/month: Webflow menagih $1189.420 dalam satu bulan pada paket $69/month
    • Tag: webflow, bandwidth, image
  • $738.420: Meski berlangganan Vercel Pro seharga $20 per bulan dan menambahkan $120 spending limit, tagihan tetap muncul
    • Tag: vercel, bandwidth, vercels-mistake, spending-limit
  • $620.123: Kasus Vercel ketika sitemap.txt menggunakan ratusan GB/hours
    • Tag: vercel, bandwidth
  • $530.19: Kasus PostHog yang tiba-tiba menagih $530 setelah sebelumnya tidak pernah ada biaya
    • Tag: posthog, events, new
  • $400.69: Cloudflare Images menagih $400 per bulan, bukan perkiraan $110, dengan penagihan prabayar yang membingungkan dan ketiadaan dukungan selama lebih dari 8 bulan
    • Tag: cloudflare, images, billing
  • $383.69: Kasus Mintlify yang menerima tagihan hampir $400 untuk situs dokumentasi
    • Tag: mintlify, ai, documentation
  • $250/month: Untuk 9,000 page visits, biaya menjadi $250 per bulan atau $3,000 per tahun
    • Tag: framer, bandwidth, images and videos
  • $103.26: Kasus AWS ketika $103 menjadi kisah horor dalam situasi penggunaan free tier
    • Tag: aws, dark-pattern, free-tier

Bacaan terkait

1 komentar

 
GN⁺ 2024-03-01
Komentar Hacker News

  • Sungguh disayangkan, dan rasanya malah seperti mundur ke belakang. File 3,44 MB seharusnya tidak menjadi masalah, dan kalaupun jadi masalah, jawabannya tidak seharusnya “unggah saja di tempat lain”
    Kalau ada satu pelajaran dari sini, itu adalah tidak ada yang gratis, dan kerugian sebesar ini seharusnya bisa dicegah dengan menetapkan batas dalam bentuk apa pun. VPS sangat murah dan mudah dikelola, serta punya batas otomatis: https://lowendbox.com/blog/1-vps-1-usd-vps-per-month/

    • Orang-orang bertanya-tanya mengapa sekarang hanya tersisa beberapa situs web dan long tail menghilang; itu karena kalau mengunggah audio 3,44 MB ke Facebook atau Twitter, Anda sama sekali tidak perlu khawatir akan ditagih
    • Mengatakan VPS “mudah dikelola” adalah pilihan yang cukup kuat dengan banyak asumsi di baliknya

  • Saya tidak melihat kasus Netlify ini terjadi karena arsitektur serverless. Serverless memang punya banyak masalah teknis, tetapi masalah menerima tagihan besar akibat trafik masuk itu terpisah dari serverless
    Bahkan jika Anda menaruh perangkat sendiri di colocation dan membayar biaya trafik, hal yang sama bisa terjadi jika pusat data tidak menahan DDoS dan menagih per TB. Tentu saja tarif per TB di colocation jauh lebih murah daripada Netlify, jadi kecil kemungkinan muncul tagihan 100 ribu dolar, tetapi kalau begitu inti masalahnya bukan “horor serverless”, melainkan biaya trafik yang kelewat mahal dan tidak adanya mitigasi DDoS

    • Jika layanan diskalakan tanpa batas, laju terbakarnya uang juga ikut diskalakan tanpa batas. Satu server di colocation, begitu jenuh, kerusakan yang bisa ditimbulkannya pada dompet juga terbatas

  • Andres, pembuat blog ini, juga membuat coolify, alternatif self-hosting untuk Heroku/Netlify. Setelah memakainya selama beberapa bulan, rasanya seperti bumbu rahasia yang memudahkan self-hosting hal-hal seperti changedetector, jdownloader, dan vaultwarden
    Komunitasnya juga tumbuh cukup baik; orang-orang menyumbang template baru dan saling membantu debugging. Saya juga mencoba menambahkan template Syncthing. Namun ketika disk di instance dengan ruang penyimpanan 10 GB penuh, berbagai hal mulai runtuh, jadi bagian ini akan bagus jika punya peringatan atau pencegahan yang lebih baik. Selain itu, cukup stabil
    https://github.com/coollabsio/coolify

  • Mungkin ini reaksi berlebihan, tetapi saya memutuskan memindahkan situs pribadi saya dari Netlify. Saya tidak butuh lebih dari sekadar tempat menaruh HTML, dan saya pikir Netlify “sudah cukup baik”, tetapi saya tidak tahu ada masalah seperti ini
    Situs yang baru-baru ini terkena dampak mirip dengan situs saya dalam hal jumlah pengunjung harian, tingkat pengenalan, dan sifat niche-nya, jadi terasa lebih nyata. Saya lebih suka membangun HTML secara lokal lalu mengunggahnya ke suatu tempat, jadi migrasinya sendiri cukup sebatas pembaruan DNS. Yang aneh adalah sebagian besar pilihan populer seperti Netlify, Vercel, dan Cloudflare sebenarnya tidak menyediakan batas pengeluaran. Itu terlihat seperti fitur yang sangat mendasar

    • Cloudflare Pages punya bandwidth gratis tanpa batas, jadi trafiknya gratis dan karena itu tidak perlu batas
    • Saya bekerja di Vercel, dan Vercel punya perlindungan DDoS serta batas pengeluaran. Kami sedang mengerjakan peningkatan tambahan untuk keduanya yang akan segera diumumkan
      https://vercel.com/blog/introducing-spend-management-realtime...
    • Cloudflare punya perlindungan DDoS, dan bisa dikonfigurasi sampai tingkat yang nyaris paranoid. Saat DDoS mulai terjadi, Anda bisa membuat CAPTCHA muncul untuk semua orang, sehingga pengeluaran bisa dibatasi dengan cukup efektif

  • Thread komentar Netlify yang ditautkan di salah satu posting Reddit juga layak dibaca: https://answers.netlify.com/t/limit-bandwidth-to-avoid-high-...
    Perwakilan Netlify secara eksplisit mengatakan bahwa meskipun di tier gratis, jika terkena DDoS mereka tidak akan melakukan apa pun untuk mencegah tagihan bandwidth yang tidak masuk akal

    • Hal yang paling tidak saya sukai dari layanan seperti ini adalah tidak adanya fitur yang setara dengan stop-loss. Kalau memasang notifikasi, mereka memang memberi tahu, tetapi hanya itu saja, dan dalam banyak kasus notifikasinya baru datang lama setelah kerusakan terjadi
      Untuk sebagian metrik penagihan, laporan atau notifikasi kadang terlambat berjam-jam. Default-nya seharusnya aman, dan menaikkan batas seharusnya mudah dilakukan
    • Dulu server akan dijatuhkan begitu saja, tetapi sekarang strukturnya menjadi situs web serverless terkena DDoS lalu menerima tagihan 100 ribu dolar
      Saya tidak tahu apakah model bisnis seperti ini berkelanjutan. Di masa ketika kita memiliki server sendiri, kita bisa mencabut colokannya, tetapi sekarang tidak ada cara untuk tahu siapa yang akan memanggil /api sejuta kali per menit
    • Tidak bisakah memakai tier gratis dengan nama palsu lalu membuang tagihan yang tidak masuk akal itu? Saya penasaran bagaimana mereka memverifikasi pelanggan
    • Saya curiga ini terjadi karena Netlify sedang mengalami kesulitan pendanaan. Netlify dulu adalah layanan yang sangat bagus dan unik, tetapi sekarang GitHub, GitLab, dan Cloudflare Pages menawarkan layanan yang hampir sama dengan harga lebih murah
    • Kalau hal seperti ini terjadi di tier gratis, apa yang harus dilakukan? Apakah cukup tidak membayar tagihannya dan pergi? Apakah mereka benar-benar akan mengirim penagih utang?

  • Penyedia cloud menagih secara berlebihan untuk item yang memang berhak mereka tagihkan rasanya mirip seperti mekanik mobil yang, saat pemeriksaan routine, menemukan satu komponen kecil rusak, lalu karena alasan yang sama komponen penggantinya juga terus rusak, sehingga ia menggantinya berulang tanpa henti selama 2 minggu tanpa memberi informasi apa pun, dan akhirnya ketika saya datang ke garasi untuk menyuruhnya berhenti, ia menagih biaya 999.999.999 komponen rusak
    Sebagai pengguna kecil, bukan organisasi besar, kami tidak bisa membaca semua dokumentasi pengaturan sampai ke setiap sudutnya. Kami ingin batas tetap: ketika batas pengeluaran yang ditentukan tercapai, matikan semuanya, dan bila perlu data pun boleh hilang. Namun kalau pengguna berhati-hati dengan anggaran, itu merugikan pendapatan, dan dalam beberapa kasus tagihan juga sulit dihitung di muka, jadi sepertinya mereka tidak menyediakan itu

    • Ada perbedaannya. Dalam contoh tadi, mekaniknya sendiri yang menciptakan situasi itu, sedangkan Netlify tidak; bisa juga sulit membedakan traffic yang tidak diinginkan dengan SaaS yang sukses dalam semalam
      Analogi yang lebih tepat adalah seseorang yang mengetahui nomor pelat meminta mekanik melakukan apa pun yang diminta, lalu mekanik menjalankannya begitu saja

  • Baru-baru ini saya membuat kunci OpenAI API, dan secara default mereka memaksakan kuota serta menonaktifkan kunci ketika batas tercapai. Saat pengguna siap menangani lebih banyak request, pengguna menaikkan kuotanya secara manual
    Mengejutkan bahwa lebih banyak perusahaan tidak menjadikan ini sebagai default untuk mencegah tagihan kejutan seperti ini. Kalau dipikir-pikir, mungkin karena pada akhirnya pengguna sering kali tetap membayar

    • Bedanya, OpenAI benar-benar mengeluarkan biaya inferensi, jadi mereka punya kepentingan yang dipertaruhkan. Saat Netlify mengenakan biaya 1000x untuk bandwidth, biaya penyediaan layanannya hampir tidak ada, jadi meski pengguna tidak membayar mereka mungkin tidak terlalu peduli secara nyata

  • Horor cloud terbesar mungkin bukan serverless, melainkan fakta bahwa kita menerima harus membayar biaya traffic antar-Availability Zone dengan alasan bersiap menghadapi kegagalan penyedia cloud
    Dengan kata lain, penyedia mengenakan biaya yang cukup besar untuk memitigasi masalah yang bisa mereka alami sendiri

  • Di thread ini semua orang bilang ini bukan masalah serverless melainkan masalah cloud, dan itu benar, tetapi poin utamanya tetap ada. Bandwidth hampir sepenuhnya margin bersih, dan mengenakan biaya semahal ini untuk bandwidth sambil tidak menyediakan alat untuk merespons serangan di luar kendali pelanggan terlihat cukup kotor
    Menurut thread ini, Netlify bahkan tidak punya opsi untuk menurunkan situs sementara saat serangan DDoS: https://answers.netlify.com/t/limiting-bandwidth-traffic-to-...
    Netlify bisa punya berbagai solusi seperti kontrol penagihan, rate limiting, batas bandwidth, atau membebaskan kelebihan pemakaian bila itu benar-benar DDoS, tetapi mereka tampaknya tidak tertarik karena itu seperti membunuh angsa bertelur emas. Bandingkan saja dengan fitur yang disediakan CDN bunny.net: https://support.bunny.net/hc/en-us/articles/360014190440-Und...
    Mengecewakan bahwa kita terlalu mudah menerima penjelasan penyedia cloud, padahal sulit dijelaskan selain sebagai keserakahan

  • Mengapa tidak adanya batas pengeluaran menjadi masalah serverless? Itu adalah masalah cloud
    Namun jika itu server cloud kecil, saat diserang ia bisa saja tumbang, dan jika seperti AWS hanya traffic keluar yang ditagih, itu menguntungkan pengguna

    • Serverless lebih sering memakai penagihan berbasis penggunaan dibanding model tradisional, dan bisa diskalakan dengan lebih baik sampai penggunaan berskala besar
      Jika VPS DigitalOcean saya yang 5 dolar per bulan terkena DDoS, biaya komputasi tidak akan naik, dan kemungkinan besar ia tidak sanggup menahan beban lalu tumbang sebelum biaya transfer menumpuk besar. Transfer DigitalOcean juga berbasis penggunaan, tetapi akan mencapai batas sebelum itu
    • Ini bukan masalah cloud. Cloud pada akhirnya hanyalah komputer milik orang lain
      Ini adalah masalah penagihan atau masalah arsitektur. Mereka harus memungkinkan pembatasan request untuk mencegah overbilling, atau memutus layanan ketika jumlah tertentu tercapai
    • Ini adalah kegagalan arsitektur. Menetapkan maksimum itu penting. Jika memilih platform yang tidak mendukung fitur seperti itu, pengguna juga punya tanggung jawab
      Di lingkungan tradisional, memasang circuit breaker secara implisit lebih mudah, tetapi tetap harus dipertimbangkan. Harus dilakukan load test untuk kedua sisi: sukses maupun gagal
    • Alasan tidak adanya batas pengeluaran menjadi masalah serverless adalah karena saat memakai cloud hal itu bisa dimitigasi, tetapi di serverless tidak bisa
      Dengan instance cloud yang saya pakai, saya tidak mengalami masalah ini dan tidak akan mengalaminya. Kalau serverless, saya akan mengalami masalah ini