Migration des données de registre d’Uber de DynamoDB vers LedgerStore

• La semaine dernière, Uber a exploré LedgerStore (LSG), sa base de données supplémentaire dédiée au modèle de registre.
• Cette semaine, l’entreprise explique comment elle a migré vers LSG des données de registre critiques pour son activité.
• L’article présente la manière dont plus de 1 billion d’entrées (plusieurs pétaoctets de données) ont été déplacées de manière transparente, sans interruption, ainsi que les enseignements tirés du processus.

Historique

• Gulfstream est la plateforme de paiements d’Uber, lancée en 2017 en s’appuyant sur DynamoDB.
• À l’échelle d’Uber, DynamoDB est devenu coûteux ; l’entreprise a donc commencé à n’y conserver que 12 semaines de données (données chaudes), tandis que les données plus anciennes (données froides) étaient stockées dans TerraBlob, le blobstore d’Uber.
• À long terme, l’objectif était d’utiliser LSG. LSG a été conçu spécifiquement pour stocker des données de type paiements.
• Principales fonctionnalités de LSG :
  • immutabilité vérifiable (il est possible de confirmer qu’un enregistrement n’a pas été modifié grâce à des signatures cryptographiques)
  • stockage hiérarchisé pour mieux gérer les coûts (les données chaudes sont placées là où elles répondent efficacement aux requêtes, les données froides là où le stockage est optimisé)
  • amélioration de la latence des index secondaires à cohérence éventuelle
• En 2021, Gulfstream stockait ses données via une combinaison de DynamoDB, TerraBlob et LSG.
  • DynamoDB : les 12 semaines de données les plus récentes
  • TerraBlob : les données froides
  • LSG : l’endroit où les données étaient écrites et la destination visée pour la migration

Pourquoi fallait-il migrer ?

• LSG est mieux adapté au stockage de données de type registre grâce à son immutabilité.
• Le passage à LSG a permis d’importantes économies récurrentes.
• Passer de trois stockages à un seul permet de simplifier le code et l’architecture du service Gulfstream.
• LSG promettait une latence d’indexation plus faible et, comme il fonctionne on-premise dans les data centers d’Uber, il offrait également une latence réseau plus basse.

Risques liés à la nature des données

• Les données migrées correspondent à l’ensemble des données de registre métier d’Uber depuis 2017 :
  • enregistrements immuables : 1,2 PB compressé
  • index secondaires : 0,5 PB non compressé
• Les enregistrements immuables ne peuvent pas être modifiés, tandis que les données des index secondaires offrent la flexibilité nécessaire pour corriger d’éventuels problèmes.

Validation

• Pour vérifier que le backfill est correct et acceptable à tous les niveaux, il fallait s’assurer à la fois que le système pouvait absorber le trafic actuel et que les données non consultées actuellement étaient elles aussi correctes.
• Critères de validation :
  • exhaustivité : tous les enregistrements ont-ils été backfillés ?
  • exactitude : tous les enregistrements sont-ils corrects ?
  • charge : LSG peut-il supporter la charge actuelle ?
  • latence : la latence P99 de LSG reste-t-elle dans une plage acceptable ?
  • délai : le délai de création des index secondaires reste-t-il dans une plage acceptable ?

Validation shadow

• Les réponses avant et après migration sont comparées afin de s’assurer que le trafic actuel n’est pas perturbé par des problèmes de migration de données ou des bugs dans le code.
• La validation shadow a permis de vérifier que le backfill était complet et exact à au moins 99,99 %, avec une borne supérieure fixée à 99,9999 %.
• Elle a aussi permis de confirmer que LSG pouvait gérer le trafic de production et d’apporter de la confiance dans le code d’accès aux données.
• Elle donne également confiance dans l’exhaustivité et l’exactitude des données actuellement consultées.

Validation hors ligne et backfill incrémental

• L’ensemble des données de LSG a été comparé à un dump des données de DynamoDB.
• La validation hors ligne permet de vérifier que le backfill a été correctement exécuté et couvre l’intégralité des données.
• Elle doit être menée en parallèle de la validation shadow.

Problèmes liés au backfill

• Tout backfill comporte des risques. Uber a utilisé Apache Spark pour effectuer ce backfill.
• Méthodes de résolution :
  • scalabilité : commencer à petite échelle puis monter progressivement en charge
  • backfill incrémental : découper les données en petits lots
  • contrôle du débit : ajuster la vitesse des jobs de backfill
  • contrôle dynamique du débit : ajuster la vitesse selon l’état actuel du système
  • arrêt d’urgence : pouvoir interrompre rapidement le backfill en cas de suspicion de surcharge
  • taille des fichiers de données : conserver une taille appropriée pour les fichiers de dump
  • tolérance aux pannes : gérer les problèmes de qualité ou de corruption des données
  • journalisation : limiter les logs pour ne pas surcharger l’infrastructure de logging

