2 ポイント 投稿者 GN⁺ 2024-03-01 | 1件のコメント | WhatsAppで共有
  • 従量課金の便利さの裏に潜むコスト暴走リスクを、実際の事例ごとにまとめて見せるサイト
  • Cloudflare、Vercel、AWS、Firebase、Netlify、BigQuery などで発生した予想外の請求を、サービス別・原因別に比較できる
  • $36,000 Cloudflare、$46,485.99 Vercel、1日あたり $100,000 の Firebase 請求のように、小さなプロジェクトや個人サービスでも一瞬で高額請求につながりうる
  • 繰り返し現れる原因は、帯域幅、DDoS/DoS、ストレージ、誤った実装、再帰、キューループ、イベント・画像・ドキュメント化・AI 関連の使用量増加
  • サーバーレスや従量制サービスを使うときは、課金上限、キャッシュ、リクエストパターン、自動化ループをデプロイ前後に確認する必要がある

サイトの性格と投稿方法

  • ServerlessHorrors は、サーバーレス利用中に発生した課金・障害系の事例を集めて読めるシンプルなブログ
  • 作者は Andras で、Coolify、Jean など複数のオープンソースプロジェクトや coolLabs 関連の作業をしている
  • 事例の投稿は 2 つの経路で受け付けている

