Como a AWS S3 processa 1 petabyte por segundo em HDDs lentos

 (bigdata.2minutestreaming.com)
19 pontos por GN⁺ 2025-09-27 | 2 comentários | Compartilhar no WhatsApp
  • O AWS S3 é um serviço de armazenamento de objetos multitenant em grande escala, oferecendo alta disponibilidade e durabilidade a baixo custo
  • Embora use HDDs antigos e lentos (≈120 IOPS), maximiza a economia de uma mídia de armazenamento ultrabarata e de alta capacidade
  • O S3 projetou sua camada interna de armazenamento (ShardStore) com estrutura log-structured (LSM), ajustando o caminho de escrita para I/O sequencial; no caminho de leitura, compensa os problemas de desempenho com Erasure Coding (5-of-9) e paralelismo em larga escala
  • Em todo o caminho entre cliente, front-end e armazenamento, reduz a latência de cauda e soma a vazão com técnicas como multipart upload, byte-range GET, connection pool e hedge requests
  • Com distribuição aleatória, Power of Two Random Choices, rebalancing contínuo e descorrelação — em que a carga se achata conforme a escala cresce — evita hotspots e, como resultado, atinge vazão de >1 PB/s

Arquitetura de armazenamento em larga escala do AWS S3

  • Todo mundo sabe o que é o AWS S3, mas poucos conhecem a escala gigantesca em que ele opera e as inovações necessárias para isso
  • O S3 é um serviço escalável de object storage multitenant que permite armazenar e recuperar objetos via API, oferecendo altíssima disponibilidade e durabilidade a um custo relativamente baixo

  • Escala do S3

    • Mais de 400 trilhões de objetos armazenados
    • 150 milhões de requisições processadas por segundo
    • Mais de 1 PB/s de tráfego nos picos
    • Dezenas de milhões de discos rígidos em operação
  • Apresenta alta disponibilidade e durabilidade (meta de projeto de “11 noves”) com custo relativamente baixo como base da experiência do usuário
    • Também se expandiu para se tornar a camada base de armazenamento de data analytics e data lakes de machine learning
  • O objetivo de projeto é lidar com padrões de acesso aleatório e concorrência em massa mantendo a eficiência de custos
    • O S3 parte do pressuposto de workloads de acesso aleatório coletivos, nos quais cada tenant acessa tamanhos e offsets arbitrários

Tecnologia de base: discos rígidos (HDD)

  • A impressionante escalabilidade e performance do S3 se apoiam em um meio de armazenamento tradicional: o HDD
  • O HDD é uma tecnologia antiga que oferece alta durabilidade, mas tem limitações de IOPS e latência devido ao movimento físico
    • Como dependem necessariamente de movimento mecânico, como rotação por segundo (ex.: 7200 RPM) e seek do atuador, a latência é estruturalmente alta e inevitável
    • Seek médio de meio prato ≈4 ms, meia rotação média ≈4 ms, transferência de 0,5 MB ≈2,5 ms → leitura aleatória média de 0,5 MB ≈11 ms, com vazão aleatória de um único disco em torno de ≈45 MB/s
  • Diferentemente dos SSDs, os HDDs ainda são usados em armazenamento em larga escala porque sua curva de longo prazo de capacidade↑ e preço↓ garante a economia de “ultrabaixo custo/alta capacidade”
    • Preço: queda de 6 bilhões de vezes por byte (ajustado pela inflação)
    • Capacidade: aumento de 7,2 milhões de vezes
    • Tamanho: redução de 5 mil vezes
    • Peso: redução de 1.235 vezes
  • No entanto, os IOPS estão estagnados em cerca de 120 há 30 anos, e o desempenho de acesso aleatório e a latência não melhoraram muito
  • SSDs são melhores em I/O aleatório, mas ficam em desvantagem em termos de TCO no armazenamento em escala de petabytes e exabytes

Caminho de escrita otimizado para I/O sequencial

  • HDDs são otimizados para acesso sequencial; ao ler e gravar bytes contíguos, o prato do disco gira naturalmente e processa dados rapidamente
  • Estruturas de dados baseadas em log (log-structured) tiram proveito dessa característica sequencial
    • O ShardStore, camada interna de armazenamento do S3, adota uma LSM log-structured, usando uma estratégia em que as escritas são tratadas como append sequencial em disco
    • De forma semelhante, o processamento em lote pode maximizar a vazão sequencial do disco

