Migrando os dados de razão contábil da Uber do DynamoDB para o LedgerStore

• Na semana passada, a Uber explorou o LedgerStore (LSG), um banco de dados no estilo ledger somente para acréscimo.
• Nesta semana, o foco é em como a Uber migrou dados de razão contábil críticos para o negócio para o LSG.
• O texto discute como mais de 1 trilhão de itens (vários petabytes de dados) foram movidos de forma transparente, sem interrupções, e o que foi aprendido no processo.

Histórico

• O Gulfstream é a plataforma de pagamentos da Uber e foi lançado em 2017 usando o DynamoDB.
• Na escala da Uber, o DynamoDB ficou caro; por isso, eles passaram a manter apenas 12 semanas de dados (dados quentes) no DynamoDB, enquanto os dados mais antigos (dados frios) eram armazenados no TerraBlob, o blobstore da Uber.
• A solução de longo prazo era usar o LSG. O LSG foi projetado sob medida para armazenar dados no estilo de pagamentos.
• Principais recursos do LSG:
  • Imutabilidade verificável (é possível confirmar com assinaturas criptográficas que os registros não foram alterados)
  • Armazenamento em camadas para gerenciamento de custos (dados quentes ficam onde é melhor para atender requisições, e dados frios onde o armazenamento é mais otimizado)
  • Melhoria na latência de índices secundários eventualmente consistentes
• Até 2021, o Gulfstream armazenava dados usando uma combinação de DynamoDB, TerraBlob e LSG.
  • DynamoDB: dados das 12 semanas mais recentes
  • TerraBlob: dados frios
  • LSG: onde os dados eram gravados e o destino da migração

Por que era necessário migrar?

• O LSG é mais adequado para armazenar dados no estilo ledger por causa da imutabilidade.
• A mudança para o LSG trouxe economias recorrentes significativas.
• Passar de três armazenamentos para um simplificaria o código e o design do serviço Gulfstream.
• O LSG prometia menor latência de indexação e, por rodar on-premises dentro dos data centers da Uber, também oferecia menor latência de rede.

Riscos relacionados à natureza dos dados

• Os dados migrados eram todos os dados de razão contábil de negócios da Uber desde 2017:
  • Registros imutáveis: 1,2 PB em tamanho comprimido
  • Índices secundários: 0,5 PB em tamanho não comprimido
• Os registros imutáveis não podem ser modificados, enquanto os dados de índices secundários têm flexibilidade para serem alterados a fim de corrigir problemas.

Validação

• Para garantir que o backfill estava correto e aceitável em todos os aspectos, era necessário verificar se o sistema conseguia lidar com o tráfego atual e se os dados que não eram acessados no momento também estavam corretos.
• Critérios de validação:
  • Completude: se todos os registros foram preenchidos no backfill
  • Exatidão: se todos os registros estavam corretos
  • Carga: se o LSG conseguia lidar com a carga atual
  • Latência: se a latência P99 do LSG estava dentro de uma faixa aceitável
  • Atraso: se a latência de geração de índices secundários estava dentro de uma faixa aceitável

Validação shadow

• As respostas antes e depois da migração foram comparadas para garantir que o tráfego atual não fosse afetado por problemas na migração dos dados ou por bugs no código.
• Com a validação shadow, a equipe confirmou que o backfill era pelo menos 99,99% completo e correto, definindo um limite superior de 99,9999%.
• A validação shadow também confirmou que o LSG conseguia lidar com o tráfego de produção e trouxe confiança ao código de acesso aos dados.
• Ela também trouxe confiança na completude e na exatidão dos dados que estavam sendo acessados naquele momento.

Validação offline e backfill incremental

• Todos os dados do LSG foram comparados com um dump de dados do DynamoDB.
• A validação offline confirmou que o backfill foi realizado corretamente e cobriu o conjunto completo de dados.
• A validação offline precisava ser realizada em conjunto com a validação shadow.

Problemas de backfill

• Todo backfill envolve riscos. A Uber usou o Apache Spark para executar o backfill.
• Como os problemas foram tratados:
  • Escalabilidade: começar em pequena escala e expandir gradualmente
  • Backfill incremental: dividir os dados em pequenos lotes para preenchimento
  • Controle de velocidade: ajustar a taxa dos jobs de backfill
  • Controle dinâmico de velocidade: ajustar a taxa monitorando o estado atual do sistema
  • Parada de emergência: oferecer a capacidade de interromper rapidamente o backfill em caso de suspeita de sobrecarga
  • Tamanho dos arquivos de dados: manter o tamanho dos arquivos de dump em um nível adequado
  • Tolerância a falhas: lidar com problemas de qualidade/corrupção de dados
  • Logging: limitar logs para não sobrecarregar a infraestrutura de logging

