Como reconstruímos frotas de nodes 15x mais rápido

A maior parte do nosso trabalho de confiabilidade é invisível por design. Você envia uma requisição RPC, recebe uma resposta em poucos milissegundos e nunca pensa na máquina que a atendeu. É exatamente assim que deveria ser. Mas por trás dessa única requisição existe uma frota de nós blockchain que precisa se manter saudável o tempo todo, em várias chains, em múltiplas regiões, sem interrupção. Manter essa frota saudável em escala acaba sendo um problema de movimentação de dados, e um problema muito maior do que a maioria imagina.

Este post trata de um investimento específico que fizemos para resolver isso: um sistema de transferência de dados de alta largura de banda e paralelizado, construído internamente, combinado com uma rede privada dedicada entre nossas máquinas. Juntos, eles nos permitem reconstruir o storage de nós em uma fração do tempo que costumava levar. Este é, antes de tudo, um investimento em confiabilidade, e confiabilidade é o que mantém a latência baixa e consistente quando o hardware falha. É uma peça deliberada das garantias de disponibilidade sobre as quais nossos clientes constroem com nossa infraestrutura de nós, não a história completa de como defendemos a latência.

A versão honesta da afirmação, desde já: isso não torna uma chamada RPC individual mais rápida em um dia normal, porque não está no caminho da sua requisição. O que isso faz é tornar a recuperação rápida e confiável exatamente quando uma máquina falha, o momento em que sua latência corre mais risco. Então sim, isso sustenta a baixa latência, nos casos extremos em que ela importa.

O que estamos realmente recuperando?

Vale responder diretamente, porque "recuperação" pode significar algumas coisas. Trata-se de restaurar o estado do nó (o conjunto de dados de blockchain em disco que um nó precisa para responder requisições) em hardware saudável. Não se trata de recuperar uma requisição individual que falhou, dados em trânsito, ou o hardware físico em si.

Recorremos a isso em três situações:

• Um nó falha ou se degrada. O hardware ou seu disco não está saudável, então colocamos um substituto em funcionamento e precisamos carregar o estado completo da chain nele rapidamente.
• Adicionamos capacidade. O tráfego de uma chain cresce e precisamos de mais nós saudáveis atendendo a ela, cada um precisando do conjunto de dados completo antes de poder receber tráfego.
• Colocamos em funcionamento uma nova chain ou região. Novos nós começam vazios e precisam de terabytes de estado antes de serem úteis.

Nos três casos, o gargalo é o mesmo: colocar um conjunto de dados grande e em crescimento constante em hardware novo, de forma rápida e confiável.

Por que reconstruir um nó blockchain é um problema de movimentação de dados?

Um full node ou archive node de blockchain não é algo pequeno. Dependendo da chain, seu estado em disco varia de centenas de gigabytes até a faixa de múltiplos terabytes, e cresce todos os dias. Toda vez que enfrentamos uma das situações acima, precisamos colocar esse estado em hardware novo, rápido.

Existem duas formas lentas de fazer isso. Você pode sincronizar a partir da rede, deixando o nó reproduzir o histórico a partir de seus peers, o que pode levar dias para uma chain grande. Ou você pode copiar o estado de um nó saudável que você já opera. Copiar é dramaticamente mais rápido do que sincronizar do zero, então é esse o caminho que otimizamos.

O problema: copiar terabytes ainda é lento se você fizer isso um nó por vez, por um caminho de rede compartilhado, com uma ferramenta que nunca foi construída para essa escala.

O que é o rsync, e por que superamos sua capacidade?

Não começamos construindo algo novo. Durante anos usamos o rsync, a ferramenta padrão do Unix para copiar e sincronizar arquivos entre máquinas.

O que é. O rsync copia arquivos de uma máquina para outra e é inteligente em execuções repetidas: ele usa um algoritmo de delta com checksum incremental para transferir apenas as partes de um arquivo que mudaram, em vez de recopiar tudo. É testado em batalha, onipresente, e sua abordagem de transferência por delta torna cópias incrementais baratas. Para sincronizar um conjunto de dados entre duas máquinas, é difícil superar.

Onde ele falhou para nós. O rsync foi projetado para sincronizar arquivos entre dois hosts, não para mover terabytes para hardware novo sob pressão de tempo. Na nossa escala, ele esbarrou em um limite rígido: throughput. Um único stream do rsync é em grande parte serial e não chega perto de saturar o hardware de rede e storage rápido que operamos, então boa parte da largura de banda disponível fica ociosa. Em escala de frota, essa capacidade desperdiçada se acumula em horas de tempo de reconstrução por nó e em um atrito operacional real. O rsync não estava errado. Simplesmente superamos aquilo para o qual ele foi construído. Então construímos uma ferramenta de transferência projetada desde o início para uma única tarefa: mover conjuntos de dados enormes para nós novos o mais rápido que o hardware permitir.

