Migración de los datos de ledger de Uber de DynamoDB a LedgerStore

• La semana pasada se exploró LedgerStore (LSG), la base de datos adicional de estilo ledger desarrollada internamente por Uber.
• Esta semana se aborda cómo Uber migró a LSG los datos de ledger críticos para su negocio.
• Se analiza cómo movieron de forma transparente más de 1 billón de elementos (varios petabytes de datos) sin interrupciones y qué aprendizajes obtuvieron en el proceso.

Historia

• Gulfstream es la plataforma de pagos de Uber y se lanzó en 2017 usando DynamoDB.
• A la escala de Uber, DynamoDB se volvió costoso, por lo que comenzaron a mantener solo 12 semanas de datos (datos calientes) en DynamoDB y a almacenar los datos antiguos (datos fríos) en TerraBlob, el blobstore de Uber.
• Como solución de largo plazo, querían usar LSG. LSG fue diseñado específicamente para almacenar datos de estilo pagos.
• Funciones principales de LSG:
  • Inmutabilidad verificable (se puede confirmar con firmas criptográficas que los registros no han sido modificados)
  • Almacenamiento por niveles para controlar costos (los datos calientes se guardan donde conviene atender solicitudes, y los datos fríos donde conviene optimizar el almacenamiento)
  • Mejora en la latencia de los índices secundarios eventualmente consistentes
• Hasta 2021, Gulfstream almacenaba datos usando una combinación de DynamoDB, TerraBlob y LSG.
  • DynamoDB: datos de las últimas 12 semanas
  • TerraBlob: datos fríos
  • LSG: destino donde registrar y migrar los datos

¿Por qué había que migrar?

• LSG era más adecuado para almacenar datos de estilo ledger debido a su inmutabilidad.
• Al moverse a LSG, el ahorro recurrente de costos fue considerable.
• Pasar de tres almacenamientos a uno solo permitía simplificar el código y el diseño del servicio Gulfstream.
• LSG prometía menor latencia de indexación y, al ejecutarse on-premise dentro de los centros de datos de Uber, también ofrecía menor latencia de red.

Riesgos relacionados con la naturaleza de los datos

• Los datos migrados corresponden a todos los datos de ledger del negocio de Uber desde 2017:
  • Registros inmutables: 1.2 PB comprimidos
  • Índices secundarios: 0.5 PB sin comprimir
• Los registros inmutables no pueden modificarse, mientras que los datos de los índices secundarios sí tienen cierta flexibilidad para corregir problemas.

Validación

• Para confirmar que el backfill era correcto y aceptable en todos los aspectos, había que verificar tanto si podía manejar el tráfico actual como si los datos que actualmente no se accedían eran correctos.
• Criterios de validación:
  • Completitud: si todos los registros fueron cargados en el backfill
  • Exactitud: si todos los registros son correctos
  • Carga: si LSG puede manejar la carga actual
  • Latencia: si la latencia P99 de LSG está dentro del rango aceptable
  • Retraso: si el retraso en la creación de índices secundarios está dentro del rango aceptable

Validación shadow

• Se compararon las respuestas antes y después de la migración para asegurar que el tráfico actual no se viera afectado por problemas de migración de datos ni por bugs en el código.
• Mediante validación shadow verificaron que el backfill era al menos 99.99% completo y correcto, y fijaron el límite superior en 99.9999%.
• La validación shadow permitió confirmar que LSG podía manejar tráfico de producción y dio confianza en el código de acceso a datos.
• La validación shadow también dio confianza sobre la completitud y exactitud de los datos a los que se estaba accediendo en ese momento.

Validación offline y backfill incremental

• Se compararon todos los datos de LSG con un volcado de datos de DynamoDB.
• La validación offline permitió verificar que el backfill de datos se hubiera realizado correctamente y cubrió el conjunto completo de datos.
• La validación offline debía realizarse junto con la validación shadow.

Problemas del backfill

• Todo backfill implica riesgos. Uber realizó el backfill usando Apache Spark.
• Formas de resolver los problemas:
  • Escalabilidad: comenzar a pequeña escala y ampliar gradualmente.
  • Backfill incremental: dividir los datos en lotes pequeños para cargarlos.
  • Control de velocidad: ajustar la velocidad del trabajo de backfill.
  • Control dinámico de velocidad: ajustar la velocidad monitoreando el estado actual del sistema.
  • Parada de emergencia: ofrecer la capacidad de detener rápidamente el backfill si se sospecha una sobrecarga.
  • Tamaño de archivos de datos: mantener en un rango adecuado el tamaño de los archivos del volcado de datos.
  • Tolerancia a fallos: manejar problemas de calidad o corrupción de datos.
  • Logging: limitar los logs para no sobrecargar la infraestructura de registro.