Mitigação de risco

• A equipe analisou vários dados estatísticos de validação e backfill e fez o rollout do LSG de forma conservadora.
• No início, foi usado um fallback para buscar dados do DynamoDB caso o backfill falhasse.
• Os logs de fallback foram verificados para confirmar que os dados não estavam realmente faltando no LSG.

Conclusão

• Este artigo abordou o processo de migrar dados de razão contábil críticos para o negócio, em larga escala, de um armazenamento de dados para outro.
• Foram tratados vários aspectos, como critérios de migração, validação, problemas de backfill e segurança operacional.
• A migração foi concluída ao longo de dois anos, sem interrupções nem incidentes.

Opinião do GN⁺

• Importância da migração de dados: migrações de dados em larga escala são complexas e arriscadas, mas oferecem grandes benefícios no longo prazo por meio de redução de custos e simplificação do sistema.
• Utilidade da validação shadow: a validação shadow é uma ferramenta poderosa para verificar a completude e a exatidão dos dados sem afetar o tráfego real.
• Necessidade da validação offline: a validação offline também é essencial, pois pode encontrar problemas que a validação shadow sozinha não revela.
• Abordagem gradual para backfill: executar o backfill em etapas, dividido em pequenos lotes, é eficaz para evitar sobrecarga do sistema.
• Função de parada de emergência: a capacidade de interromper rapidamente o backfill quando ocorre um problema é importante para manter a estabilidade do sistema.

[GN⁺]

Comentários do Hacker News

Resumo dos comentários do Hacker News

• 2 bilhões de corridas por trimestre

  • A Uber processa 2 bilhões de corridas por trimestre. Isso pode ser convertido em cerca de 1.000 transações por segundo. É difícil entender por que há tanta preocupação com escalar a infraestrutura.

• Usando o DynamoDB de forma inadequada

  • A Uber estava usando o DynamoDB de forma inadequada. Algumas jornadas críticas do usuário (CUJ) exigem consistência forte, e é necessário data warehousing para transações históricas. É estranho que não tenham migrado para uma arquitetura com DynamoDB e Redshift.

• Google rejeita

  • Parece que a Uber pegou um projeto que fracassou no Google. Esse tipo de projeto normalmente mira uma grande promoção. Algo como: "Projetei e construí nosso próprio sistema e economizei $Xm! Me promovam!". Mas o custo de construção acaba sendo maior, e há uma boa chance de ser descartado alguns anos depois.

• SQLite em um único servidor

  • Fico me perguntando se seria possível armazenar 1,7 petabytes de dados (1 trilhão de registros indexados) em SQLite em um único servidor bare metal de alto desempenho. Um link de exemplo foi fornecido.

• LedgerStore não é open source

  • O LedgerStore não é open source. Para encontrar informações relacionadas, é preciso seguir as postagens do blog da Uber. Foi fornecido um link para uma postagem de 2021.

• Era da infraestrutura customizada

  • Por volta de 2015, muitas empresas de tecnologia como Netflix, Spotify, SoundCloud e Uber construíram bastante infraestrutura e ferramentas de banco de dados. Hoje em dia, muitos engenheiros falam em termos de AWS/cloud. Ainda é revigorante ver organizações que continuam construindo suas próprias ferramentas.

• Nuvem proprietária cara

  • Este é um bom exemplo de como um armazenamento de dados baseado em nuvem proprietária pode ser caro. Migrar para outra coisa é possível.

• Consideraram o TigerBeetle?

  • Fico curioso se consideraram o TigerBeetle.

• DynamoDB é caro

  • Não sei qual é a viabilidade econômica deste projeto, mas o DynamoDB é realmente caro. Eu achava que outras pessoas estavam usando errado, mas mesmo quando usado como uma tabela hash distribuída ele ainda custa muito.

• Custo de manter a equipe

  • O custo de manter a equipe do projeto provavelmente não deve ser muito diferente da economia obtida (US$ 6 milhões). Os custos de manutenção também se somam. Sistemas de pagamento talvez não sejam uma aposta de longo prazo. É interessante entender por que projetos assim seguem adiante. Também pode haver custo afundado relacionado à equipe de engenharia já existente.