Uber migre 1 000 milliards d'enregistrements de la base de données NoSQL cloud AWS DynamoDB vers LedgerStore, un magasin de données, pour économiser 6 millions de dollars par an

Le 21 mai 2024 à 13:10, par Jade Emy

134PARTAGES

Uber a migré toutes ses données de transactions de paiement de DynamoDB et du stockage blob vers une nouvelle solution à long terme, un magasin de données spécialement conçu à cet effet, appelé LedgerStore.

Uber Technologies, Inc, communément appelé Uber, est une société multinationale américaine de transport qui propose des services de covoiturage, de messagerie, de livraison de nourriture et de transport de marchandises. Elle a son siège à San Francisco, en Californie, et opère dans environ 70 pays et 10 500 villes dans le monde. C'est la plus grande société de covoiturage au monde, avec plus de 150 millions d'utilisateurs actifs mensuels et 6 millions de chauffeurs et de coursiers en activité. Elle facilite en moyenne 28 millions de trajets par jour et a facilité 47 milliards de trajets depuis sa création en 2010.

Amazon DynamoDB est une base de données NoSQL propriétaire entièrement gérée proposée par Amazon.com dans le cadre du portefeuille Amazon Web Services. DynamoDB offre un datastore clé-valeur persistant et rapide avec une prise en charge intégrée de la réplication, de l'autoscaling, du cryptage au repos et de la sauvegarde à la demande, entre autres fonctionnalités.

Uber migre 1 000 milliards d'enregistrements de DynamoDB vers LedgerStore pour économiser 6 millions de dollars par an. L'entreprise cherchait à réaliser des économies et avait précédemment réduit l'utilisation de DynamoDB pour stocker les données chaudes (datant de 12 semaines). Ce changement a permis de réaliser d'importantes économies et de simplifier l'architecture de stockage.

Uber a construit Gulfstream, sa plateforme de paiement, en 2017 et a utilisé DynamoDB pour le stockage. En raison de l'augmentation des coûts de stockage, DynamoDB n'a été utilisé que pour les données les plus récentes (12 semaines), et les données plus anciennes ont été stockées dans TerraBlob, un service de type S3 créé en interne par Uber.

Entre-temps, l'entreprise a commencé à travailler sur une solution dédiée au stockage des transactions financières avec des garanties d'intégrité des données. Avec LedgerStore, Uber possède maintenant un magasin de données sur mesure. LedgerStore est une solution de stockage immuable d'Uber qui fournit des garanties vérifiables sur l'exhaustivité et l'exactitude des données afin d'assurer l'intégrité des données pour ces transactions.

Migration de 1 000 milliards d'enregistrements du grand livre d'Uber de DynamoDB vers LedgerStore

Après avoir exploré LedgerStore (LSG), sa base de données de type grand livre, Uber annonce qu'ils vont voir comment migré les données critiques du grand livre d'Uber vers LSG. Voici des détails sur comment ils ont déplacé plus de mille milliards d'entrées (ce qui représente quelques pétaoctets de données) de manière transparente et sans perturbation.

Historique

Gulfstream est la plateforme de paiement d'Uber. Elle a été lancée en 2017 en utilisant DynamoDB pour le stockage. À l'échelle d'Uber, DynamoDB est devenu coûteux. Ils ont donc commencé à ne conserver que 12 semaines de données (c'est-à-dire les données chaudes) dans DynamoDB et à utiliser le blobstore d'Uber, TerraBlob, pour les données plus anciennes (c'est-à-dire les données froides). TerraBlob est similaire à AWS S3.

Pour une solution à long terme, Uber souhaite utiliser LSG. Il a été conçu pour stocker des données de type paiement. Ses principales caractéristiques sont les suivantes :

