A construção e a operação de um enorme sistema de armazenamento chamado S3
(allthingsdistributed.com)- O Amazon S3 começou como um armazenamento de objetos baseado em API HTTP REST, lançado em 14 de março de 2006, e cresceu até se tornar um serviço de grande escala operado em conjunto por centenas de microsserviços e várias equipes dedicadas
- A escala do S3 não pode ser explicada apenas pelo código; trata-se de um sistema em constante mudança, no qual discos rígidos, firmware, data centers, organização operacional e cargas de trabalho dos clientes continuam interagindo entre si
- Os HDDs melhoraram muito em capacidade e eficiência de custo, mas o desempenho de acesso aleatório continua limitado por restrições mecânicas, então o S3 trata o gerenciamento de calor de I/O e a colocação de dados em milhões de discos como problemas centrais
- A replicação e a codificação de apagamento baseada em Reed-Solomon não apenas aumentam a durabilidade, mas também ajudam a contornar discos sobrecarregados, contribuindo para o desempenho e para o controle da tail latency
- A operação do S3 é projetada para manter desenvolvimento rápido e altos padrões de durabilidade ao mesmo tempo, com revisões de durabilidade, o ShardStore baseado em Rust, verificação formal leve e ownership em nível de equipe
Ver o S3 como um único e enorme sistema de serviço
- O S3 é um serviço de armazenamento de objetos composto por API HTTP REST, frota de front-end, serviço de namespace, frota de armazenamento baseada em discos rígidos e frota de tarefas em segundo plano
- Cada grande componente tem sua própria área dentro da organização do S3, com liderança e várias equipes; os componentes internos também operam com suas próprias frotas e equipes
- Hoje, o S3 é composto por centenas de microsserviços, e a interação entre equipes se aproxima de contratos no nível de API
- Se a modularidade for mal projetada, a interação entre equipes também pode se tornar ineficiente e estranha, e corrigir isso também faz parte do processo de projetar software e equipes em conjunto
O sistema não é o software, mas o serviço inteiro
- Os clientes do S3 não compram software empacotado, mas uma experiência de serviço, esperando qualidade contínua e previsível
- Os limites do sistema do S3 não ficam apenas no código
- código executado perto dos discos
- técnicos que instalam novos racks de armazenamento no data center
- aplicações dos clientes ajustadas para desempenho
- as organizações de hardware, finanças e engenharia
- O S3 está mais próximo de um sistema vivo, em que software, hardware e pessoas crescem e mudam continuamente juntos
- Um simples diagrama de arquitetura em quadro branco esconde a escala e os serviços expandidos dentro de cada caixa, levando a uma subestimação do sistema real
Como os limites físicos dos HDDs afetam o design do S3
- O S3 é um sistema muito grande que usa milhões de discos rígidos, e as características dos HDDs são uma das restrições centrais do design
- Desde a IBM 350 disk storage unit de 1956, os HDDs evoluíram muito
- o maior HDD mencionado atualmente é o Western Digital Ultrastar DC HC670 de 26 TB
- desde o RAMAC, a capacidade melhorou 7,2 milhões de vezes
- o tamanho físico ficou 5.000 vezes menor
- o custo por byte, ajustado pela inflação, ficou 6 bilhões de vezes mais barato
- Mas o seek time melhorou apenas 150 vezes, e o desempenho de leitura e escrita aleatória continua em torno de 120 operações por segundo
- Esse número de desempenho já era parecido quando o S3 foi lançado em 2006, e não era muito diferente nem mesmo 10 anos antes disso
- Como o HDD é um dispositivo mecânico, é preciso esperar o movimento do braço e a rotação do prato, então o desempenho de acesso aleatório não melhora na mesma velocidade do aumento de capacidade
- O roadmap da indústria aponta para uma trajetória rumo a HDDs de 200 TB na próxima década, e nesse nível, assumindo acesso aleatório uniforme a todos os dados, isso equivale a permitir apenas 1 I/O por segundo para cada 2 TB de dados no disco
- O S3 ainda não usa unidades de 200 TB, mas espera-se que use tanto essas unidades quanto todos os tamanhos intermediários até lá
Gerenciamento de calor: colocação de dados e desempenho
- No S3, heat significa o número de requisições que chegam a um disco específico em um determinado momento
- Se o gerenciamento de calor for mal feito, as requisições se concentram em certos discos e criam um hotspot, piorando o desempenho geral das requisições que dependem desses discos
- Em vez de derrubar o sistema imediatamente, um hotspot cria filas de requisições e degrada a experiência do cliente
- requisições que aguardam discos ocupados ficam atrasadas
- a latência se amplifica nas camadas superiores da pilha de armazenamento por meio de I/Os dependentes, como consultas de metadados ou codificação de apagamento
- surgem altas latências em parte das requisições, ou seja, stragglers
- hotspots em HDDs individuais levam à tail latency e, se ignorados, acabam afetando a latência geral das requisições
- No S3, no momento em que os dados são gravados, não se sabe quando nem como eles serão acessados no futuro, o que torna difícil decidir a colocação dos dados no momento da escrita
- Em pequena escala, prever e gerenciar o heat de I/O é muito difícil, mas na escala e no ambiente multi-tenant do S3 surgem outras características
- Cargas de trabalho individuais costumam ficar ociosas na maior parte do tempo e, de repente, atingir picos, mas quando milhões de cargas de trabalho são agregadas, a demanda total se torna mais uniforme e previsível
- Depois de certo tamanho, torna-se difícil ou impossível que uma única carga de trabalho individual afete o pico geral
Replicação e codificação de apagamento tratam durabilidade e desempenho ao mesmo tempo
- O método de redundância de um sistema de armazenamento não apenas protege os dados contra falhas de hardware, mas também ajuda na distribuição de calor
- A replicação mantém cópias em vários discos para suportar falhas de disco e permite atender leituras a partir de qualquer uma dessas cópias
- Do ponto de vista de capacidade, a replicação é cara, mas do ponto de vista de I/O de leitura, ela é eficiente
- Para não pagar o overhead da replicação para todos os dados, o S3 também usa codificação de apagamento
- Um método de exemplo usa algoritmos como Reed-Solomon
- o objeto é dividido em k shards de identidade
- são gerados adicionalmente m parity shards
- o objeto pode ser lido se qualquer conjunto de k shards entre os k+m totais estiver disponível
- Essa abordagem reduz o overhead de capacidade enquanto tolera o mesmo número de falhas
Estratégia de colocação de dados e isolamento de cargas de trabalho dos clientes
- O método de redundância divide os dados em mais fragmentos do que o número necessário de leituras, permitindo enviar requisições evitando discos sobrecarregados
- O S3 também distribui novos objetos amplamente por toda a frota de discos para reduzir ainda mais o calor
- Um objeto individual pode ser codificado em dezenas de unidades, e objetos diferentes são colocados em conjuntos diferentes de discos
- Espalhar os objetos de cada bucket por muitos discos traz dois benefícios
- a fração dos dados de um cliente em um único disco se torna muito pequena, dificultando que uma carga de trabalho individual crie um hotspot em um disco específico
- uma carga de trabalho individual pode fazer burst até uma escala de discos que seria difícil e cara de construir como sistema independente
- Um burst de um cliente de análise genômica executando análises paralelas em milhares de funções Lambda pode ser atendido por mais de 1 milhão de discos individuais
- Hoje, há dezenas de milhares de clientes no S3 com buckets distribuídos por milhões de discos
- O diferencial do S3 não está apenas na escala do próprio sistema de armazenamento, mas no fato de que a escala agregada de clientes e cargas de trabalho pode mudar até a natureza do sistema
Revisões de durabilidade e guardrails
- A Amazon valoriza permitir que engenheiros e equipes falhem rápido e com segurança
- Para avançar rapidamente enquanto fornece armazenamento de alta durabilidade, o S3 usa um processo de durability review
- O durability review não é um mecanismo que entra no modelo estatístico de 11 noves, mas é tratado como algo importante na operação do S3
- Se uma mudança de engenharia puder afetar o estado de durabilidade, é feito um durability review
- O processo toma emprestada a ideia de threat model da pesquisa em segurança
- escreve-se um resumo da mudança
- cria-se uma lista abrangente de ameaças
- documenta-se como a mudança resiste a essas ameaças
- O durability review cumpre dois papéis
- faz com que autor e revisores pensem criticamente sobre os riscos que precisam ser protegidos
- permite discutir separadamente os riscos e as contramedidas
- Ao buscar contramedidas, prefere-se guardrails simples e robustos que bloqueiem classes amplas de risco, em vez de anexar mitigações individuais a cada risco específico
ShardStore, Rust e verificação formal leve
- Alguns anos atrás, o S3 iniciou um projeto para reescrever do zero a camada mais baixa da pilha de armazenamento, isto é, a parte que gerencia os dados em discos individuais
- O nome dessa nova camada de armazenamento é ShardStore
- Um dos guardrails adotados na reconstrução do ShardStore foi a verificação formal leve
- A equipe migrou a linguagem de implementação para Rust para encontrar bugs mais cedo
- aproveitando a segurança de tipos
- aproveitando o suporte estruturado da linguagem
- escrevendo bibliotecas que estendem a segurança de tipos também às estruturas on-disk
- No lado da verificação, foi escrito em Rust um modelo simplificado da lógica do ShardStore e colocado no mesmo repositório da implementação real de produção
- Esse modelo funciona como uma especificação executável, removendo a complexidade da camada real de armazenamento on-disk e dos HDDs
- O tamanho do modelo era cerca de 1% do sistema real, mas permitia um nível de teste irrealista contra discos rígidos de 120 IOPS
- Esse trabalho também foi publicado no artigo da SOSP Using lightweight formal methods to validate a key-value storage node in Amazon S3
- Depois disso, foram usadas ferramentas e técnicas já existentes, como property-based testing, para verificar se o comportamento da implementação correspondia à especificação
- O ponto central é que técnicas de pesquisa em verificação formal foram industrializadas em código que engenheiros comuns conseguem manter e em ferramentas aplicadas a cada commit
- Os guardrails de verificação deram à equipe confiança para desenvolver mais rápido e continuaram sendo mantidos mesmo após a entrada de novos engenheiros
Ownership para lidar com os problemas de escala de equipes e indivíduos
- Na Amazon, ownership é o conceito de deixar claro qual indivíduo ou equipe é responsável até o fim pelo sucesso de uma determinada tarefa ou serviço
- Para manter altos padrões de qualidade enquanto se move rapidamente no S3, as equipes precisam ser donas do que constroem
- elas são donas dos contratos de API com outros sistemas
- respondem por durabilidade, desempenho e disponibilidade
- corrigem problemas até às 3 da manhã se um bug inesperado afetar a disponibilidade
- depois de corrigir um bug, melhoram o sistema para que o mesmo problema não volte a ocorrer
- Ownership exige confiança junto com grande responsabilidade
- Para que uma pessoa ou equipe seja dona de um serviço, ela precisa ter espaço para decidir diretamente como entregá-lo
- Mesmo na experiência de projetos de pesquisa de pós-graduação, quando o estudante sente que a ideia é sua e pode desenvolvê-la diretamente, ele tende a se comprometer mais profundamente
- Em papéis de engenharia muito seniores, costuma ser mais eficaz definir bem o problema e ajudar a equipe a ter ownership da solução, em vez de simplesmente apresentar uma solução pronta para implantação
- Em problemas com várias soluções possíveis, fazer com que alguém escolha a solução adequada é uma forma de dar a essa pessoa ownership da solução
Conclusões extraídas do S3
- A escala técnica do S3 não é apenas uma versão maior de sistemas pequenos; as cargas de trabalho, a estrutura e o modo de operação são fundamentalmente diferentes
- O “sistema” inclui não só o software, mas também a operação do serviço, a organização operacional e até o código dos clientes que funciona junto com esse serviço
- Como a organização também faz parte do sistema, ela própria tem problemas de escala e oportunidades de inovação
- Para ter sucesso em um papel individual, é preciso expressar com clareza os problemas, mais do que as soluções, e apoiar equipes de engenharia fortes para que elas realmente tenham ownership das soluções
2 comentários
Opiniões do Hacker News
Uma das conversas de que me lembro de quando estava na AWS era que até um evento de uma em um bilhão acontece todos os dias na escala do S3
Coisas que normalmente seriam tão improváveis que não valeriam a pena se preocupar precisam necessariamente ser consideradas e tratadas
É bom ver abordagens como o ShardStore, especialmente verificação formal e testes baseados em propriedades. As gerações anteriores de serviços tinham muitos bugs, a ponto de mostrar bem os riscos do crescimento orgânico, mas pelo menos foram projetadas para falhar de forma “segura”, evitando perda de dados, e os engenheiros do S3 eram obcecados por isso
E isso não é só no S3. Por exemplo, no Prime Day 2022, o DynamoDB chegou a mais de 105 milhões de requisições por segundo apenas com workloads da Amazon: https://aws.amazon.com/blogs/aws/amazon-prime-day-2022-aws-f...
No texto, Andy também aborda técnicas formais leves e a adoção de Rust pela equipe; em uma escala em que até eventos de probabilidade extremamente baixa se tornam comuns, é preciso investir em várias camadas de ferramentas e processos para garantir correção
Expliquei que, ao chegar à meta de 500k TPS, isso seria 30 vezes por minuto, e perguntei: “você quer ficar de on-call naquela semana?”. Nessa stack, “insistir nos mais altos padrões” ganha um significado completamente diferente da maioria das organizações
Felizmente o algoritmo era bom, e o hardware hoje em dia também é muito mais confiável
Também há uma voz meio cínica na minha cabeça pronta para pegar a pipoca se eu tiver a sorte de ver as consequências da primeira grande colisão de hash criptográfico
Trabalhando com genômica, lidei com muitos repositórios de dados em escala de petabytes nos últimos 10 anos
Depois de usar AWS S3, GCP GCS e sistemas de armazenamento para hardware em colocation (Ceph, Gluster e um sistema da HP cujo nome apaguei da memória), passei a ter grande respeito pelo esforço necessário para operar sistemas assim
Também é difícil subestimar o benefício de compartilhar I/O de disco com inúmeros outros clientes. Foi a primeira vez que vi o termo “heat” usado como no texto, mas em um sistema único é realmente difícil mitigar isso. No nosso cluster em colocation, para gerenciar I/O adequadamente entre jobs grandes, tivemos de modificar o sistema de batch para tratar I/O como um recurso alocável, assim como RAM ou CPU. S3 e GCP são muito caros, mas às vezes o desempenho justifica o preço
Para mim, textos como esse são o melhor lado do HN
Do ponto de vista do armazenamento em nuvem, o melhor cliente é aquele que armazena uma quantidade enorme de dados, mas quase nunca os lê. É parecido com alugar discos rígidos, mas, se você preencher apenas parte de cada disco com dados “frios”, pode continuar usando toda a capacidade de I/O do mesmo disco para processar workloads quentes
Se você equilibrar com muito cuidado quais dados ficam em quais drives, consegue manter todos os drives em uso mesmo que a maior parte dos dados não seja acessada. Por isso, armazenar é relativamente barato e ler é relativamente caro
Mesmo quando dão suporte a S3, o desempenho costuma ser muito mais lento do que poderia ser
É difícil, e peço desculpas pelo fato de a disponibilidade de leitura ficar em torno de apenas 99,95%
Se o S3 tivesse especificado um protocolo simples baseado em OAuth2 para delegação de acesso de leitura/gravação, muita coisa poderia ter sido criada
O mundo precisa de um protocolo baseado em HTTP que permita a apps acessar dados em nome do usuário. O Google Drive é o que chega mais perto disso, mas há apenas um provedor e também outros problemas[0]. É uma pena que o remoteStorage não tenha vingado. Espero que o Solid dê certo, mas para mim ele parece complicado demais. Minha abordagem para esse problema é https://gemdrive.io/, mas no momento está praticamente parada porque estou focado em outras partes da stack de self-hosting
[0]: https://gdrivemusic.com/help
Fazer isso direito hoje é extremamente difícil. Criei uma aplicação CLI inteira para resolver o problema de “emitir credenciais da AWS que tenham acesso apenas a este bucket específico”, mas não quero orientar usuários a instalar e executar algo assim: https://s3-credentials.readthedocs.io/en/stable/
Na prática, seria bom ter uma biblioteca com dependências mínimas no lado do cliente que montasse um diretório local que, na verdade, fosse o bucket S3 do usuário
Porque um concorrente poderia entrar a qualquer momento com interoperabilidade adversarial
É uma pena que todos os projetos que tentaram criar, ou estão criando, soberania de dados do usuário tenham acabado indo para aquele lado estranho de criptomoedas
https://docs.aws.amazon.com/cognito/latest/developerguide/co...
Edit: acho que li o comentário errado. Entendi que o app queria delegar os dados do usuário ao cliente, mas na verdade parece que o usuário quer delegar seus dados ao app. São casos de uso diferentes
Nas especificações do IBM RAMAC aparece capacidade de armazenamento de 3,75 MB e cerca de US$ 9.200 por terabyte, mas isso não pode estar certo
Se multiplicar o custo pela capacidade, o preço do drive dá 3 centavos
Este site[1] diz que ele “armazenava cerca de 2.000 bits por polegada quadrada e o preço de compra era de aproximadamente US$ 10.000 por megabyte”
Então provavelmente a especificação deveria ser US$ 9.200 por megabyte. Aí o preço do drive fica em US$ 34.500, o que parece mais plausível
[1]: https://www.historyofinformation.com/detail.php?entryid=952
Eram 30 milhões de bits, usando apenas 6 bits de dados e excluindo paridade. Mas, como era alugado por US$ 3.000 por mês, não havia um custo fixo equivalente a comprar o drive físico à vista. Nesse aspecto, ele até se parece bastante com o modelo do S3
O que a maioria não percebe é que a mágica não está em lidar com o sistema em si, mas em fazer a autorização parecer sem custo
Autorização em sistemas distribuídos é extremamente difícil. Na escala da AWS, é praticamente magia. A AWS tem um modelo de permissões rico, e mudanças de permissão se propagam por toda a infraestrutura em velocidade submilissegundo, mesmo enquanto provavelmente processa trilhões de requisições
Essa parte, junto com logging/acerto de contas para cobrança, são os dois elementos mágicos da AWS sobre os quais eu gostaria de ler em detalhe
O S3 lida com controle de acesso de forma diferente de outros serviços: as permissões ficam vinculadas ao recurso. Imagino que seja por questão de velocidade
Uma das razões pelas quais o modelo de acesso bucket/chave é especial é que ele já estava estabelecido quando o IAM apareceu
O fato de ter sido mantido depois provavelmente se deve a que remover o modelo antigo quebraria muitas configurações de clientes, o que seria uma tarefa difícil
“Como um engenheiro realmente sênior na empresa, é claro que tenho opiniões fortes e uma pauta técnica. Mas, ao interagir com engenheiros, se eu simplesmente tento distribuir ideias, fica difícil todo mundo ter sucesso. É muito mais difícil se engajar em uma ideia que você não possui. Por isso, ao trabalhar com equipes, adotei a estratégia de fazer com que minhas melhores ideias se tornem ideias de outras pessoas, não minhas. Conscientemente, passo muito mais tempo desenvolvendo o problema e expressando-o muito bem do que vendendo uma solução. Muitas vezes há várias maneiras de resolver um problema, e escolher a forma certa é fazer com que alguém assuma a propriedade da solução.”
“Aprendi que, para ter real sucesso no meu papel, preciso me concentrar em articular claramente o problema, não a solução, e encontrar formas de apoiar uma equipe de engenharia forte para que ela realmente assuma a propriedade dessa solução.”
Gostei muito dessa parte. De certa forma, lembra o efeito Ikea. Para fazer alguém se entusiasmar com o que está fazendo, é preciso incentivar o senso de propriedade, e uma boa maneira é fazer com que aquilo se torne “a ideia da pessoa”.
Afinal, muitas vezes as pessoas já divergem sobre o que é o “problema”.
Felizmente, nem todos os problemas são assim. Mas, por exemplo, quando se olha para a discussão sobre o “problema de empacotamento” do Python, na prática há algo como seis problemas diferentes que as pessoas descrevem de maneiras muito distintas, e esse fenômeno aparece de forma bastante ruim.
Andy Warfield, se estiver lendo — e provavelmente está —, tenho uma pergunta. Ao desenvolver um problema, qual é o valor de esboçar possíveis soluções? Quando você articula o problema com clareza, algumas soluções possíveis surgem naturalmente; vale a pena compartilhá-las para iniciar o raciocínio dos potenciais donos? Ou é melhor focar apenas no problema e deixar o espaço de soluções completamente aberto?
Além disso, há algum material recomendado para ler mais sobre a forma de atuação desse tipo de contribuidor individual muito sênior?
Para mim soa como: “Seu plebeu! Não tenho tempo para me preocupar com seus problemas. Se você trouxer só o problema, eu não consigo ser promovido às custas do seu trabalho.”
Para conseguir resolver um problema, primeiro é preciso entendê-lo e reconhecer que ele existe.
Em situações sem autoridade ou expertise previamente reconhecidas — ou seja, o contexto em que a maioria dos problemas cotidianos aparece —, se você ocupa sozinho um canal de conversa bidirecional com uma explicação longa, detalhada e cuidadosamente organizada do problema, é fácil parecer alguém que só quer falar e não trabalhar, ou alguém que não quer encontrar uma solução junto com os outros.
É bom ver que funcionários da Amazon agora podem falar publicamente sobre o funcionamento interno do S3.
Também gostaria de ouvir mais sobre como o Glacier funciona. Pelo que sei, nunca divulgaram qual é o meio de armazenamento subjacente, então houve todo tipo de especulação: fita, HDDs offline, HDDs customizados etc.
Mas há quem discorde. Ainda é uma incógnita.
Seria ótimo se a AWS contasse tudo sobre isso e toda a jornada. É um assunto realmente fascinante.
Bastaria um engenheiro bêbado sair falando demais. Em áreas muito mais críticas, um militar de Massachusetts vazou informações de segurança nacional no Discord para parecer legal aos amigos gamers, e agora enfrenta uma longa pena de prisão. Eu achava que os detalhes do Glacier já teriam aparecido a esta altura.
“Imagine a cabeça de um disco rígido como um 747 voando a 75 milhas por hora sobre um gramado. O espaço de ar entre a parte de baixo do avião e a ponta da grama tem a espessura de duas folhas de papel. Se medirmos os bits do disco em folhas de grama, a largura da trilha é de 4,6 folhas de grama, e o comprimento de um bit é de uma folha de grama. Enquanto o avião voa sobre a grama contando as folhas, ele erra apenas uma folha a cada 25 mil voltas ao redor da Terra.”
A parte sobre balanceamento de carga me lembrou a época do KeyMap do S3 e quando tentávamos migrar para ele a partir da implementação inicial.
A lição foi que, mesmo depois de identificar o objeto/partição/bucket mais quente, não dava para simplesmente movê-lo e pronto. Era preciso ordenar tudo. A solução real foi ordenar e então dividir a carga das partições dos hosts em quartis, movendo as partições do segundo quartil para os hosts com menor carga.
Quando tentávamos mover o bucket mais quente, ou seja, o primeiro quartil, a carga recaía ainda mais sobre os membros restantes e continuávamos falhando.
Outro efeito colateral foi que a taxa de erros passou de cerca de 1% estável para dias sem erros, e, como resultado, atualizamos os critérios de alerta para serem muito mais rigorosos. Isso foi por volta de 2009.
Eu também tinha formação acadêmica na UM, mas entrei no S3 em vez de fazer doutorado. Até rima.
O S3 é mais do que armazenamento; é um padrão.
Gosto do fato de que dá para usar armazenamento compatível com S3 em vários lugares, geralmente com algumas ressalvas. Não sei quão aberto é o padrão, nem se é preciso pagar à Amazon para dizer “S3 compatible”, mas é bem legal.
Exemplos incluem E2 da iDrive, Digital Ocean Object Storage, Cloudflare R2, Vultr Object Storage e Backblaze B2.
Edit: pesquisando, parece que o Azure realmente não tem :-/
Comentários do Hacker News
Trabalhando na área de genômica, lidei com muitos armazenamentos de dados na escala de petabytes ao longo dos últimos 10 anos.
As coisas que poderíamos construir se o S3 pudesse usar um protocolo baseado em OAuth2 para delegar acesso de leitura/gravação.
Lidar com autenticação em sistemas distribuídos é muito difícil.
É bom ver funcionários da Amazon falando publicamente sobre o funcionamento interno do S3.
A parte que explica a cabeça do disco rígido comparando-a a um avião 747.
Voltando aos tempos do S3 KeyMap, aprendemos que, mesmo após identificar os objetos/partições/buckets mais quentes, não dava para simplesmente movê-los e resolver o problema.
S3 não é apenas armazenamento, é um padrão.