Reinvenção contínua: uma breve história do armazenamento em blocos da AWS
(allthingsdistributed.com)- O AWS EBS começou como armazenamento em blocos conectado pela rede para o EC2 e cresceu de um serviço baseado em HDDs compartilhados para uma frota distribuída de SSDs que processa mais de 14 trilhões de operações por dia
- As limitações iniciais de desempenho vinham não só dos 120 a 150 IOPS dos HDDs e da latência média de 6 a 8 ms, mas também do problema de noisy neighbor causado por cargas de trabalho de vários clientes compartilhando o mesmo disco
- Com a adoção de SSDs, os volumes Provisioned IOPS passaram a oferecer em 2012 até 1.000 IOPS com latência média de cerca de 2 a 3 ms, mas os gargalos migraram para rede, hipervisor e filas de software
- A equipe do EBS instrumentou todo o caminho de IO e fez melhorias em cada camada, incluindo filas do Xen, offloading com Nitro, processamento de criptografia em hardware, ajustes de TCP e até o protocolo de transporte SRD
- Os ganhos de desempenho vieram não de uma grande reescrita, mas de melhorias incrementais com migrações sem interrupção, mudanças independentes por equipes pequenas, medição contínua e possibilidade de rollback
Do armazenamento em blocos para EC2 a uma frota massiva de SSDs
- O EBS começou em 20 de agosto de 2008, cerca de dois anos após o lançamento beta do EC2, a partir da ideia de oferecer armazenamento em blocos conectado pela rede para instâncias EC2
- Na época, a equipe tinha um ou dois especialistas em armazenamento e alguns engenheiros de sistemas distribuídos, que começaram a construir o serviço com base em conhecimentos de sistemas computacionais e redes
- Desde então, o EBS deixou de ser um produto baseado em HDDs compartilhados e se tornou um serviço capaz de fornecer centenas de milhares de IOPS a uma única instância EC2
- Hoje, a quantidade de IOPS disponível para uma única instância é maior do que o nível que toda uma Availability Zone recebia na era inicial baseada em HDD
- O EBS como um todo processa mais de 14 trilhões de operações por dia em uma frota distribuída de SSDs
- A principal carga de trabalho são os discos de sistema das instâncias EC2, em um modelo mais próximo de oferecer, via armazenamento de rede, o papel que um disco rígido cumpre dentro de um servidor físico
- Os clientes valorizam a durabilidade, mas desempenho e disponibilidade, por estarem diretamente ligados à experiência com EC2, são igualmente importantes
- Volumes io2 Block Express e snapshots de volume são componentes fundamentais oferecidos para atingir alta durabilidade
- O desempenho e a disponibilidade dos volumes EBS quase se refletem diretamente na experiência das aplicações baseadas em EC2
As limitações iniciais causadas por filas e HDDs
- Em sistemas computacionais, requisições de armazenamento são processadas passando por várias filas entre CPU, barramentos e dispositivos
- No armazenamento em rede, surgem várias filas entre o kernel do sistema operacional, o adaptador de armazenamento, o fabric de armazenamento, o adaptador de armazenamento de destino e a mídia de armazenamento
- Quando o EBS foi criado pela primeira vez em 2008, o mercado de armazenamento era dominado por HDDs, e a latência era determinada principalmente pela própria mídia
- Discos rígidos são dispositivos mecânicos e têm limites físicos
- Durante décadas, o desempenho de HDDs ficou em torno de 120 a 150 operações por segundo, com latência média de IO de 6 a 8 ms
- Por causa de filas e reordenação de comandos dentro do drive, a latência de cauda podia chegar a centenas de ms
- Como a latência end-to-end do EBS naquela época era da ordem de dezenas de ms, as dezenas de microssegundos adicionadas pela rede representavam uma parcela pequena da latência total
- O desempenho de HDDs é fortemente afetado por outras operações acumuladas na fila
- Pequenas requisições aleatórias espalhadas pela mídia levam mais tempo para localizar e acessar do que várias requisições grandes e próximas umas das outras
- Distribuir clientes por vários discos reduzia picos extremos de latência das cargas mais intensas, mas espalhava esse comportamento irregular para mais clientes
- O problema de noisy neighbor, em que uma carga de trabalho afeta outra, tornou-se uma questão importante de negócio
- A AWS entendeu que era necessário um forte isolamento de desempenho para elevar a qualidade da experiência do cliente
- Mudanças em algoritmos de escalonamento de disco e a distribuição das cargas por mais spindles trouxeram apenas pequenas melhorias incrementais
A importância da instrumentação que ficou clara após a adoção de SSDs
- Por volta de 2011, SSDs se tornaram mais populares e passaram a ser oferecidos em capacidades que a AWS podia considerar
- SSDs não têm movimentação física de braço para localizar dados, atendem requisições aleatórias quase tão rápido quanto sequenciais e contam com vários canais entre o controlador e os chips NAND
- O EBS primeiro criou um novo tipo de servidor de armazenamento baseado em SSD e um novo tipo de volume chamado Provisioned IOPS
- O lançamento do novo tipo de volume não foi um trabalho pequeno, e as cargas de trabalho capazes de aproveitá-lo eram limitadas
- Ao contrário da expectativa de que trocar HDD por SSD resolveria quase tudo, o problema de noisy neighbor não desapareceu automaticamente
- O Provisioned IOPS, lançado em agosto de 2012, oferecia até 1.000 IOPS
- Isso era 10 vezes mais que os volumes EBS standard existentes
- A latência média caiu para cerca de 2 a 3 ms, uma melhora de 5 a 10 vezes
- O controle de outliers também melhorou bastante
- Nesse ponto, o EBS só tinha telemetria básica, e era necessária uma instrumentação bem mais detalhada para decidir o que corrigir
- A equipe construiu uma forma de rastrear todo IO em vários pontos
- O initiator cliente do EBS
- A pilha de rede
- O mecanismo de durabilidade do armazenamento
- O sistema operacional
- Além do monitoramento das cargas de trabalho dos clientes, também foram criados testes canário para verificar continuamente os efeitos positivos e negativos de mudanças em cargas de trabalho bem conhecidas
O trabalho de melhoria dividido entre hardware e software
- A nova telemetria mostrou com clareza onde investir primeiro
- Era preciso reduzir o número de filas em todo o sistema
- Havia espaço para diminuir a complexidade do caminho de IO no hipervisor Xen usado no EC2
- Era necessário otimizar o software de rede
- O mecanismo central de durabilidade precisava de melhorias como layout de dados on-disk, otimização de cache line e adoção de um modelo de programação assíncrono
- Na AWS, problemas de desempenho de sistemas frequentemente atravessam ao mesmo tempo várias camadas da pilha de hardware e software
- O EBS colocou em movimento, em paralelo, a equipe de servidores de armazenamento e a equipe cliente, com participação também dos engenheiros do hipervisor do EC2 e do grupo interno de desempenho de rede da AWS
- A organização de desenvolvimento também foi dividida no estilo divide and conquer, como um sistema de software
- A equipe monolítica de desenvolvimento do servidor de armazenamento foi reorganizada em pequenas equipes por área, como replicação de dados, durabilidade e hydration de snapshots
- Cada equipe podia iterar e aplicar mudanças de forma independente com base em testes rigorosos
- O blueprint criado em 2013 não era idêntico ao EBS atual, mas indicava a direção a seguir
- Na época, não se previa que a Amazon um dia criaria seu próprio SSD e teria uma pilha tecnológica ajustada às necessidades do EBS
Removendo gargalos do Xen ao Nitro e ao SRD
- Até o fim de 2017, todas as instâncias EC2 rodavam sobre o hipervisor Xen
- No caminho de dispositivos do Xen havia uma ring queue em que o domínio guest e o domínio privilegiado de driver, o dom0, compartilhavam informações, e o cliente EBS executava como dispositivo de bloco do kernel no dom0
- Até sair da instância e deixar o host do EC2, uma requisição de IO passava por várias filas
- Fila do dispositivo de bloco da instância
- Xen ring
- Fila do dispositivo de bloco do kernel do dom0
- Fila de rede do cliente EBS
- A equipe do EBS escreveu vários dispositivos de loopback para isolar o impacto de cada fila
- Mesmo quando a latência do driver de dispositivo do dom0 era quase inexistente, foi confirmado que, quando várias instâncias geravam IO ao mesmo tempo, o throughput efetivo do sistema inteiro diminuía
- O EC2 foi lançado com a quantidade padrão de filas de dispositivos de bloco e entradas de fila do Xen
- Esses valores padrão tinham sido definidos com base no hardware de armazenamento limitado do ambiente de desenvolvimento anterior do Xen
- O número de requisições de IO outstanding era limitado a 64 para o host inteiro, e não por dispositivo
- Em 2013, estava em andamento o desenvolvimento da primeira Nitro offload card dedicada a rede
- O processamento da rede definida por software da VPC foi movido do kernel do Xen dom0 para um pipeline de hardware dedicado
- Ao separar o data plane de processamento de pacotes do hipervisor, não era mais necessário usar ciclos de CPU das instâncias dos clientes para tratar tráfego de rede
- A mesma abordagem foi aplicada ao armazenamento EBS
- Mais processamento foi movido para hardware, reduzindo filas do sistema operacional no hipervisor
- O offloading de trabalho baseado em interrupções reduziu o tempo que o hipervisor gastava processando requisições
- A segunda placa Nitro também incluía recursos de hardware capazes de tratar volumes EBS criptografados sem impacto de desempenho
- O material de chaves de criptografia foi separado do hipervisor, dando proteção adicional aos dados dos clientes
- Depois da migração do EBS para Nitro, o gargalo se deslocou para a própria rede
- Foram revisados parâmetros modernos de ajuste de TCP para datacenters e algoritmos de controle de congestionamento
- Houve casos em que adicionar um pequeno atraso aleatório às requisições do servidor de armazenamento reduziu a latência média e os outliers graças a um efeito de smoothing na rede
- Esses ajustes não duravam para sempre à medida que desempenho e escala do sistema continuavam crescendo, e seguia sendo necessário medir e monitorar continuamente para evitar regressões
- Em 2014, começou o trabalho baseado em Scalable Reliable Datagram (SRD) com o objetivo de encontrar uma abordagem melhor que TCP
- O artigo relacionado é A Cloud-Optimized Transport Protocol for Elastic and Scalable HPC
- Os requisitos incluíam melhor recuperação de falhas e capacidade de desvio, além de facilidade para offloading em hardware
- No projeto do SRD, duas observações foram importantes
- Era possível focar no design da rede de datacenters da AWS, e não na Internet geral
- Em armazenamento, a ordem de execução das requisições de IO em voo pode ser reordenada
- Assim, foi possível evitar o custo da entrega estritamente in-order do TCP e executar, na chegada, requisições enviadas por vários caminhos de rede
- O SRD é usado não só em armazenamento, mas também em rede
- No Elastic Network Adapter(ENA) Express, o SRD melhora o desempenho da pilha TCP do guest
- Ele permite usar vários caminhos de rede e reduzir overflow e filas em dispositivos intermediários, elevando a utilização da rede
Cache SSD e migração sem interrupção
- O EBS não se contentou com uma situação em que só alguns volumes e alguns clientes obtinham melhor desempenho, e buscou levar os benefícios dos SSDs de forma mais ampla
- Na época, havia milhões de volumes de clientes non-provisioned IOPS rodando em milhares de servidores de armazenamento
- Alguns desses volumes ainda existem hoje
- Descartar e substituir todo o hardware teria um custo elevado
- Havia espaço livre no chassi do servidor, mas o único ponto que não atrapalhava o fluxo de ar de resfriamento ficava entre a placa-mãe e os ventiladores
- Os SSDs eram pequenos e leves, mas não podiam ficar soltos dentro do chassi; com ajuda de cientistas de materiais e depois de tentativa e erro, encontrou-se uma fita industrial de fixação hook and loop resistente ao calor
- Durante alguns meses de 2013, o EBS instalou manualmente 1 SSD em cada um dos milhares de servidores
- No software, foi adicionada uma pequena mudança para fazer staging de novas gravações no SSD, retornar a conclusão para a aplicação e depois fazer flush assíncrono para o HDD mais lento
- Esse trabalho foi realizado sem interrupção para os clientes
- Desde o início, o EBS foi projetado considerando eventos de manutenção sem interrupção
- Era possível redirecionar um volume EBS para um novo servidor de armazenamento e atualizar ou reconstruir um servidor vazio
- A capacidade de mover volumes de clientes para novos servidores de armazenamento continuou útil muitas vezes depois disso
- Foi usada ao introduzir estruturas de dados mais eficientes para o formato on-disk
- Também serviu na substituição de hardware antigo por hardware novo
- Alguns volumes criados nos primeiros meses após o lançamento do EBS em 2008 ainda continuam ativos
- É provável que esses volumes tenham passado por centenas de servidores diferentes e por várias gerações de hardware
- Atualizações e reconstruções da frota foram feitas sem impactar essas cargas de trabalho
Um estilo de liderança adaptado à escala de desempenho
- A escala do EBS era diferente, não só tecnicamente, mas também do ponto de vista organizacional, em relação ao ambiente de empresas pequenas ou startups
- Se especialistas em sistemas se envolvessem em toda escalada, revisão de commit e análise de mudança de design, poderiam se tornar um gargalo de desempenho da organização
- Para resolver isso, houve experimentação não só no código, mas também na forma de colaboração
- Uma ferramenta representativa foi o peer debugging
- Vários engenheiros acompanhavam juntos o código e o terminal enquanto rastreavam o problema
- Em um caso, descobriram que o problema estava em onde e como era feito o locking nas atualizações de uma estrutura de dados crítica
- Em geral, o problema não aparecia, mas ocasionalmente a resposta a requisições ficava lenta, e corrigi-lo removeu uma das causas de jitter
- Dar autonomia para que engenheiros experimentem com segurança, reduzindo barreiras mas mantendo guardrails, podia levar a resultados melhores
Melhoria contínua em vez de grandes reescritas
- A evolução do EBS não aconteceu por meio de uma única mudança gigantesca, mas como uma sequência de melhorias incrementais ao longo do tempo
- Essa abordagem permitiu entregar valor ao cliente mais rapidamente e ajustar a direção com base no que era aprendido à medida que as cargas de trabalho dos clientes mudavam
- A experiência de latência do EBS melhorou de um nível médio de mais de 10 ms por operação de IO para um IO consistente abaixo de 1 ms nos volumes io2 Block Express de maior desempenho
- Essa transformação foi alcançada sem colocar o serviço offline para introduzir uma nova arquitetura
- Os clientes continuam querendo cada vez mais desempenho, e essa demanda segue impulsionando a inovação e a iteração do EBS
1 comentários
Comentários do Hacker News
Fico muito feliz de ver este texto aqui. Se você tem o mínimo interesse em sistemas de grande escala, vale muito a leitura.
Em cargas de trabalho sequenciais, discos magnéticos modernos conseguem entregar mais de 100 MB/s em leitura/gravação, mas em cargas totalmente aleatórias de 4 kB isso pode cair para 400 kB/s. Mesmo que filas e escalonamento evitem o pior, o desempenho real varia mais de 100 vezes dependendo da carga de trabalho, o que é muito difícil para um sistema multi-tenant lidar. Especialmente para leituras, não há uma saída como “simplesmente gravar em outro lugar”.
A maior coisa que aprendi com o Marc foi que, para saber o que quebrou, primeiro é preciso enxergar direito. Ele criava visualizações de latência, como a série temporal de histogramas do artigo, e contava uma história com essas visualizações, fazendo a equipe enxergar de forma completamente diferente o que precisava ser feito. Cada pico no histograma tinha sua própria causa e seu próprio trabalho de otimização, e investir em olhar os dados de desempenho em profundidade, de várias maneiras, abre eficiências e oportunidades que de outro modo não apareceriam.
O projeto de retrofit de 2013, que colocou um SSD em cada um de milhares de servidores, é um dos meus casos favoritos nas histórias da AWS. Isso foi possível porque, desde o início, os eventos de manutenção sem downtime foram considerados: volumes EBS podiam ser redirecionados para novos servidores de armazenamento, enquanto servidores vazios eram atualizados ou reconstruídos. É um bom exemplo de que sistemas distribuídos não servem apenas para escalar; eles também tornam possível a operação em larga escala ao tolerar naturalmente falhas de servidores e permitir mover dados sem perda.
Dick Lyon, do Google, também usou a mesma abordagem nos servidores de armazenamento do Google e, a partir do slide 62 de https://www.pdl.cmu.edu/SDI/2015/slides/DatacenterComputers...., identificou várias filas e contenção de recursos como os principais gargalos do armazenamento em bloco.
Isso me traz lembranças antigas. O Reddit foi um dos primeiros usuários do EBS em 2008, e achávamos que éramos espertos por descobrir que fazer software RAID com 5 volumes EBS aumentava os IOPS.
Na época, o desempenho de cada volume era muito irregular, então subíamos 7 ou 8 volumes, rodávamos carga de leitura/gravação e escolhíamos os 5 com melhor desempenho para juntar em um RAID por software no Linux. Quando dava certo, tinha o efeito desejado e às vezes entregava mais IOPS do que 5 vezes um único nó; quando dava errado, era realmente horrível.
Não sabíamos que, em software RAID, se um nó fica lento, o RAID inteiro passa a operar na velocidade do volume mais lento, e o resultado parecia que o banco de dados estava quebrando. Levou um tempo para descobrirmos que a causa era o RAID, e também era difícil remover o nó ruim. O software RAID não queria soltá-lo até terminar as gravações naquele volume lento.
Era preciso adicionar um novo volume EBS e reconstruir o array, o que também era ruim porque ficava limitado pelos IOPS do novo volume. Depois disso, deixamos de usar esse software RAID, e na Netflix quase não usamos EBS. Eu contava os erros que cometemos no Reddit para todo mundo que quisesse ouvir, e, antes mesmo de eu entrar, a Netflix já tinha padronizado o uso de apenas discos locais.
Como curiosidade divertida, durante a grande falha do EBS na AWS, eu trabalhava no Reddit e estava assistindo à Netflix enquanto esperava o EBS voltar para consertar o banco de dados. Na entrevista na Netflix, perguntei: “Como vocês sobreviveram durante a falha do EBS?”, e a resposta foi: “Ah, nós simplesmente não usamos EBS”.
Gostei de ler este texto.
Um ponto interessante é que, no período abordado pelo artigo, lembro que a AWS teve uma interrupção de cerca de 4 dias por causa do EBS, afetando EC2, EBS e RDS. Essa falha abalou bastante a confiança na AWS.
Como resultado, houve uma reorganização, e o EBS passou a receber um investimento muito mais profundo como serviço independente. Esse período também coincidiu com a Apple se tornando cliente e com o crescimento acelerado da AWS como um todo graças à adoção por startups como Netflix, Zynga e Dropbox.
Essas histórias técnicas e operacionais são interessantes, mas inovação tecnológica em produção é bagunçada e acontece sobre o pano de fundo de exigências reais de negócio. Seria ótimo ouvir mais histórias desse tipo também.
Mas a roda voltou a girar e o trabalho retornou ao desenvolvimento de funcionalidades. Sempre me lembro daquele ano como o período com menos escalations enquanto estive lá.
Fiquei curioso com a parte em que “adicionar uma pequena quantidade de latência aleatória às requisições do servidor de armazenamento reduzia a latência média e os outliers, por causa do efeito de suavizar a rede”. Alguém consegue explicar por quê?
Se houver interesse, existe uma palestra de 2009 [0] sobre a estrutura interna do Amazon S3. Ela foi feita com base em materiais internos da equipe do S3, e muito do que aparece ali também influenciou a forma como o EBS foi desenvolvido.
[0]: https://vimeo.com/7330740
Gostei da parte em que, em 2013, eles adicionaram SSDs manualmente a todos os equipamentos do EBS. Pela foto, parece bastante com um SSD SATA da Samsung
https://www.allthingsdistributed.com/images/mo-manual-ssd.pn...
Minha memória pode estar errada, mas acho que usar SSDs instalados em blades Dell já vinha de bem antes disso. Por volta de 2010–2012, o desempenho de I/O era uma questão enorme, e era o período de transição dos discos rígidos giratórios para memória flash
Lembro de experimentos com dispositivos baseados em flash bruto, sem nenhum tratamento de erros nem nivelamento de desgaste. Era uma loucura, mas todo mundo estava desesperado pelos enormes ganhos de desempenho de I/O ao sair dos discos giratórios e ir para o silício
A velocidade dos discos subiu tão rápido que, em seis meses, o primeiro SKU ficou obsoleto. Fico feliz por não ter precisado explicar pessoalmente à equipe de ativos quando descartamos aqueles racks anos antes do planejado. Colocar modelos novos, mais densos e mais rápidos fazia o valor da posição no rack ser muito maior
Isso me fez lembrar de quando criávamos infraestrutura de armazenamento como serviço antes de existir algo open source utilizável. Saímos de Sun SAN, Fibre Channel e Solaris para GlusterFS sobre servidores de armazenamento Supermicro rodando Linux e NFS, e chegamos a quase 2 PB antes de eu sair, em 2007
Também me lembro de uma época em que simplesmente fazia sentido quebrar e reconstruir mdraid às escondidas, com o servidor em execução, trocando discos giratórios por SSDs. Isso porque o SATA oferecia algum suporte a hot swap de unidades. Ao trocar discos giratórios por SSDs, o IOPS do sistema mais importante da plataforma aumentou 14 vezes
No início da minha carreira, trabalhei em sistemas de ponta a ponta numa empresa de internet que era grande em escala técnica e operacional, não em número de pessoas. A quantidade de lições que aprendi em pouco tempo foi absurda. Depois que saí daquela empresa, percebi que a maioria das pessoas quase nunca encontra esse tipo de problema ao longo da carreira e, por isso, também não aprende essas lições
Por isso acho que deveria existir um sistema de qualificação profissional. Se exigíssemos um aprendizado sob a orientação de engenheiros experientes, seria possível adquirir em pouco tempo conhecimentos e habilidades muito valiosos que só se aprendem pela experiência, e depois trabalhar de forma muito mais eficaz. Para quem entrevista candidatos, evidências de experiência e recomendações de mentores também seriam muito valiosas
Gostei desta frase
“O ideal amplamente exaltado do engenheiro full-stack também tem valor, mas, em sistemas profundos e complexos, muitas vezes é mais valioso formar um grupo de especialistas capaz de colaborar e trabalhar de forma criativa atravessando toda a stack e suas respectivas áreas de especialização profunda”
O primeiro diagrama do texto é impreciso ou bastante antigo. Em computadores modernos, a maioria das linhas PCIe se conecta diretamente ao hub de I/O da CPU ou à área Uncore, em vez de passar por um PCH separado como antes
Isso é um avanço importante tanto para a vazão de I/O quanto para a latência. No restante, é um ótimo texto e mostra bem que, no fim, tudo é fila
Vou deixar claro na legenda da imagem que aquela é a estrutura daquela época