Paralelismo e Erasure Coding para o caminho de leitura aleatória

  • As leituras exigem saltos para posições arbitrárias (aleatórias) conforme a solicitação do usuário, esbarrando diretamente nas limitações físicas (a latência média de I/O aleatório é de cerca de 11 ms)
    • Um único HDD consegue processar no máximo cerca de 45 MB/s em I/O aleatório
    • Por isso, HDDs têm excelente custo-benefício para armazenar grandes volumes de dados, mas desempenho ruim em acesso aleatório
  • Para superar essa limitação física, o S3 adota paralelismo em larga escala, fazendo sharding dos dados em muitos discos e lendo em paralelo para somar a vazão total
    • Os dados são distribuídos por inúmeros HDDs, usando o I/O de cada disco em paralelo para elevar bastante a vazão agregada
    • Por exemplo, se um arquivo de 1 TB for dividido e armazenado em 20 mil HDDs, é possível ler em escala de TB/s somando a vazão de todos eles

Erasure Coding

  • Em sistemas de armazenamento, garantir redundância é indispensável
  • O S3 usa Erasure Coding (EC) para dividir os dados em K fragmentos e M fragmentos de paridade
    • A restauração é possível com quaisquer K fragmentos dentre os K+M totais
  • O S3 usa Erasure Coding (5-of-9) com uma estrutura de 9 partes (5 shards de dados, 4 shards de paridade) para atingir um ponto de equilíbrio
    • 5 dados + 4 paridades = 9 fragmentos
    • Tolera a perda de até 4 shards e permite reconstruir o original com quaisquer 5 fragmentos, oferecendo tolerância a falhas
    • O overhead de armazenamento é de ≈1,8x, mais eficiente em capacidade do que tripla replicação (3x)
    • Ao mesmo tempo, garante 5 caminhos de leitura paralelos, o que favorece a paralelização por shards e a evasão de stragglers
  • Assim, o S3 supera essa limitação física e oferece acesso aleatório a dados em grande escala

Estrutura de processamento paralelo

  • O S3 usa 3 formas principais de paralelização
    • 1. O usuário divide os dados em vários chunks para upload e download
    • 2. O cliente faz requisições simultâneas a vários servidores front-end
    • 3. O servidor distribui os objetos por vários servidores de armazenamento

  • 1. Paralelismo na camada de servidores front-end

    • Usa pools internos de conexões HTTP para se conectar simultaneamente a vários endpoints distribuídos
    • Evita sobrecarga em nós específicos da infraestrutura ou em caches

  • 2. Paralelismo entre discos rígidos

    • Com base em EC, os dados são distribuídos em pequenos shards por vários HDDs

  • 3. Paralelismo em requisições PUT/GET

    • O cliente divide os dados em várias partes para upload paralelo
    • PUT: maximiza o paralelismo de novas gravações com multipart upload
    • GET: suporta byte-range GET (leitura de apenas parte do intervalo dentro do objeto)
  • Com processamento paralelo distribuído, até uploads de 1 GB/s podem ser alcançados sem dificuldade

Prevenção de hotspots

  • O S3 opera em um ambiente com dezenas de milhões de discos, centenas de milhões de requisições por segundo e centenas de milhões de shards em paralelo
  • Se a carga se concentrar em um disco ou nó específico, há risco de degradação de desempenho de todo o sistema
  • Estratégias principais para evitar isso:
    • 1. Distribuição aleatória do local de armazenamento dos dados
    • 2. Rebalancing contínuo
    • 3. Expansão da escala do sistema

  • 1. Shuffle sharding & Power of Two

    • A localização inicial de armazenamento é distribuída aleatoriamente
    • Aplica o algoritmo Power of Two Random Choices:
      • Ao escolher o menos carregado entre dois nós aleatórios, é possível fazer balanceamento de carga com eficiência

  • 2. Rebalancing

    • Temperatura dos dados: aproveita a característica de que dados novos são mais quentes (mais acessados) para redistribuir espaço e I/O com rebalancing periódico
      • Quanto mais antigos os dados, menor a frequência de acesso e maior a folga de I/O no armazenamento como um todo
    • O S3 redistribui dados frios para maximizar o uso de espaço e recursos
    • Ao adicionar novos racks (ex.: 20 PB/rack, 1000×20 TB), é necessária distribuição ativa para ocupar a capacidade vazia

  • 3. Chill@Scale

    • Efeito de escala: quanto mais independentes forem os workloads, menor a concorrência em bursts, gerando descorrelação que achata a carga agregada
    • Quanto maior o sistema, menores as diferenças entre pico e média e melhor a previsibilidade
    • Em outras palavras, mesmo que o uso repita ciclos de pico e ociosidade, em grande escala eles se compensam e mantêm uma carga previsível

