Earlier quoted context omitted.
Not on DO. ~$100 a month droplet gets you about 5TB of transfer out. They pulled 15TB in 7 hours. That's ~1,440,000 (16 3 30) on overage or about $15k extra.
Doesn't DO charge $0.01/GB for egress overage? That's $150, not $15k. (Although Hetzner or something would've been even less.)
We survived 10k requests/second: Switching to signed asset URLs in an emergency
71–80 of 176 posts
Re: We survived 10k requests/second: Switching to signed asset URLs in an emergency
#72I'm always surprised to read how much money companies are willing to spend on things that can be done for essentially nothing. I had a look at the site - why does this need to run on a major cloud provider at all? Why use VERY expensive cloud storage at 9 cents per gigabyte? Why use very expensive image conversion at $50/month when you can run sharp on a Linux server? I shouldn't be surprised - the world is all in on…
You are missing both development cost and much more importantly opportunity cost
If I spent a person year on a cheap run architecture while my competitor spent a person year on a value add feature add, he will win
Re: We survived 10k requests/second: Switching to signed asset URLs in an emergency
#73We've designed our system for this very use case. Whether it's on commodity hardware or in the cloud, whether or not it's using a CDN and edge servers, there are ways to "nip things in the bud", as it were, by rejecting requests without a proper signed payload. For example, the value of session ID cookies should actually be signed with an HMAC, and checked at the edge by the CDN. Session cookies that represent a auth…
Re: We survived 10k requests/second: Switching to signed asset URLs in an emergency
#74Earlier quoted context omitted.
You cannot just put Cloudflare in front of your Google hosted bucket, that's against CF's terms of service. In order to do that you would have to also host the content itself on Cloudflare R2/Images etc. There used to be also html only restriction but that's no longer the case. > Next, we got rid of the antiquated HTML vs. non-HTML construct, which was far too broad. Finally, we made it clear that customers can serve…
Lots of people do this, so you definitely can do this even if its against CF's terms of service, which is something I can't find evidence of.
If you're putting the CDN in front of a bucket with nothing but images, you're automatically in breach.
https://www.cloudflare.com/service-specific-terms-applicatio...
Re: We survived 10k requests/second: Switching to signed asset URLs in an emergency
#75Earlier quoted context omitted.
Not on DO. ~$100 a month droplet gets you about 5TB of transfer out. They pulled 15TB in 7 hours. That's ~1,440,000 (16 3 30) on overage or about $15k extra.
Didn't pay attention to transfer figure lets switch DO to CCX43 on Hetzner for $50 more
Re: We survived 10k requests/second: Switching to signed asset URLs in an emergency
#76Quick feedback – you've used the term "signed URL" over 50 times in the post without once explaining what it is or how it works.
Rather than allowing any object on a bucket to be downloaded by its raw URL (i.e: http://mycdn.io/abcdefg.jpeg ), the backend service needs to generate a "signed" url, which is a short lived URL that grants the user a single request against that resources (GET, POST, PUT, etc.) (i.e: http://mycdn.io/abcdefg.jpeg?signed={securerandomstring} ) So you can only use the URL to download it once, and you need to go through…
That is, the entire point is to not put more compute between the requester and the data. The absolute worst place to be would be to have compute that is streaming from the data provider, so that they can stream to the end user.
Right?
Re: We survived 10k requests/second: Switching to signed asset URLs in an emergency
#77Quick feedback – you've used the term "signed URL" over 50 times in the post without once explaining what it is or how it works.
Rather than allowing any object on a bucket to be downloaded by its raw URL (i.e: http://mycdn.io/abcdefg.jpeg ), the backend service needs to generate a "signed" url, which is a short lived URL that grants the user a single request against that resources (GET, POST, PUT, etc.) (i.e: http://mycdn.io/abcdefg.jpeg?signed={securerandomstring} ) So you can only use the URL to download it once, and you need to go through…
Re: We survived 10k requests/second: Switching to signed asset URLs in an emergency
#78Edit: I see this is discussed in other threads.
Re: We survived 10k requests/second: Switching to signed asset URLs in an emergency
#79I'm always surprised to read how much money companies are willing to spend on things that can be done for essentially nothing. I had a look at the site - why does this need to run on a major cloud provider at all? Why use VERY expensive cloud storage at 9 cents per gigabyte? Why use very expensive image conversion at $50/month when you can run sharp on a Linux server? I shouldn't be surprised - the world is all in on…
Entering the world where you're dealing with Cogent, your Dell and Fortinet reps, suddenly having strong opinions about iDRAC vs iLO and hardware RAID is well beyond what anyone wants to care about just to run some web servers.
When people talk about major cloud providers being expensive the alternative is never /really/ to do it yourself but move to a discount hosting provider. And it's not as if there isn't savings to be found there but it's just another form of cloud optimization. We're talking about a story where $100 of spend triggers an alert. The difference is so minuscule.
Re: We survived 10k requests/second: Switching to signed asset URLs in an emergency
#80I'm confused, isn't this literally the use case for a CDN? Edit: I see this is discussed in other threads.
Given that we have the problem now, and that people already have the non-CDN URLs, we needed a solution that allowed us to roll out something ASAP, while allowing people that use our API to continue using the image URLs they've downloaded.