Reinvenção contínua: uma breve história do armazenamento em blocos da AWS

Reinvenção contínua: uma breve história do armazenamento em blocos da AWS

• Introdução

  • Marc Olson trabalha há mais de 10 anos na equipe do Elastic Block Store (EBS).
  • O EBS evoluiu de um simples serviço de armazenamento em blocos para um sistema de armazenamento em rede em grande escala que processa mais de 140 trilhões de operações por dia.
  • Este texto compartilha o processo de evolução do EBS e lições importantes.

• História inicial do EBS

  • O EBS foi lançado em 20 de agosto de 2008 e começou com uma ideia simples: fornecer armazenamento em blocos conectado pela rede para instâncias EC2.
  • No início, usava discos rígidos compartilhados (HDD), e hoje pode oferecer centenas de milhares de IOPS para uma única instância EC2.
  • Atualmente, o EBS processa mais de 140 trilhões de operações por dia por meio de uma frota distribuída de SSDs.

• Teoria das filas

  • A forma como os sistemas computacionais interagem com o armazenamento não mudou fundamentalmente.
  • A CPU coloca solicitações em uma fila, e o dispositivo de armazenamento busca os dados na memória da CPU para gravá-los em uma mídia durável ou, no sentido inverso, transfere os dados para a memória da CPU.
  • A teoria das filas tem um papel importante para entender esse processo.

• A transição de HDD para SSD

  • O EBS inicial usava HDDs, o que limitava o desempenho por causa de restrições físicas.
  • Com a chegada dos SSDs, até solicitações aleatórias passaram a poder ser processadas quase tão rápido quanto solicitações sequenciais.
  • Em 2012, foi lançado um novo tipo de servidor de armazenamento com SSDs e um novo tipo de volume EBS chamado Provisioned IOPS.

• Medição e gestão

  • Em 2012, o EBS contava apenas com telemetria básica.
  • Para melhorar o desempenho do sistema, era preciso descobrir o que estava errado e resolver isso por ordem de prioridade.
  • Foram criadas formas de medir IO em vários subsistemas e detectar mudanças por meio de monitoramento contínuo.

• Dividir e conquistar na organização

  • A equipe de servidores de armazenamento do EBS foi reorganizada em times menores focados em áreas específicas, como replicação de dados, durabilidade e hidratação de snapshots.
  • Cada equipe podia iterar e aplicar mudanças de forma independente.

• Questionando premissas

  • Descobriu-se que a configuração padrão do hipervisor Xen estava limitando o desempenho.
  • Cartões de offload Nitro foram usados para transferir para o hardware o processamento de rede e armazenamento.

• Experimentos de ajuste de rede

  • Ao migrar o EBS para o Nitro, o overhead da própria rede aumentou.
  • Para melhorar o desempenho de rede, foi desenvolvido o protocolo SRD (Scalable Relatable Diagram) no lugar do TCP.

• Restrições impulsionam a inovação

  • Para oferecer os benefícios do SSD a todos os clientes, SSDs foram adicionados sem substituir o hardware existente.
  • Os SSDs eram adicionados manualmente aos servidores, novas gravações eram armazenadas primeiro neles e depois enviadas de forma assíncrona para os HDDs.

• Reflexões sobre escalabilidade de desempenho

  • Uma história de crescimento pessoal: a transição da cultura de uma empresa pequena para uma organização de grande porte.
  • Sessões de depuração com colegas ajudaram a resolver problemas e aumentar a eficiência da equipe.

• Conclusão

  • O EBS evoluiu não por meio de uma única grande mudança, mas por uma série de melhorias graduais.
  • As demandas dos clientes continuarão crescendo, e isso motiva a continuidade da inovação e da iteração.

# Resumo do GN⁺

• Este texto oferece a perspectiva de alguém de dentro sobre como o EBS da AWS evoluiu.
• Aborda vários desafios técnicos e suas soluções, como teoria das filas, adoção de SSD e ajuste de rede.
• Enfatiza a importância de medição e gestão contínuas para melhorar o desempenho.
• Produtos com funcionalidades semelhantes incluem Google Cloud Persistent Disk e Microsoft Azure Disk Storage.

[GN⁺]

Opinião no Hacker News

• Vale a pena ler este artigo se você se interessa por sistemas de grande porte

  • O desempenho do disco rígido varia conforme as outras transações na fila
  • Em operações aleatórias de 4 kB, o desempenho pode cair bastante
  • Enfileiramento e escalonamento ajudam, mas o desempenho real pode variar em mais de 100x dependendo da carga de trabalho
  • Em sistemas multitenant, há dificuldades especialmente nas operações de leitura

• Para resolver um problema, é preciso saber o que está errado

  • A maior lição aprendida com Marc foi mudar a perspectiva da equipe por meio de visualizações
  • Analisar dados de desempenho de várias formas pode revelar eficiências e oportunidades que não eram visíveis

• O projeto de instalar SSDs em servidores EBS em 2013 é uma das histórias interessantes da AWS

  • O sistema foi projetado desde o início pensando em eventos de manutenção não destrutiva
  • Construir sistemas distribuídos torna possível operar em grande escala

• A interrupção de cerca de 4 dias da AWS foi causada pelo EBS e abalou a confiança na AWS

  • Isso levou ao aumento dos investimentos em EBS
  • Coincidiu com o período em que a Apple estava se tornando cliente

• O Reddit foi um dos primeiros usuários do EBS em 2008

  • Tentou aumentar os IOPS usando RAID por software, mas o desempenho não era consistente
  • Levaram tempo para resolver os problemas do RAID
  • A Netflix não usava EBS

• Adicionar latência aleatória tem o efeito de reduzir a latência média e os outliers

• Trabalhar em grandes empresas de internet trouxe muitas lições

  • Por meio de aprendizado prático, é possível adquirir rapidamente conhecimentos e habilidades importantes
  • Em entrevistas, a experiência e a recomendação de mentores são muito úteis

• Foi interessante a parte em que, em 2013, SSDs foram instalados manualmente em todas as unidades EBS

  • Entre 2010 e 2012, o desempenho de I/O era uma questão importante

• Em 2009, houve uma palestra sobre a parte interna do Amazon S3

  • Essa palestra influenciou o desenvolvimento do EBS

• No início da nuvem, usava-se hardware de uso geral, mas agora são usados hardwares especializados para serviços individuais

  • A AWS usa chips Graviton, Inferentia e Tranium
  • O Google usa TPU e a placa de segurança Titan
  • A Azure usa FPGA e Sphere

• O primeiro diagrama está errado ou desatualizado

  • Nos computadores modernos, a maioria das lanes PCIe se conecta diretamente à CPU
  • Isso é um avanço importante para throughput e latência de I/O

• Estou procurando a melhor forma de fornecer um diretório de dataset rápido de 256 GB para novas instâncias EC2

  • Estou usando volumes EBS, mas as atualizações são trabalhosas
  • O EFS é lento demais
  • O SSD de armazenamento da instância é temporário
  • Ainda não experimentei o FSx Lustre