Cultura operacional, confiabilidade e outras técnicas

  • Com shuffle sharding no nível de DNS, busca isolamento entre tenants e distribuição uniforme já na camada de resolução de nomes
  • O rollout de software também é feito de forma gradual e sem interrupções, como no EC, e a migração para o ShardStore ocorreu sem impacto no serviço
  • Cultura de durabilidade: confiabilidade baseada em processos como detecção contínua de falhas, chain of custody, modelagem de ameaças à durabilidade e verificação formal

Por que isso importa: tendências de infraestrutura de dados baseadas em S3

  • Com a expansão de arquiteturas stateless, cresce o padrão em que os nós de aplicação eliminam estado e delegam persistência, replicação e balanceamento de carga ao S3
    • Exemplos: Kafka Diskless (KIP-1150), SlateDB, Turbopuffer, Lucene on S3 e integrações de object storage em ClickHouse/OpenSearch/Elastic
  • As vantagens são escala elástica, simplificação operacional e redução de custos; a desvantagem é o possível aumento de latência, exigindo projetar o trade-off entre latência, custo e durabilidade conforme o workload

Resumo

  • O AWS S3 é um serviço de armazenamento multitenant em larga escala que supera os limites de mídias lentas com paralelismo em massa, load balancing e data sharding
  • Garante estabilidade e desempenho com Erasure Coding, distribuição aleatória, rebalancing contínuo e hedge requests
  • No início era focado em backup e mídia, mas evoluiu para se tornar o principal armazenamento de infraestruturas de big data, como analytics e machine learning
  • Arquiteturas baseadas em S3 possibilitam escalabilidade stateless, delegando de forma eficaz à AWS os problemas de durabilidade, replicação e balanceamento de carga
  • Isso também traz redução de custos em nuvem e maior eficiência operacional

Leituras relacionadas

2 comentários

 
shakespeares 2025-10-05

Se a tecnologia não fosse boa, acho que não daria lucro.
 
