Construção e operação de um sistema de armazenamento bem grande chamado S3

Construção e operação do S3

• S3 é a sigla de Amazon Simple Storage Service e se refere a um sistema de armazenamento em larga escala.
• Andy Warfield trabalhou no S3 e passou a ter uma compreensão ampla do sistema.
• O S3 é um serviço que abrange diversas áreas, da experiência de desempenho do cliente até a mecânica dos discos rígidos.

Há 17 anos, em um campus universitário distante...

• O S3 foi lançado em 14 de março de 2006 e completa seu 17º aniversário este ano.
• Warfield concluiu seu doutorado na Universidade de Cambridge, participou do projeto Xen e depois fundou a startup XenSource.
• A XenSource cresceu e foi adquirida pela Citrix, e Warfield aprendeu muito sobre crescimento de negócios e gestão de equipes.

Como o S3 funciona

• Depois de entrar na Amazon, Warfield aprendeu como o S3 funciona com Seth Markle, um dos primeiros engenheiros do S3.
• O S3 é um serviço de object storage com API HTTP REST, composto por frontend, serviço de namespace, uma frota de armazenamento com discos rígidos e uma frota que executa tarefas em segundo plano.
• O S3 é composto por centenas de microsserviços, e a interação entre as equipes acontece por meio de contratos no nível de API.

Observações iniciais

• O S3, mais do que software, é um ecossistema em evolução contínua que inclui hardware e pessoas.
• A escala do S3 faz com que cada componente seja composto por um conjunto de serviços com scale-out, então leva tempo para entender a dimensão do sistema.

Escala técnica: a física do armazenamento

• O S3 é um sistema muito grande que usa milhões de discos rígidos.
• Os hard drives reúnem maravilhas de tecnologia e inovação e têm excelente eficiência de custo.

Gestão de calor: posicionamento dos dados e desempenho

• No S3, são feitas otimizações para resolver o problema de "gestão de calor", distribuindo de forma equilibrada as requisições de I/O por muitos discos rígidos.

Replicação: posicionamento dos dados e durabilidade

• O S3 usa esquemas de redundância, como replicação e erasure coding, para garantir a durabilidade dos dados e gerenciar o calor.

O impacto da escala: estratégia de posicionamento dos dados

• Ao distribuir os dados o mais amplamente possível entre muitos discos, os dados de cada cliente passam a ocupar uma quantidade muito pequena em cada disco, alcançando isolamento de workload.

O fator humano

• A complexidade do S3 se deve não apenas a fatores técnicos, mas também ao fator humano.
• A Amazon incentiva engenheiros e equipes a falharem rápido e com segurança, mantendo o foco em fornecer armazenamento com alta durabilidade.

Expandindo a mim mesmo: resolvendo problemas difíceis que começam e terminam com 'ownership'

• Warfield vivenciou na Amazon uma expansão de escala pessoal, aprendendo sobre a escala de software, pessoas e negócios.
• Na Amazon, há forte ênfase em 'ownership', o que ajuda a entender a estrutura organizacional e a abordagem de engenharia.

Opinião do GN⁺

• O S3 vai além de um simples serviço de armazenamento: é um ecossistema complexo que combina hardware, software e fatores humanos.
• Este texto oferece insights para engenheiros de software iniciantes que querem entender a escala e a complexidade do S3.
• A cultura de 'ownership' da Amazon é um fator importante que motiva equipes e indivíduos a buscar inovação com maior senso de responsabilidade.

[GN⁺]

Comentários do Hacker News

• Uma taxa de erro de 1 em 10^15 solicitações é algo que acontece com frequência no mundo real e é algo a ser considerado no S3.

  • Quando trabalhei na AWS, lembro que, na escala do S3, eventos de uma em um bilhão aconteciam diariamente, e até eventos com probabilidade baixa o bastante para normalmente não se preocupar precisavam ser considerados e tratados.
  • Fico feliz em ler sobre o ShardStore, especialmente impressionado com verificação formal, testes baseados em propriedades etc. A geração anterior de serviços era notoriamente cheia de bugs, mas pelo menos foi bem projetada, graças aos engenheiros do S3 obcecados em falhar com segurança para evitar perda de dados.

• Trabalhando na área de genômica, lidei com muitos armazenamentos de dados na escala de petabytes ao longo dos últimos 10 anos.

  • Tendo usado vários sistemas de armazenamento, como AWS S3, GCP GCS, Ceph, Gluster e sistemas da HP, valorizo muito o esforço necessário para operar esses sistemas.
  • O benefício de compartilhar IOPS de disco com inúmeros outros clientes é enorme, e mitigar isso em um sistema único é muito difícil.
  • No caso de clusters de hardware co-localizados, tivemos que personalizar o sistema de agendamento para tratar IO em trabalhos grandes como um recurso alocável, como RAM ou CPU.
  • S3 e GCP são caros, mas seu desempenho vale o preço.

• As coisas que poderíamos construir se o S3 pudesse usar um protocolo baseado em OAuth2 para delegar acesso de leitura/gravação.

  • Precisamos de um protocolo baseado em HTTP no qual apps possam acessar dados em nome dos usuários.
  • O Google Drive é o mais próximo disso, mas há o problema de fornecedor único, e é uma pena que o remoteStorage não tenha se popularizado.
  • Espero que o Solid tenha sucesso, mas parece complexo.
  • Minha própria solução para o problema é o gemdrive.io, mas no momento estou focado em outras partes da pilha self-hosted.

• Explicação sobre as especificações do disco rígido IBM RAMAC de 1956.

  • A especificação de capacidade de armazenamento de 3.75 MB e custo de cerca de US$ 9.200 por terabyte pode não estar correta.
  • Outros sites sugerem um preço de compra de cerca de US$ 10.000 por megabyte, então a especificação deveria ser US$ 9.200 por megabyte.

• Lidar com autenticação em sistemas distribuídos é muito difícil.

  • Na escala da AWS, autenticação parece mágica, e a AWS tem um modelo de permissões rico, em que mudanças de autenticação se propagam pela infraestrutura em velocidades abaixo de milissegundos.
  • O S3, ao contrário de outros serviços, tem as permissões no recurso, possivelmente por questão de velocidade.

• Como um engenheiro muito experiente com uma agenda técnica, passo mais tempo desenvolvendo e explicando claramente o problema do que fornecendo ideias.

  • Para desempenhar um papel bem-sucedido, o foco é esclarecer o problema e defender a solução, encontrando formas de apoiar uma equipe de engenharia forte para que ela assuma a solução.

• É bom ver funcionários da Amazon falando publicamente sobre o funcionamento interno do S3.

  • Gostaria de ouvir mais sobre como o Glacier funciona, e ainda há muita especulação sobre o meio de armazenamento usado, já que isso não foi divulgado.

• A parte que explica a cabeça do disco rígido comparando-a a um avião 747.

  • É um trabalho de precisão tal que equivale a um avião dar 25.000 voltas na Terra e, em um único erro, deixar passar um tufo de grama.

• 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.

  • A solução real foi dividir a carga das partições do host em quartis e mover as partições do segundo quartil para o host menos carregado.
  • Isso fez a taxa de erro passar de algo estável em torno de 1% para dias sem erros, então atualizamos os alertas para serem muito mais rígidos.

• S3 não é apenas armazenamento, é um padrão.

  • Alguns lugares oferecem armazenamento compatível com S3, e não está claro o quão aberto é o padrão, nem se é preciso pagar à Amazon para dizer "compatível com S3", mas isso é bem legal.