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.
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.
[QUOTE]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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