GN⁺ 2025-09-27
Comentários do Hacker News

  • Há alguns erros factuais, mas eles não afetam muito o fluxo do artigo. Um exemplo é a afirmação de que o S3 usa um esquema de fragmentação 5:9; na prática, o S3 usa vários esquemas de fragmentação e, pelo que eu sei, 5:9 não é um deles. A proporção de 1,8 byte físico para cada 1 byte lógico é realmente ruim do ponto de vista de custo de HDD. Também existem formas de reduzir essa proporção, ampliar o paralelismo e melhorar a disponibilidade. Por exemplo, é preciso considerar quantos shards podem ser perdidos antes que um objeto se torne impossível de obter via GET quando uma AZ inteira cai

    • Entendi neste vídeo, no ponto 42:20, que o S3 usa esse esquema de fragmentação. Se você souber mais, eu gostaria de entender

    • Parece pouco intuitivo reduzir a proporção de 1,8x e ao mesmo tempo aumentar a disponibilidade. Se houver menos réplicas, não aumenta o risco de perda de dados em caso de falha de AZ? Eu entendia que a AWS fornecia réplicas totalmente independentes em 3 AZs. E ainda acho impressionante a explicação de que, para ler um chunk de 16 MB, na prática é mais rápido ler 4 MB de 5 discos rígidos diferentes

    • A VAST data usa um esquema 146+4. (link)

  • Gostei de ler este texto, mas a resposta à pergunta do título é óbvia demais: paralelismo

    • Normalmente eu quase nunca penso em velocidade de I/O de armazenamento nessa escala. No passado usei RAID0 para gravar mais rápido em discos, mas isso faz muito tempo. No começo achei que eles usariam alguma abordagem interessante como cache ou hierarquização. Só depois de ler percebi que paralelismo é a resposta óbvia, mas eu não tinha pensado nos detalhes da implementação do S3 nem na forma como ele faz correção de erros. A palavra-chave é paralelismo, mas os detalhes trouxeram bastante insight. Imagino que o MinIO também tenha uma história parecida de escalabilidade: também é paralelismo

    • Acho que o título do artigo é um pouco confuso porque foca só no throughput de pico do S3 como um todo. A pergunta realmente interessante, na minha opinião, é "como é possível obter throughput de GET acima do throughput máximo de um HDD". Com replicação simples, você pode direcionar GETs em paralelo para vários HDDs e, do ponto de vista do S3 como um todo, o throughput sobe, mas no fim você continua limitado ao throughput de cada HDD multiplicado pelo número de requisições GET. O segredo, e a parte interessante, é que o S3 não tem essa limitação

    • Se você juntar milhões de discos rígidos, acaba com uma largura de banda de I/O gigantesca

    • Parece uma lógica do tipo "a forma de ir à Lua é óbvia: viagem"

  • full-platter seek time: ~8ms; half-platter seek time (avg): ~4ms
    Em média, se dois pontos em [0,1] tiverem distribuição uniforme, o valor esperado da distância entre eles não é 0,5, mas 1/3. Se o tempo de seek de prato completo for 8 ms, então o tempo médio de seek é 2,666 ms

    • Em discos modernos, o seek completo está mais perto de 25 ms do que de 8 ms. Se quiser testar por conta própria, com um HDD e acesso root, dá para usar o fio com a opção --readonly e alternar leituras entre as duas extremidades do disco. Também há um bom artigo explicando por que esse número de 1/3 não é exato em discos modernos (aqui). Se tiver mais curiosidade sobre mecânica ou desempenho de disk drives, posso responder

    • Há aceleração do cabeçote ao se mover entre trilhas. Quanto menor a distância, menor a velocidade máxima atingida, e há também uma latência fixa (tempo de estabilização etc.), então na prática a média pode mesmo ser 4 ms

    • Como o prato é circular, não se deve usar uma distribuição uniforme em [0, 1], mas sim no círculo unitário em [0, 2π]; e como o prato gira apenas em uma direção, a distância deve ser calculada sempre no sentido horário.
      Simplificando o problema: se o ponto de partida é 0 grau e o ponto de destino é aleatório, qual é a distância média? Como 0-180 graus e 180-360 graus têm o mesmo comprimento de arco, a distância média é 180 graus. Ou seja, o half-platter seek é exatamente metade do full-platter seek

  • Dá para estimar se o S3 ainda usa HDD como serviço principal olhando o preço e convertendo para IOPS. O preço das requisições GET/PUT no S3 é alto o bastante para que a AWS possa se dar ao luxo de deixar espaço em disco ocioso para atender tenants de alto desempenho. Mas não muito além disso

  • Fico curioso se alguma parte do S3 roda em SSD. Eu imaginava que o S3 padrão já fosse baseado em SSD e que só as camadas lentas usassem HDD ou sistemas mais lentos

    • O KeyMap Index do S3 usa SSD. Neste momento, eu esperaria que SSDs já estivessem sendo usados para cache de objetos quentes ou como parte de algum produto mais novo one zone

    • Os dados efetivamente armazenados provavelmente ficam quase todos em HDD. Mas imagino que metadados, índices etc. usem armazenamento flash muito mais rápido. Em clusters Ceph menores, os servidores MDS normalmente já funcionam assim, e o S3 está em uma escala muito maior

    • Já mencionei isso acima, mas no tier padrão o preço por requisição é alto o suficiente para que, mesmo com clientes com alta proporção de IOPS/TB, ainda faça sentido em custo deixar parte da capacidade dos discos ociosa. Mas acima disso já não compensa. HDDs modernos armazenam cerca de 30 TB e, embora eu não saiba quanto a AWS realmente paga, estimaria algo entre 300 e 500 dólares por unidade. Isso é muito mais barato do que um SSD de 30 TB. Além disso, esses HDDs podem ser montados em sistemas de alta densidade, como 100 discos em 4U, com apenas cerca de 25% de custo extra no total. Já os gabinetes que suportam SSD em grande quantidade custam muito mais por slot

    • Imagino que o S3 Express One Zone seja baseado em SSD. Mas parece que a Amazon não divulga isso abertamente

    • Eu esperaria com certeza que os metadados ficassem em SSD. Também é possível que objetos quentes, lidos com frequência, sejam armazenados em cache em SSD

  • Acho curioso que, mesmo com a queda contínua do preço dos HDDs, a cobrança do S3 tenha permanecido igual por pelo menos 8 anos. A falta de concorrência em redução de preços mantém uma estrutura tarifária alta. Dá para imaginar quanto lucro isso gera para a AWS

    • A política de preços da AWS é parecida em todos os serviços. Por exemplo, uma instância EC2 m7a.medium custa 50 dólares por mês no on-demand e 35 dólares com reserva de 1 ano. Mesmo comparando com serviços de outras empresas com especificações semelhantes, ela não parece muito competitiva

    • Também há o efeito da inflação, então mesmo que o preço nominal seja o mesmo, em termos reais houve queda. Mas concordo que a inflação é refletida muito mais lentamente do que o ritmo do progresso tecnológico

    • Acho que o objetivo dos incentivos não é reduzir custos. Quando se olha para empresas como Splunk ou CrowdStrike, que armazenam volumes enormes de dados na AWS, há muita informação repetitiva, e elas simplesmente cobram isso dos clientes aplicando apenas uma deduplicação básica. Se o custo cair, isso acaba criando incentivo para ainda mais uso desnecessário

    • Fico em dúvida se a queda no preço dos HDDs ainda é realmente grande. Nos últimos anos, a redução do preço por GB em discos rígidos desacelerou bastante, e a tendência é que os SSDs alcancem isso em breve

  • Como leitura mais interessante sobre o S3, recomendo "Building and operating a pretty big storage system called S3"

  • Fico curioso sobre o desempenho real do rustfs

  • Ao ver a menção de que dezenas de milhões de HDDs são usados, dá para estimar que, se HDDs corporativos tiverem capacidade na faixa de 10 a 20 TB, a capacidade total do AWS S3 esteja na casa de centenas de exabytes. Provavelmente é o maior sistema de armazenamento do planeta

    • Se o hardware tiver sido atualizado desde 2013, um certo datacenter em Utah pode superar essa capacidade (matéria relacionada)

    • Hoje os HDDs corporativos já chegam a 30 TB, e em breve podem alcançar até 50 TB

  • Gostaria de conhecer algum serviço open source otimizado para HDD que entregue desempenho parecido. Os principais projetos (MinIO, Swift, Ceph+RadosGW, SeaweedFS) todos recomendam implantações só com flash. Ultimamente estou olhando o projeto Garage, mas ele é bem diferente no desenho, por exemplo por não usar EC

    • Ceph+RadosGW também funciona bem o suficiente com HDD. Só que o pool de índices precisa usar SSD, e é preciso ter uma noção realista dos números de IOPS que se pode esperar de pools em HDD. Do lado do cliente, os IOPS reais acabam sendo multiplicados várias vezes, e o S3 resolve isso com um número enorme de HDDs. Para armazenamento massivo em streaming de 4 MB isso não é um grande problema, mas se houver muitas leituras e escritas aleatórias de chaves pequenas, ou muito acesso distribuído sobre uma mesma chave, o desempenho do backend passa a importar bastante

    • Lustre/ZFS também pode alcançar velocidades semelhantes. Mas, se for necessário alto IOPS, no Lustre é preciso flash para o MDS e, no ZFS, SSDs dedicados para log

    • Todos esses serviços também precisam de muitos discos em escala de grande datacenter para atingir o mesmo desempenho. Pouquíssimas implantações conseguem operar nessa escala. Por isso o flash é mais eficiente, em espaço e custo, para acesso rápido

    • O SeaweedFS evoluiu bastante nos últimos anos, com suporte a RDMA e também adoção de EC

    • Em um emprego anterior, operamos armazenamento de objetos baseado em SwiftStack, com os metadados em SSD e os dados dos objetos em HDDs comuns. Funcionava bem o bastante