Como fazemos isso: uma rede privada dedicada mais uma ferramenta de transferência paralela

Atacamos o problema em duas frentes ao mesmo tempo: a estrada e o veículo.

A estrada: uma rede privada dedicada

Movemos a transferência em massa de dados de nós para uma rede privada dedicada entre nossas máquinas, separada do caminho que atende ao tráfego de produção.

Duas coisas mudam no momento em que a cópia roda nessa rede privada. Primeiro, a transferência em massa deixa de competir com o tráfego de requisições de produção, então uma reconstrução grande nunca coloca em risco a latência voltada ao cliente. Segundo, ela entrega largura de banda alta e previsível entre nós: a capacidade bruta que a ferramenta de transferência foi construída para usar, chegando a dezenas de gigabits por segundo.

O veículo: uma ferramenta de transferência paralela construída sob medida

Nossa ferramenta interna faz uma única tarefa: enviar um diretório completo de estado de nó de uma máquina de origem saudável para uma máquina de destino o mais rápido possível. O design é construído em torno de saturar um link de alta largura de banda que uma única cópia serial deixaria majoritariamente ocioso. Três ideias fazem o trabalho:

• Muitas conexões paralelas. Em vez de um único stream, a transferência roda em muitas conexões TCP concorrentes ao mesmo tempo, de modo que consegue de fato preencher a largura de banda da rede privada.
• Divisão de arquivos muito grandes. Um único arquivo de estado de múltiplos terabytes engargalaria uma conexão, então arquivos acima de um limite de tamanho configurável são divididos em pedaços por offset de byte, e cada pedaço é enviado por sua própria conexão em paralelo. O destino grava cada pedaço diretamente no offset correto do arquivo.
• Agrupamento de arquivos pequenos e priorização dos maiores primeiro. Muitos arquivos pequenos são agrupados para amortizar a sobrecarga por transferência, e os arquivos maiores começam primeiro para que as transferências mais longas já estejam em andamento imediatamente.

A orquestração: Ansible e AWX

Uma ferramenta de transferência rápida só é útil se você conseguir operá-la de forma confiável em muitas máquinas sem uma pessoa digitando comandos. Orquestramos reconstruções com Ansible, que executa tarefas definidas em muitos servidores, gerenciado pelo AWX, seu plano de controle de agendamento e execução de jobs.

O resultado é que uma reconstrução se torna um job repetível e auditável: selecione o alvo, inicie o workflow, e deixe o sistema levar o estado pela rede privada em paralelo - com resultados consistentes todas as vezes.

Quanto mais rápida é nossa solução em comparação ao rsync?

Nossa ferramenta é de 10 a 15 vezes mais rápida. O rsync single-threaded move o estado do nó a 100-200 MB/s. Nossa transferência paralelizada sustenta 2-3 GB/s.

Essa velocidade aparece onde importa, em uma reconstrução real. Em uma execução de produção, reconstruímos uma frota de Base Mainnet de 13 nós (uma origem, doze destinos) com a transferência de dados real concluindo em cerca de 35 minutos, e o workflow completo, incluindo configuração e desmontagem da rede privada, terminando em aproximadamente 1 hora e 27 minutos, com zero falhas e zero nós inacessíveis. A abordagem antiga, nó por nó, transformava o mesmo tipo de reconstrução em um processo arrastado de várias horas.

O que isso viabiliza para você com a Alchemy

Esta é uma capacidade de camada de fundação, então seu benefício alcança qualquer produto que rode sobre nossa frota de nós. O mecanismo é sempre o mesmo (uma falha de hardware se resolve antes de poder concentrar carga e elevar a latência de cauda), mas eis o que isso significa para você, produto por produto.

• Node & RPC APIs (RPC API da Alchemy): seus tempos de resposta p95/p99 permanecem estáveis durante a falha de um nó, porque um nó degradado é substituído antes que os sobreviventes fiquem sobrecarregados. Menos picos de requisições lentas para seus usuários.
• Data & indexing APIs (Transfers, Balances, Token, Webhooks): menos lacunas e menos atraso nos dados que você consome quando um nó de suporte é reconstruído, porque a recuperação é uma janela curta em vez de horas. Dados mais confiáveis, mais cedo.
• Rollups & chain services: restauração de capacidade mais rápida para sua chain dedicada ou específica de aplicação, de modo que uma única falha de hardware não se transforme em uma janela prolongada de degradação para seu app.

