Superando desafios únicos em nossa migração do Binance Ledger
Principais tópicos do post:
Nossa migração do Binance Ledger visava resolver o problema de conta quente inerente ao nosso antigo servidor de banco de dados relacional.
Uma corretora de criptomoedas opera 24 horas por dia, 7 dias por semana, 365 dias por ano, sem janela de manutenção, ao contrário de uma corretora regular, que tem horários de intervalo diários.
A migração para um novo Binance Ledger tinha que ocorrer on-line, mantendo os ativos dos usuários SAFU e não implicando em nenhum impacto nos negócios, para que a experiência para os usuários finais permanecesse perfeita.
Escolhemos uma estratégia de migração gradual, conta por conta, em vez de uma estratégia de transferência de uma só vez, como empregada pela ferramenta gh-ost.
O Binance Ledger sustenta nossas operações técnicas e processa milhões de transações diárias para uma vasta base de usuários. Você pode aprender mais sobre o sistema, seus objetivos e seus desafios em nosso blog Como o Binance Ledger potencializa sua experiência na Binance. Nosso processo de migração da versão antiga para a nova enfrentou um desafio típico: como poderíamos atualizar o motor em tempo real enquanto o avião ainda está em voo? Tivemos que migrar os ativos de nossos usuários, pois manter os fundos SAFU era nossa principal prioridade.
Principais desafios de migração da Binance
A lista abaixo de desafios teve que ser enfrentada para atingir os objetivos estabelecidos:
Assegurar a total correção do novo ledger (livro razão)
Ser capaz de detectar qualquer problema nos fundos e corrigi-lo de forma oportuna e precisa
Não incorrer em tempo de inatividade para upstreams
Comparando nossa missão de migração com DDL de banco de dados on-line
Antes de mergulharmos nos detalhes de nossa solução, vejamos o problema comum de executar uma DDL (linguagem de definição de dados) on-line para uma tabela grande. O que exatamente é DDL? Bem, imagine uma tabela com centenas de milhões de linhas na qual precisamos adicionar outra coluna. Queremos fazer isso on-line sem interromper os negócios.
A ferramenta gh-ost é amplamente utilizada para resolver esse problema, e você pode ver como ela funciona no diagrama a seguir.
O processo consiste essencialmente em duas fases:
A fase de sincronização, que continua até que a nova tabela seja totalmente idêntica à tabela original. Existem dois tipos de dados a serem sincronizados:
Dados existentes
Dados incrementais (novos dados gerados a partir da tabela original durante o processo de migração)
A fase de cutover trocando a tabela original pela nova sem interromper nenhuma transação em andamento.
Onde os problemas do Binance Ledger diferiram
Apesar de algumas semelhanças, o Binance Ledger teve alguns desafios inerentemente únicos em nossa missão de migração on-line.
Em primeiro lugar, os sistemas de back-end da Binance operam em um ambiente distribuído, enquanto o banco de dados on-line DDL está em um ambiente monolítico. Em segundo lugar, não podemos nos dar ao luxo de adotar a abordagem de transição de uma só vez porque os dados eram ativos de nossos usuários. Por fim, precisamos garantir que todos os serviços relevantes funcionem como um todo antes de iniciar a migração em massa.
Como no exemplo DDL on-line anterior, também houve duas fases em nossa migração:
A fase de sincronização, onde um serviço replicador dedicado foi criado especialmente para sincronizar os saldos do antigo ledger para o novo
A fase de transição conta a conta
Abordagem baseada em fases
A tarefa era grande e, como dizem, Roma não foi construída em um dia. A abordagem de dividir e conquistar geralmente funciona como um encanto diante de um domínio de problema grande e complexo.
Fase 1: replicação
Por que
Podemos resumir nosso processo de pensamento aqui em dois pontos principais:
Modelamos o Binance Ledger como um novo escravo que se junta ao cluster MySQL existente, que alimenta o sistema de contabilidade atual. Aproveitando as técnicas de replicação, conseguimos manter os saldos dos usuários totalmente sincronizados de forma assíncrona.
Assim, foi possível rotear o tráfego de produção literalmente para o Binance Ledger para validar sua correção e robustez. Mesmo se as coisas derem errado nesta fase, não haverá impacto para nós e nossos usuários.
O que
Abaixo, ilustramos o pipeline de replicação geral. O caminho crítico para prestar atenção é:
Transferência → Ledger → Replicador do Binance Ledger → Binance Ledger
Como
Dividimos o processo de replicação em duas etapas separadas:
Descartando um snapshot do banco de dados do ledger e o importando para o Binance Ledger
Replicado o log de compartimento do banco de dados do ledger após o momento em que o snapshot for descartado.
Eventualmente, os dados de saldos e logs de saldos seriam mantidos em total sincronia entre o antigo ledger e o Binance Ledger, podendo ser validado posteriormente pelo módulo de reconciliação completa.
Quando
O Binance Ledger foi lançado no início de agosto de 2022. Em seguida, iniciamos o processo de replicação, que durou até meados de novembro de 2022. Este processo foi um período importante para nós, pois a exatidão do novo sistema de ledger precisava ser validada 100%. Esta etapa não pode ser ignorada antes de prosseguir com a próxima fase de migração.
Por fim, não encontramos nenhum problema e realizamos várias rotinas de liberação para nos sentirmos mais confortáveis com a situação. O processo de três meses não foi particularmente rápido, mas foi necessário para nosso objetivo SAFU.
Fase 2: migração on-line
Por que
Para migrar centenas de milhões de contas, criamos um trabalho de migração personalizado.
O que
Abaixo, descrevemos o fluxo de migração principal para uma conta:
Aqui estão algumas notas importantes para ter em mente:
O sistema de contas mantém o mapeamento de propriedade para cada conta.
Conta A → ledger
Conta B → Binance Ledger
Conta C → proibida
Antes de migrar uma conta, se houvesse alguma transação simultânea pendente, ela seria ignorada para reduzir o impacto nos negócios.
Alteramos o mapeamento de propriedade do ledger (livro razão) para proibido, não permitindo mais atualizações de saldo, tornando-o imutável.
Reconciliamos os saldos entre o antigo ledger e o Binance Ledger.
Mudamos o mapeamento de propriedade de proibido para Binance Ledger, permitindo que futuras atualizações de saldo sejam roteadas diretamente para o Binance Ledger.
De acordo com nossa métrica de desempenho, demorou em média 150 ms do passo 3 ao passo 5. Em teoria, os usuários não podem realizar nenhuma transação durante esse período de migração de 150 ms. Descobriu-se que não houve nenhuma transação impactada.
A execução
Na Binance, defendemos o princípio de “boa execução acima do planejamento meticuloso”. A execução sólida é vital para o nosso sucesso, e a segurança dos fundos é sempre a nossa principal prioridade. Adotamos uma estratégia de migração gradual durante um período de três semanas para detectar problemas o mais cedo possível, o que, por sua vez, ajudou a reduzir a magnitude do impacto negativo.
O processo de reconciliação
A reconciliação é extremamente importante na detecção de possíveis anomalias de saldo em tempo hábil, de uma perspectiva imparcial. Podemos conduzir o processo quase em tempo real para tomar medidas imediatas antes que as coisas piorem. Dois tipos de módulos de reconciliação são desenvolvidos especificamente para o processo de migração on-line: em tempo real e completo.
Tempo real
O processo de reconciliação baseado em nível de transação é construído para detectar qualquer problema de fundos em tempo real.
Completo
Podemos realizar uma reconciliação completa periodicamente com base nos snapshots sincronizados com o data warehouse. Esse processo garante que todos os saldos sejam os mesmos entre o antigo ledger e o Binance Ledger.
Por exemplo, digamos que temos 10 milhões de usuários ainda residindo no antigo ledger. Podemos usar essa reconciliação completa para verificar se os saldos e os logs de saldo são os mesmos entre o antigo ledger e o Binance Ledger.
Encerrando o processo de migração
Em poucas palavras, a missão foi cumprida por 1) usando técnicas de replicação para validar a exatidão do novo Binance Ledger 2) implementando uma estratégia de migração conta por conta para atualizar o mecanismo de forma lenta, mas segura.
Acreditamos que o paradigma de migração on-line acima mencionado pode ser reutilizado em tarefas semelhantes. Se os processos e tópicos discutidos despertaram seu interesse, por que não considerar entrar para a equipe? Estamos sempre procurando pessoas dedicadas com novas perspectivas sobre nossos desafios diários na Binance.