Il est vérifiable et immuable (c'est-à-dire que vous pouvez vérifier que les enregistrements n'ont pas été modifiés à l'aide de signatures cryptographiques).
Stockage hiérarchisé pour gérer les coûts (les données chaudes sont conservées à l'endroit le plus approprié pour répondre aux demandes et les données froides sont stockées à un endroit optimisé pour le stockage).
un meilleur décalage pour obtenir des index secondaires cohérents.

En 2021, Gulfstream utilisait donc une combinaison de DynamoDB, TerraBlob et LSG pour stocker ses données.

DynamoDB pour les 12 dernières semaines de données
TerraBlob, le blob store interne d'Uber, pour les données froides
LSG, où ils écrivent des données et vers lequel ils veulent migrer.

Pourquoi migrer ?

Uber répond à la question en déclarant :

LSG est mieux adapté au stockage de données de type grand livre en raison de son immuabilité. La migration vers LSG a permis de réaliser d'importantes économies sur les coûts récurrents.

Le passage de trois à un seul système de stockage simplifierait le code et la conception des services Gulfstream chargés d'interagir avec le stockage et de créer des index. Cela facilite la compréhension et la maintenance des services.

LSG promettait un délai d'indexation plus court (c'est-à-dire le temps qui s'écoule entre l'écriture d'un enregistrement et la création de son index secondaire). En outre, il nous offrirait une latence réseau plus rapide car il fonctionnait sur site dans les centres de données d'Uber.

Nature des données et risques associés

Les données qu'Uber a migrées sont toutes les données du grand livre d'Uber pour l'ensemble des activités d'Uber depuis 2017 :

Enregistrements immuables - 1,2 Po de taille compressée
Index secondaires - 0,5 Po de taille non compressée.

Les enregistrements immuables ne doivent pas être modifiés. Ainsi, à toutes fins pratiques, une fois qu'un enregistrement a été écrit, il ne peut pas être modifié. Mais il est possible de modifier les données de l'index secondaire pour corriger des problèmes.

Contrôles

Pour s'assurer que le remblayage est correct et acceptable à tous égards, ils ont du vérifier que le trafic actuel pouvait être gérer et que les données qui ne sont pas consultées actuellement sont correctes. Les critères utilisés à cet effet sont les suivants

Exhaustivité : Tous les enregistrements ont été remplis.
Exactitude : Tous les enregistrements sont corrects.
Charge : LSG doit être en mesure de gérer la charge actuelle.
Latence : La latence P99 du LSG se situe dans des limites acceptables.
Retard : Les index secondaires sont créés en arrière-plan. Nous voulons nous assurer que le délai du processus de création d'index se situe dans des limites acceptables.

Les contrôles ont été effectués à l'aide d'une combinaison de validation fantôme et de validation hors ligne.

Validation fantôme

Cette validation compare la réponse obtenue avant la migration avec celle obtenue avec le LSG comme source de données. Cela permet de s'assurer que le trafic actuel ne sera pas perturbé par des problèmes de migration de données ou des bogues de code.

Uber :

Nous voulions que notre backfill soit au moins 99,99 % complet et correct, comme mesuré par la validation fantôme. Nous avions également une limite supérieure de 99,9999 %.

Les raisons de cette limite supérieure sont les suivantes :

Lors de la migration de données historiques, il y a toujours des problèmes de corruption de données. Parfois, cela est dû au fait que les données n'ont pas été écrites correctement pendant la période initiale de développement du service. Il est également possible que la corruption des données soit due à l'échelle. Par exemple, si S3 offre une garantie de durabilité de 11 neuf, on peut s'attendre à 10 corruptions sur 1 000 milliards d'enregistrements.
Les index sont éventuellement cohérents, ce qui signifie que certains enregistrements apparaîtront après quelques secondes. La validation fantôme les signalera donc comme manquants. Il s'agit d'un faux positif qui apparaît à grande échelle.
Pour 6 neuf, vous devez examiner des données de 100 millions de comparaisons pour obtenir des résultats fiables. Cela signifie que si votre validation fantôme compare 1 000 enregistrements par seconde, vous devez attendre un peu plus d'une journée pour collecter suffisamment de données. Avec 7 neuf, vous devrez attendre 12 jours. Concrètement, cela ralentirait le projet.
Avec une limite supérieure bien définie, vous n'êtes pas obligé d'examiner tous les problèmes potentiels que vous soupçonnez. Par exemple, si l'occurrence d'un problème est égale à 1/10 de la limite supérieure, il n'est même pas nécessaire de l'examiner.
Avec 6 neuf, nous pourrions nous retrouver avec un peu plus d'un million d'enregistrements corrompus. Même si la confirmation d'une exactitude de 6 neuf pourrait représenter un coût réel pour l'entreprise, les économies générées par ce projet l'ont emporté sur le coût potentiel.

Pendant la validation fantôme, vous reproduisez essentiellement le trafic de production sur LSG. Ainsi, en surveillant LSG, nous pouvons vérifier qu'il peut gérer notre trafic de production tout en respectant nos exigences en matière de latence et de décalage. Cela nous donne une bonne confiance dans le code que nous avons écrit pour accéder aux données de LSG. En outre, cela nous permet de nous assurer de l'exhaustivité et de l'exactitude des données, en particulier des données en cours d'accès. Nous avons développé un code de validation générique unique qui a été réutilisé plusieurs fois pour différentes parties de la migration.

Au cours du processus de migration, Uber a constaté des problèmes de latence et de décalage dus à de multiples bogues dans différentes parties et ils les ont corrigés.

Optimisation des clés de partition pour une meilleure distribution des données d'index.
Problèmes d'indexation entraînant un balayage de l'enregistrement au lieu d'une recherche par point.

Malheureusement, la validation en temps réel ne peut pas donner de garanties solides sur le corpus de données historiques rarement accessibles.

Validation hors ligne et remplissage incrémentiel

Cette méthode permet de comparer les données complètes du LSG avec le vidage de données de DynamoDB. En raison de divers problèmes liés aux données, vous devez ignorer les mauvais enregistrements pour vous assurer que votre remplissage peut se faire. En outre, il peut y avoir des bogues dans le travail de remplissage lui-même. La validation hors ligne permet de s'assurer que le remplissage des données s'est déroulé correctement et qu'il couvre des données complètes. Elle doit être effectuée en plus de la validation fantôme, car le trafic en direct a tendance à n'accéder qu'aux données récentes. Par conséquent, si des problèmes se cachent dans les données froides auxquelles on accède rarement, ils ne seront pas détectés par la validation fantôme.

Le principal défi de la validation hors ligne est la taille des données. Les données les plus volumineuses traitées représentaient 70 To compressés (environ 300 To non compressés) et Uber a comparé 760 milliards d'enregistrements en une seule tâche. Ce type de tâche Apache SparkTM nécessite un brassage des données et Distributed Shuffle as a Service for Spark, combiné à l'allocation dynamique des ressources et à l'exécution spéculative, a permis de le faire à une vitesse raisonnable en dépit des contraintes de ressources.

La validation hors ligne a permis de trouver les enregistrements manquants et son résultat a été utilisé pour le remplissage incrémental.Uber a itéré entre la validation hors ligne et le remplissage pour s'assurer que tous les enregistrements étaient écrits.

Problèmes liés au backfill

Tout backfill (est risqué. Ils ont utilisé l'offre interne d'Uber, Apache Spark, pour les backfills. Voici les différents problèmes rencontrés et comment ils les ont gérés.

Évolutivité

Vous voulez commencer à une petite échelle et augmenter progressivement jusqu'à ce que vous atteigniez la limite du système. Si vous dépassez aveuglément cette limite, vous créez une attaque DDoS sur vos propres systèmes. À ce stade, vous devez trouver le goulot d'étranglement, y remédier, puis augmenter votre travail. La plupart du temps, il s'agit simplement d'augmenter les services en aval, mais il peut aussi s'agir de quelque chose de plus complexe. Dans tous les cas, vous ne devez pas faire évoluer votre tâche de remplissage au-delà de la capacité du goulot d'étranglement du système. Il est conseillé de procéder à une mise à l'échelle par petits incréments et d'effectuer une surveillance étroite après chaque mise à l'échelle.

Remplissages progressifs

Lorsque vous essayez de recharger 3 ans de données en l'espace de 3 mois, vous générez un trafic 10 fois supérieur à la charge normale et le système peut ne pas être en mesure de faire face à ce trafic. À titre d'exemple, il vous faudra 120 jours pour remplir 100 milliards d'enregistrements à un taux de 10K/sec alors que votre production gère normalement un taux de 1K/sec. Vous pouvez donc vous attendre à ce que le système soit surchargé. S'il y a la moindre chance que le travail de remplissage cause un problème permanent, vous devez l'arrêter. Il n'est donc pas réaliste de s'attendre à ce qu'une tâche de backfill puisse être exécutée du début à la fin en une seule fois, et vous devez donc exécuter les backfills de manière incrémentielle.

Une méthode simple et efficace consiste à diviser le backfill en petits lots qui peuvent être exécutés un par un, de sorte que chaque lot puisse être terminé en quelques minutes. Étant donné que votre travail peut s'arrêter au milieu d'un lot, il doit être idempotent. Chaque fois que vous terminez un lot, vous souhaitez transférer les statistiques (telles que les enregistrements lus, les enregistrements remplis, etc. ) dans un fichier. Au fur et à mesure que vous remplissez le fichier, vous pouvez agréger les chiffres pour vérifier l'état d'avancement.

Si vous pouvez supprimer ou mettre à jour les enregistrements existants, vous réduisez le risque et le coût des erreurs et des bogues de code pendant le remplissage.

Contrôle des taux

Pour remblayer en toute sécurité, vous devez vous assurer que votre tâche de backfill se comporte de manière cohérente. Votre tâche doit donc être dotée d'un contrôle de taux qui peut être facilement modifié pour augmenter ou réduire l'échelle. En Java/Scala, vous pouvez utiliser le RateLimiter de Guava.

Contrôle dynamique des débits

Dans certains cas, il est possible d'aller plus vite lorsque le trafic de production est moins important. Pour cela, vous devez surveiller l'état actuel du système et voir s'il est possible d'aller plus vite. Nous avons ajusté le RPS sur la base d'une augmentation additive et d'une diminution multiplicative. Nous avons toujours fixé une limite supérieure au trafic pour des raisons de sécurité.

Arrêt d'urgence

Le processus de migration doit pouvoir s'arrêter rapidement en cas de panne ou de suspicion de surcharge. Tout backfill pendant une panne doit être interrompu à la fois par précaution et parce qu'il constitue une source potentielle de bruit. Même après une panne, les systèmes ont tendance à subir une charge supplémentaire au fur et à mesure qu'ils se rétablissent. La possibilité d'arrêter le backfill permet également de déboguer les problèmes liés à l'échelle.

Taille du fichier de données

Lors de la vidange des données, la taille des fichiers doit être d'environ 1 Go, avec une flexibilité de 10x de part et d'autre. Si la taille du fichier est trop importante, vous rencontrerez des problèmes tels que la limitation MultiPart de différents outils. Si la taille de votre fichier est faible, vous avez trop de fichiers et le simple fait de les répertorier prendra beaucoup de temps. Vous risquez même de vous heurter à la limite ARGMAX lorsque vous exécutez des commandes dans un shell. Cela devient suffisamment important pour s'assurer que chaque fois que vous faites quelque chose avec des données, cela a été appliqué à tous les fichiers et pas seulement à certains d'entre eux.

Tolérance aux fautes

Tous les travaux de backfill nécessitent une certaine forme de transformation des données. Lorsque vous faites cela, vous rencontrez inévitablement des problèmes de qualité/corruption des données. Vous ne pouvez pas arrêter le travail de backfill à chaque fois que cela se produit, car ces mauvais enregistrements ont tendance à être distribués de manière aléatoire. Mais vous ne pouvez pas non plus les ignorer, car ils peuvent également être dus à un bogue dans le code. Pour remédier à ce problème, vous vidangez les enregistrements problématiques séparément et vous surveillez les statistiques. Si le taux d'échec est élevé, vous pouvez arrêter le remplissage manuellement, résoudre le problème et continuer. Dans le cas contraire, laissez le remplissage se poursuivre et examinez les échecs en parallèle.

Une autre raison pour laquelle les enregistrements ne sont pas écrits est le dépassement du délai RPC. Vous pouvez réessayer, mais à un moment donné, vous devez abandonner et aller de l'avant, quelle que soit la raison, pour vous assurer que vous pouvez progresser.

Journalisation

Il est tentant d'enregistrer les données pendant le backfill pour faciliter le débogage et surveiller les progrès, mais cela n'est pas toujours possible en raison de la pression exercée sur l'infrastructure de journalisation. Même si vous pouvez conserver des journaux, il y aura trop de données à conserver. La solution consiste à utiliser un limiteur de débit pour limiter la quantité de journaux que vous produisez. Vous ne devez limiter le taux que pour les parties qui produisent la plupart des journaux. Vous pouvez même choisir d'enregistrer toutes les erreurs si elles sont peu fréquentes.

Atténuer les risques

Outre l'analyse des données provenant de différentes statistiques de validation et de remplissage, Uber a également fait preuve de prudence dans le déploiement de LSG.

Nous l'avons mis en place en quelques semaines, avec l'accord des ingénieurs de garde des principaux utilisateurs de notre service. Nous l'avons d'abord déployé avec un système de secours (c'est-à-dire que si les données n'étaient pas trouvées dans LSG, nous essayions de les récupérer à partir de DynamoDB). Nous avons examiné les journaux de secours avant de les supprimer. Pour chaque enregistrement signalé comme manquant dans les journaux de secours, nous avons vérifié LSG pour nous assurer qu'il n'était pas réellement manquant. Même après cela, nous avons conservé les données de DynamoDB pendant un mois avant d'arrêter d'y écrire des données, de faire une dernière sauvegarde et d'abandonner la table.

Conclusion

Uber a migré toutes ses données de transactions de paiement de DynamoDB et du stockage blob vers une nouvelle solution à long terme, un magasin de données spécialement conçu à cet effet, appelé LedgerStore. Dans cet article, on a vu comment Uber a réalisé la migration de quantités massives de données monétaires critiques d'un datastore à un autre. On a abordé différents aspects de la migration, notamment les critères de migration, les vérifications, les problèmes de remplissage et la sécurité. Uber confirme avoir effectué cette migration sur une période de deux ans sans aucun temps d'arrêt ou de panne pendant ou après la migration.

Source : Uber

Et vous ?