Esses são ganhos reais de consistência: mantemos sua experiência rápida tornando os momentos difíceis curtos e raros.

Por que isso importa para quem nunca vê isso

Eis a conexão de volta com sua aplicação. Quando um nó se degrada ou falha, seu tráfego precisa migrar para os nós saudáveis restantes. Se reconstruir um substituto é lento, essa pressão fica sobre os sobreviventes por mais tempo, e carga concentrada é exatamente o que eleva a latência de cauda: os tempos de resposta p95 e p99 que se manifestam como suas requisições mais lentas. (O tratamento clássico desse efeito é o de Dean e Barroso, The Tail at Scale.) A recuperação rápida encolhe essa janela. A frota se recupera antes que a degradação chegue a ser sentida como uma resposta lenta do seu lado.

É isso que queremos dizer quando afirmamos que planejamos para a falha. Não assumimos que as máquinas ficarão sempre ativas. Assumimos que elas vão falhar, e investimos para que a falha permaneça pequena e a recuperação permaneça rápida. Este sistema de transferência e a rede privada por trás dele são um desses investimentos: infraestrutura cujo trabalho inteiro é garantir que um problema de hardware em nosso data center nunca se torne um problema de latência no seu app.

Você provavelmente nunca vai notar nada disso. Esse é o objetivo.

O panorama geral: rápido, e rápido sob estresse

É fácil divulgar um bom número de latência em um dia saudável. A afirmação mais difícil, a que realmente importa em produção, é continuar rápido quando as coisas quebram. Baixa latência não é apenas uma propriedade de estado estável. É uma propriedade de como um sistema se comporta durante a falha, e de quão rápido ele se recupera. É também por isso que operamos uma infraestrutura de nós heterogênea e redundante, em primeiro lugar.

Esta é uma parte de como defendemos isso: um investimento deliberado no caminho de recuperação, para que os tempos de resposta com os quais você conta se mantenham não apenas quando tudo está verde, mas quando uma máquina cai às 3 da manhã e precisa ser reconstruída antes que alguém perceba.

Esse é o padrão que exigimos de nós mesmos. É por isso que o trabalho de performance na Alchemy vai até o ponto de determinar quão rápido conseguimos mover um terabyte entre duas máquinas.

Perguntas frequentes

Isso torna minhas requisições RPC mais rápidas?

Em um dia normal, não. Não está no caminho da sua requisição. Mas isso protege sua latência no momento em que mais importa: quando o hardware falha. Ao reconstruir um nó saudável rapidamente, isso impede que carga concentrada eleve seus p95/p99, mantendo suas requisições mais lentas rápidas sob estresse.

O que exatamente isso recupera?

O estado do nó - o conjunto de dados de blockchain em disco que um nó precisa para atender requisições. Usamos isso para substituir um nó que falhou, adicionar capacidade, ou colocar em funcionamento um novo nó ou região. Isso não recupera requisições individuais nem hardware físico.

Por que não simplesmente usar o rsync?

O rsync é excelente para sincronizar arquivos entre duas máquinas, e o usamos por anos. Mas um único stream do rsync é majoritariamente serial, então em escala de frota ele não satura nosso hardware de rede e storage, somando horas de tempo de reconstrução por nó. Nossa ferramenta executa a transferência em muitas conexões paralelas e divide arquivos muito grandes entre elas para usar toda a largura de banda de uma rede privada dedicada.

Como a recuperação mais rápida de nós melhora a latência?

Quando um nó falha, sua carga migra para os nós saudáveis restantes. Quanto mais tempo uma reconstrução leva, mais tempo essa carga concentrada eleva a latência de cauda: os tempos de resposta p95 e p99 que os usuários sentem como suas requisições mais lentas. A recuperação mais rápida encolhe essa janela para que as falhas não se manifestem como respostas lentas.

Quanto mais rápido isso é em comparação ao rsync?

Cerca de 10 a 15 vezes em throughput bruto de transferência: aproximadamente 100-200 MB/s para um único stream rsync single-threaded contra 2-3 GB/s para nossa transferência paralelizada pela rede privada. Na prática, isso transformou uma reconstrução de frota de várias horas em uma na qual a transferência de dados terminou em cerca de 35 minutos, em uma frota de 13 nós na Base Mainnet, com zero falhas.

Quer construir sobre uma infraestrutura projetada dessa forma? Explore a documentação em alchemy.com/docs.