Réduction des risques

• Uber a analysé différentes données de validation et statistiques de backfill, puis a déployé LSG avec prudence.
• Au départ, un fallback permettait encore de récupérer les données depuis DynamoDB en cas d’échec du backfill.
• Les logs de fallback ont été vérifiés pour s’assurer qu’aucune donnée ne manquait réellement dans LSG.

Conclusion

• Cet article décrit la migration, à grande échelle, de données de registre critiques pour l’activité d’un entrepôt de données vers un autre.
• Il couvre différents aspects, notamment les critères de migration, la validation, les défis du backfill et la sécurité opérationnelle.
• La migration a été menée à bien sur deux ans, sans interruption ni incident.

L’avis de GN⁺

• L’importance de la migration de données : les migrations de données à grande échelle sont complexes et risquées, mais elles apportent de gros bénéfices à long terme grâce aux économies de coûts et à la simplification des systèmes.
• L’utilité de la validation shadow : la validation shadow est un outil puissant pour vérifier l’exhaustivité et l’exactitude des données sans impacter le trafic réel.
• La nécessité de la validation hors ligne : elle reste indispensable, car elle peut révéler des problèmes que la seule validation shadow ne permet pas de voir.
• L’approche progressive du backfill : exécuter le backfill par petits lots et de manière progressive est efficace pour éviter la surcharge du système.
• La fonction d’arrêt d’urgence : la capacité à stopper rapidement un backfill en cas de problème est essentielle pour préserver la stabilité du système.

[GN⁺]

Commentaires Hacker News

Résumé des commentaires de Hacker News

• 2 billion rides per quarter

  • Uber traite 2 milliards de trajets par trimestre. Cela peut se convertir en environ 1 000 transactions par seconde. Il est difficile de comprendre pourquoi ils se préoccupent autant de la montée en charge de l’infrastructure.

• Using DynamoDB poorly

  • Uber utilisait mal DynamoDB. Certains parcours utilisateurs critiques (CUJ) nécessitent une forte cohérence, et un entrepôt de données est nécessaire pour les transactions historiques. Il est étrange qu’ils n’aient pas basculé vers une architecture DynamoDB et Redshift.

• Google rejects

  • On dirait qu’Uber a récupéré un projet abandonné par Google. Ce genre de projet vise souvent une grosse promotion. Du style : "J’ai conçu et construit notre propre système, ce qui a permis d’économiser X millions de dollars ! Faites-moi monter en grade !" Mais le coût de construction est plus élevé, et il y a de fortes chances qu’il soit abandonné quelques années plus tard.

• SQLite on a single server

  • Quelqu’un se demande s’il serait possible de stocker 1,7 pétaoctet de données (1 billion d’enregistrements indexés) avec SQLite sur un seul serveur bare metal hautes performances. Un lien d’exemple est fourni.

• LedgerStore not open source

  • LedgerStore n’est pas open source. Pour trouver des informations à son sujet, il faut remonter aux billets de blog d’Uber. Un lien vers un article de 2021 est fourni.

• Era of custom infrastructure

  • Vers 2015, de nombreuses entreprises tech comme Netflix, Spotify, SoundCloud et Uber construisaient beaucoup d’outils d’infrastructure et de base de données. Aujourd’hui, beaucoup d’ingénieurs parlent surtout en termes AWS/cloud. C’est encore rafraîchissant de voir des organisations qui continuent à construire leurs propres outils.

• Expensive proprietary cloud

  • C’est un bon exemple de ce que peut coûter très cher un stockage de données propriétaire basé sur le cloud. Migrer vers autre chose reste possible.

• Considered TigerBeetle?

  • Quelqu’un se demande s’ils ont envisagé TigerBeetle.

• DynamoDB is expensive

  • On ne sait pas si ce projet est rentable, mais DynamoDB coûte vraiment cher. Certains pensaient que d’autres l’utilisaient mal, mais même en s’en servant comme table de hachage distribuée, le coût reste élevé.

• Cost of running the team

  • Le coût de fonctionnement de l’équipe projet ne semble pas très différent des économies annoncées (6 millions de dollars). Il faut aussi ajouter les coûts de maintenance. Il est peu probable qu’un système de paiement soit un pari de long terme. C’est intéressant de se demander pourquoi lancer un tel projet. Il peut aussi y avoir un coût irrécupérable lié à une équipe d’ingénierie déjà en place.