Great to see Amazon employees being allowed to talk openly about how S3 works behind the scenes. I would love to hear more about how Glacier works. As far as I know, they have never revealed what the underlying storage medium is, leading to a lot of wild speculation (tape? offline HDDs? custom HDDs?).
Building and operating a pretty big storage system called S3
21–30 of 169 posts
Re: Building and operating a pretty big storage system called S3
#22> What’s interesting here, when you look at the highest-level block diagram of S3’s technical design, is the fact that AWS tends to ship its org chart. This is a phrase that’s often used in a pretty disparaging way, but in this case it’s absolutely fascinating. I’d go even further: at this scale, it is essential and required to develop these kind of projects with any sort of velocity. Large organizations ship their c…
Re: Building and operating a pretty big storage system called S3
#23> Now, let’s go back to that first hard drive, the IBM RAMAC from 1956. Here are some specs on that thing: > Storage Capacity: 3.75 MB > Cost: ~$9,200/terabyte Those specs can't possibly be correct. If you multiply the cost by the storage, the cost of the drive works out to 3¢. This site[1] states, > It stored about 2,000 bits of data per square inch and had a purchase price of about $10,000 per megabyte So perhaps t…
Must've put a decimal point in the wrong place or something. I always do that. I always mess up some mundane detail.
Re: Building and operating a pretty big storage system called S3
#24Re: Building and operating a pretty big storage system called S3
#25> That’s a bit error rate of 1 in 10^15 requests. In the real world, we see that blade of grass get missed pretty frequently – and it’s actually something we need to account for in S3. One of the things I remember from my time at AWS was conversations about how 1 in a billion events end up being a daily occurrence when you're operating at S3 scale. Things that you'd normally mark off as so wildly improbable it's not…
Also worked at Amazon, saw some issues with major well known open source libraries that broke in places nobody would ever expect.
Re: Building and operating a pretty big storage system called S3
#26Examples:
iDrive has E2, Digital Ocean has Object Storage, Cloudflare has R2, Vultr has Object Storage, Backblaze has B2
Re: Building and operating a pretty big storage system called S3
#27> That’s a bit error rate of 1 in 10^15 requests. In the real world, we see that blade of grass get missed pretty frequently – and it’s actually something we need to account for in S3. One of the things I remember from my time at AWS was conversations about how 1 in a billion events end up being a daily occurrence when you're operating at S3 scale. Things that you'd normally mark off as so wildly improbable it's not…
I think Ceph hit similar problems and they had to add more robust checksumming to the system, as relying on just tcp checksums for integrity for example was no longer enough
Re: Building and operating a pretty big storage system called S3
#28Great to see Amazon employees being allowed to talk openly about how S3 works behind the scenes. I would love to hear more about how Glacier works. As far as I know, they have never revealed what the underlying storage medium is, leading to a lot of wild speculation (tape? offline HDDs? custom HDDs?).
Never officially stated, but frequent leaks from insiders confirm that Glacier is based on Very Large Arrays of Wax Phonograph Records (VLAWPR) technology.
One of the tag line ideas we had was "8 out of 10 customers say they prefer the feel of their data after it is restored"
Re: Building and operating a pretty big storage system called S3
#29Great to see Amazon employees being allowed to talk openly about how S3 works behind the scenes. I would love to hear more about how Glacier works. As far as I know, they have never revealed what the underlying storage medium is, leading to a lot of wild speculation (tape? offline HDDs? custom HDDs?).
Re: Building and operating a pretty big storage system called S3
#30> That’s a bit error rate of 1 in 10^15 requests. In the real world, we see that blade of grass get missed pretty frequently – and it’s actually something we need to account for in S3. One of the things I remember from my time at AWS was conversations about how 1 in a billion events end up being a daily occurrence when you're operating at S3 scale. Things that you'd normally mark off as so wildly improbable it's not…
Daily? A component I worked on that supported S3’s Index could hit a 1 in a billion issue multiple times a minute. Thankfully we had good algorithms and hardware that is a lot more reliable these days!