Mitigación de riesgos

• Se analizaron diversos datos de validación y estadísticas del backfill, y el rollout de LSG se realizó de forma conservadora.
• Al principio se usó un fallback para obtener datos desde DynamoDB si el backfill fallaba.
• También se revisaron los logs del fallback para confirmar que realmente no faltaban datos en LSG.

Conclusión

• Este artículo trata sobre el proceso de migrar datos de ledger críticos para el negocio y a gran escala de un almacenamiento de datos a otro.
• Cubre varios aspectos, incluidos los criterios de migración, la validación, los problemas del backfill y la seguridad.
• La migración se completó durante 2 años sin interrupciones ni incidentes.

Opinión de GN⁺

• Importancia de la migración de datos: las migraciones de datos a gran escala son complejas y conllevan riesgos, pero ofrecen grandes beneficios a largo plazo mediante ahorro de costos y simplificación del sistema.
• Utilidad de la validación shadow: la validación shadow es una herramienta poderosa para comprobar la completitud y exactitud de los datos sin afectar el tráfico real.
• Necesidad de la validación offline: la validación offline también es esencial porque puede descubrir problemas que no aparecen solo con la validación shadow.
• Enfoque gradual del backfill: dividir el backfill en lotes pequeños y ejecutarlo gradualmente es efectivo para evitar la sobrecarga del sistema.
• Función de parada de emergencia: contar con una capacidad para detener rápidamente el backfill cuando surge un problema es importante para mantener la estabilidad del sistema.

[GN⁺]

Opinión de Hacker News

Resumen de comentarios de Hacker News

• 2 mil millones de viajes por trimestre

  • Uber procesa 2 mil millones de viajes por trimestre. Eso podría equivaler a unas 1000 transacciones por segundo. Cuesta entender por qué ponen tanto énfasis en escalar la infraestructura.

• Uso deficiente de DynamoDB

  • Uber estaba usando DynamoDB de forma deficiente. Ciertos recorridos críticos del usuario (CUJ) requieren consistencia fuerte y se necesita almacenamiento histórico para transacciones pasadas. Resulta extraño que no hayan migrado a una arquitectura de DynamoDB y Redshift.

• Google rechaza

  • Parece que Uber tomó un proyecto que fracasó en Google. Este tipo de proyectos normalmente apunta a un gran ascenso. Algo como: "¡Diseñé y construí un sistema propio y ahorré $Xm! ¡Asciéndanme!". Pero cuesta más construirlo y es muy probable que termine descartado unos años después.

• SQLite en un solo servidor

  • Se preguntan si 1.7 petabytes de datos (1 billón de registros indexados) podrían almacenarse en SQLite sobre un solo servidor bare metal de alto rendimiento. Se proporciona un enlace de ejemplo.

• LedgerStore no es open source

  • LedgerStore no es open source. Para encontrar información relacionada, hay que seguir una publicación del blog de Uber. Se proporciona un enlace a una publicación de 2021.

• La era de la infraestructura personalizada

  • Alrededor de 2015, muchas empresas tecnológicas como Netflix, Spotify, SoundCloud y Uber construían mucha infraestructura y herramientas de base de datos. Hoy en día hay muchos ingenieros que hablan en términos de AWS/cloud. Sigue siendo refrescante ver organizaciones que todavía construyen sus propias herramientas.

• Cloud propietario costoso

  • Este es un buen ejemplo de lo caro que puede ser un almacén de datos basado en cloud propietario. Sí es posible migrar a otra cosa.

• ¿Consideraron TigerBeetle?

  • Se preguntan si consideraron TigerBeetle.

• DynamoDB es caro

  • No está clara la viabilidad económica de este proyecto, pero DynamoDB es realmente caro. Pensaban que otras personas lo estaban usando mal, pero incluso al usarlo como tabla hash distribuida sigue costando mucho.

• Costo de operar el equipo

  • Parece que el costo de operar el equipo del proyecto no sería muy distinto del ahorro reportado (6 millones de dólares). Además, se suman los costos de mantenimiento. Es posible que un sistema de pagos no sea una apuesta de largo plazo. Resulta interesante por qué emprenden proyectos como este. También podría tratarse de costos hundidos relacionados con un equipo de ingeniería ya existente.