WIwillglynn·Aug 8, 2018
> With S3, every upload call must start by hitting the same URL that is then redirected.
Well… hold on. The docs say that S3 _can_ redirect PUTs and clients need to handle it correctly. This means a service could redirect every single incoming PUT and be S3-compatible. For example, this is how Internet Archive's S3ish service works:
https://archive.org/help/abouts3.txt
In practice, S3 doesn't seem to redirect very much at all, and I've never actually seen it redirect small objects. My speculation is that S3's frontend service is responsible for erasure coding and replicating inbound PUTs. Remember that S3's default storage class needs to send bits to multiple machines in multiple datacenters; it makes sense to me that this happens while you're uploading, instead of waiting for the upload to finish and then having the single point of failu
Read the rest
re replicate back out.
S3's API gives the frontend service the _option_ to redirect each incoming PUT, but it almost always dispatches uploads to the internal storage systems with a single PUT from the client.
> But it saves Backblaze money to not have such high loads and high uptime demand on the original URL.
The endpoint that handles `b2_get_upload_url` still needs to be highly available and serve lots of requests. Its load isn't 1:1 for each uploaded object and its failure wouldn't immediately stop all uploads, but… it still has to work.
> The "need" was to save money. See example above. Amazon S3 would require 3 redirects from the original URL, while Backblaze B2 chose a different tradeoff that is zero redirects and 4 total requests where 3 out of 4 requests were NOT redirected. The 3 out of 4 requests go to the final location DIRECTLY.
How much does this help? A search of GitHub shows that many users are calling `b2_get_upload_url` and then uploading a single file, a use case for which B2 requires twice as many HTTP requests as a typical (non-redirecting) S3 PUT:
https://github.com/UKn0Me/b2-api/blob/master/examples/b2_upl...
https://github.com/volnt/e2e-upload/blob/master/project/uplo...
https://github.com/djoon/webboard/blob/master/src/com/webboa...
https://github.com/jaeming/benjidalton.com-rails/blob/master...
> But either way, it is the tradeoff we chose.
Sure, that's fine, but I think this is disingenuous:
> And it’s a big deal that B2 is free of the “load balancer problem.” It solves for a huge scaling issue. When we roll out new vaults in new data centers in new countries, the clients are contacting those vaults DIRECTLY (over whatever network path is shortest) and so there are fewer choke points in our architecture.
When you connect to s3.amazonaws.com, you're talking to the S3 frontend service in the us-standard region. This is the service that knows how to list your buckets (by talking to the internal index services), knows how to encode and distribute your incoming objects (by talking to the internal storage services), knows how to request/repair/decrypt/assemble your outgoing objects, etc. It's not in the way, it's not a "choke point", it is the _only_ part of S3 that performs these frontend functions.
When S3 adds a new region, that region gets a new endpoint: s3.us-east-2.amazonaws.com, s3.us-west-1.amazonaws.com, s3.eu-west-1.amazonaws.com, etc. all perform the same functions for their respective geographical areas.
And if you request something from the wrong region:
$ curl -s https://s3.us-west-1.amazonaws.com/elevation-tiles-prod | tidy -q -xml
<?xml version="1.0" encoding="utf-8"?>
<Error>
<Code>PermanentRedirect</Code>
<Message>The bucket you are attempting to access must be addressed
using the specified endpoint. Please send all future requests to
this endpoint.</Message>
<Bucket>elevation-tiles-prod</Bucket>
<Endpoint>s3.amazonaws.com</Endpoint>
<RequestId>D18584530CD6A9E1</RequestId>
<HostId>
N7Oa6U6FouXBvz40Wa920r+D2qj5nWUZ8nxP14L+HhqfbEX5jeR+Yo80boODWqVxUFVeCeZVBqw=</HostId>
</Error>
…you're told which regional endpoint you should use instead.