高額請求につながった代表的な事例

  • $36,000: RetainDB のサイドプロジェクトが、ユーザー 81 人の状態で Cloudflare から $36k の請求を受けた
    • 原因は、16B Durable Object writes、runaway queue loop、バッチ化されていない Durable Object writes、各リクエストごとに実行された KV list scan
    • タグ: cloudflare, workers, durable-objects, kv, queues
  • $46,485.99: Jmail が 450M pageviews を超え、多くのキャッシュ緩和を行った後でも Vercel の請求額が $46k まで増えた
    • タグ: vercel, bandwidth
  • $100,000.420: ある程度人気のある WebGL ゲームアップロードサイトが DoS を受け、1 日の Firebase 請求額が $100k になった
    • タグ: google, storage, firebase
  • $120,000.420: Cloudflare が 24 時間以内に $120k を支払うよう求めた後、Web サイトを停止させようとした事例
    • タグ: cloudflare, bandwidth
  • $104,500.123: Netlify から $104,500.00 の延滞請求メールを受け取った事例
    • タグ: netlify, bandwidth, ddos
  • $96,280.69: Vercel の bandwidth 関連で高額請求になった事例
    • タグ: 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: Vercel でテストやデプロイを行う際は注意すべきだという事例
    • タグ: vercel, bandwidth, wrong-implementation
  • $1,300.69: 希望するリージョンに空で非公開の AWS S3 bucket を作ったあと、費用が発生した
    • タグ: aws, s3, security, ddos
  • $1273.69: Devin AI にコードベースの変更を依頼したあと、PostHog の費用が発生した
    • タグ: posthog, devin, ai, cognition-labs, new
  • ~$1189.420/month: $69/month プランなのに、単月で Webflow が $1189.420 を請求した
    • タグ: webflow, bandwidth, image
  • $738.420: Vercel Pro を月 $20 で契約し、$120 の spending limit も追加していたのに請求が発生した
    • タグ: vercel, bandwidth, vercels-mistake, spending-limit
  • $620.123: sitemap.txt が数百 GB/hours を消費した Vercel の事例
    • タグ: vercel, bandwidth
  • $530.19: これまで費用を払ったことがなかったのに、突然 $530 を請求された PostHog の事例
    • タグ: posthog, events, new
  • $400.69: Cloudflare Images が予想の $110 ではなく月 $400 を請求し、わかりにくい前払い課金と 8 か月以上のサポート不在も含まれていた
    • タグ: cloudflare, images, billing
  • $383.69: ドキュメントサイトでほぼ $400 を請求された Mintlify の事例
    • タグ: mintlify, ai, documentation
  • $250/month: 9,000 page visits に対して月 $250、年 $3,000 の費用が必要になった
    • タグ: framer, bandwidth, images and videos
  • $103.26: free tier 利用中でも $103 が恐怖事例になった AWS の事例
    • タグ: 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/

    • なぜ今ではウェブサイトが数えるほどしか残っておらず、ロングテールが消えたのか不思議がる人がいるが、それは Facebook や Twitter では 3.44MB の音声をアップロードしても課金を心配する必要がまったくないからだ
    • VPSが「管理しやすい」というのは、いくつもの前提を置いたかなり強い主張だ
  • Netlifyの事例はサーバーレスアーキテクチャのせいで起きたとは思わない。サーバーレスには技術的な問題が多いが、流入トラフィックのせいで高額請求を受ける問題はサーバーレスとは独立している。
    自分の機材をコロケーションに置いてトラフィック費用を払っていたとしても、データセンターがDDoSを防いでくれず、TB単位で請求されれば同じことは起こり得る。もちろんコロケーションはTBあたりの単価がNetlifyよりずっと安いので、10万ドルの請求書になる可能性は低いが、だとすれば焦点は「サーバーレスの恐怖」ではなく、法外に高いトラフィック料金とDDoS緩和の欠如であるべきだ

    • サービスが無限にスケールするなら、金が燃える速度も無限にスケールする。コロケーションの単一サーバーは飽和すれば、財布への被害も限定される
  • このブログを作ったAndresは、Heroku/Netlifyのセルフホスト代替であるcoolifyも作っている。数か月使ってみたが、changedetector、jdownloader、vaultwardenのようなものをセルフホストしやすくしてくれる秘密のソースのような存在だった。
    コミュニティもかなりうまく成長していて、人々が新しいテンプレートを提供し合い、互いにデバッグを手伝っている。Syncthingのテンプレートも追加してみた。ただ、10GBストレージのインスタンスでディスクがいっぱいになるといろいろ壊れ始めたので、この点は通知や予防策がもっと良くなるとありがたい。それ以外はかなり安定している。
    https://github.com/coollabsio/coolify

  • 過剰反応かもしれないが、個人サイトをNetlifyから移すことにした。HTMLを置いておく場所以上のものは必要なく、Netlifyは「十分に良い」と思っていたが、こういう問題があるとは知らなかった。
    最近被害を受けたサイトが、1日の訪問者数や知名度、ニッチさといった点で自分のサイトと似ていたので、より現実味を感じた。HTMLはローカルでビルドしてどこかにアップロードする形が好みなので、移行自体はDNSの更新程度で済む。奇妙だったのは、Netlify、Vercel、Cloudflareのような人気の選択肢の多くが、実際には支出上限を提供していないことだ。あまりにも基本的な機能に思える

    • Cloudflare Pagesは無料帯域幅が無制限なので、トラフィックは無料であり、そのため上限は不要だ
    • Vercelで働いているが、VercelにはDDoS防御と支出上限がある。どちらについても、まもなくさらなる改善を公開できるよう作業中だ。
      https://vercel.com/blog/introducing-spend-management-realtime...
    • CloudflareにはDDoS防御があり、ほとんど被害妄想的と言えるほど細かく設定できる。DDoSが始まったら全員にCAPTCHAを表示させることもでき、支出の抑制にかなり効果的だ
  • Redditの投稿の1つでリンクされていたNetlifyのコメントスレッドも一見の価値がある: https://answers.netlify.com/t/limit-bandwidth-to-avoid-high-...
    Netlifyの担当者が、無料ティアであってもDDoSを受けた場合、ばかげた帯域幅請求を防ぐためには何もしないと明言している

    • こうしたサービスでいちばん気に入らないのは、損切りに相当する機能がないことだ。通知を設定すれば知らせてはくれるが、それだけで、多くの場合は被害が出てからかなり時間がたってようやく通知が来る。
      一部の課金指標はレポートや通知が何時間も遅れることもある。デフォルトは安全であるべきで、上限引き上げは簡単にできるべきだ
    • 昔はサーバーを落とせばよかったのに、今ではサーバーレスなウェブサイトがDDoSを受けて10万ドルの請求書を受け取る構図になっている。
      こういうビジネスモデルが持続可能なのか分からない。サーバーを所有していた時代にはプラグを抜けたが、今では誰かが/apiを毎分100万回呼び出すのを防ぐ術がない
    • 無料ティアを偽名で使って、法外な請求書を捨てることはできないのだろうか? どうやって顧客確認をしているのか気になる
    • Netlifyは資金繰りに困っていて、だからこういうことが起きているのではないかと思う。以前のNetlifyはとても良くてユニークなサービスだったが、今ではGitHub、GitLab、Cloudflare Pagesがほぼ同じサービスをもっと安く提供している
    • 無料ティアでこういうことが起きたらどうすればいいのだろう? そのまま請求書を払わずに去ればいいのか? 本当に取り立てに来るのだろうか?
  • クラウド事業者が請求権のある項目を過剰請求するのは、車の整備士が routine 点検中に小さな部品が壊れ、同じ理由で交換品も壊れ続けたため無限ループで交換し続け、2週間何の情報もよこさず、最終的に自分がガレージに行って止めろと言ったら壊れた部品 999,999,999個分の費用 を請求してくるようなものだと感じる
    大規模組織ではない小さな利用者としては、隅々までの調整用ドキュメントを全部読むことはできない。決めた支出上限に達したら全体を止め、必要ならデータを失ってもよい固定上限を望む。だが、利用者が予算に慎重になると売上に悪影響があり、請求額を事前計算しにくい場合もあるので、そうしてくれないのだと思う

    • 違いはある。例の整備士は状況を自分で作り出したが、Netlify はそうではなく、望まないトラフィックと一夜にして成功した SaaS を見分けるのは難しいかもしれない
      より正確なたとえは、ナンバープレートを知っている人が何を依頼しても整備士に全部やってくれと伝え、整備士がそのまま実行したケースに近い
  • 最近 OpenAI API キーを作ったが、デフォルトで クォータ を強制し、上限に達するとキーを無効化する。さらに多くのリクエストを処理する準備ができたら、利用者が手動でクォータを引き上げる方式だ
    こうした不意打ちの請求書を防ぐために、もっと多くの会社がデフォルトでこうしていないのは驚きだ。考えてみれば、結局は利用者がそのまま払うことが多いからなのかもしれない

    • 違いとして、OpenAI は推論コストが実際にかかるため利害関係がある。Netlify が帯域幅に 1000 倍課金するときは、サービス提供コストがほとんどないので、利用者が払わなくても実際にはそれほど気にしないかもしれない
  • 最大のクラウド恐怖はサーバーレスではないかもしれず、クラウド事業者が失敗した場合に備えるという理由で アベイラビリティゾーン間トラフィック料金 を私たちが受け入れていることだと思う
    つまり、事業者側に起こりうる問題を緩和するための費用を、事業者がかなり高く請求しているということだ

  • このスレッドでは皆、これはサーバーレスの問題ではなくクラウドの問題だと言っているが、それは正しいとしても核心はなお残る。帯域幅はほぼ純利益 であり、帯域幅にここまで高額課金しながら、顧客の制御外にある攻撃に対処するツールを提供しないのはかなり不誠実に見える
    このスレッドによれば Netlify には、DDoS 攻撃中にサイトを一時停止する選択肢すらない: https://answers.netlify.com/t/limiting-bandwidth-traffic-to-...
    Netlify には請求制御、リクエスト制限、帯域幅上限、本物の DDoS なら超過分免除など、さまざまな解決策があり得るが、金の卵を産むガチョウを殺すことになるので関心がないように見える。bunny.net CDN が提供する機能を見るだけでも比較になる: https://support.bunny.net/hc/en-us/articles/360014190440-Und...
    クラウド事業者の説明は、強欲以外では説明しにくいのに、私たちがあまりに簡単に受け入れているのは残念だ

  • 支出上限がないことがなぜサーバーレスの問題なのか? それは クラウドの問題
    ただし、小規模なクラウドサーバーなら攻撃を受ければ落ちる可能性があり、AWS のように外向きトラフィックだけ課金するなら、それは利用者に有利だ

    • サーバーレスは従来モデルより 従量課金 を使うことが多く、大規模な利用量までよりよくスケールするからだ
      月 5 ドルの自分の DigitalOcean VPS が DDoS されても、コンピュート費用は増えず、転送費用が大きく積み上がる前に負荷に耐えられず落ちる可能性が高い。DigitalOcean の転送量も従量課金だが、その前に限界に達するはずだ
    • これはクラウドの問題ではない。クラウドは結局、他人のコンピュータにすぎない
      これは 請求の問題 かアーキテクチャの問題だ。過剰請求を防ぐためにリクエストを制限できるようにするか、一定額に達したら遮断すべきだ
    • これは アーキテクチャの失敗 だ。最大値を設定するのは重要だ。そうした機能をサポートしないプラットフォームを選ぶなら、それは本人の責任でもある
      従来環境ではサーキットブレーカーを置くのが暗黙的にやりやすいが、それでも必ず考慮すべきだ。成功時と失敗時の両方について負荷テストをしなければならない
    • 支出上限がないことがサーバーレスの問題である理由は、クラウドなら緩和できるがサーバーレスでは緩和できないからだ
      クラウドインスタンスを使っている自分にはこの問題はなく、今後もないだろう。サーバーレスだったらこの問題を経験していただろう