- En 2023, Stripe a traité un volume total de paiements de 1 000 milliards de dollars tout en maintenant une disponibilité de 99,999 %
- L’équipe infrastructure bases de données de Stripe fournit DocDB, une database as a service (DBaaS), comme couche de base de son API
- DocDB est une version étendue de MongoDB Community, composée de plusieurs services développés en interne chez Stripe
- Elle traite plus de 5 millions de requêtes par seconde et stocke des données financières critiques de l’ordre du pétaoctet, réparties sur plus de 2 000 shards de base de données et plus de 5 000 collections
- Stripe a choisi MongoDB Community pour la flexibilité de son modèle documentaire et sa capacité à traiter des données en temps réel à grande échelle
- En 2011, MongoDB Atlas n’existait pas encore, ce qui a conduit Stripe à construire son propre cluster d’instances MongoDB autogérées dans le cloud
- Le cœur de DocDB est la Data Movement Platform
- À l’origine conçue comme une solution de scale-out pour dépasser les limites du scale-up de MongoDB, elle a ensuite été personnalisée pour de multiples usages
- Fusion de shards de base de données sous-utilisés afin d’améliorer l’utilisation et l’efficacité, mises à niveau majeures du moteur de base de données pour gagner en fiabilité, ou encore passage d’un mode multitenant à un mode single-tenant pour de très gros clients
- La Data Movement Platform permet de passer d’un petit nombre de shards de grande taille à un grand nombre de shards de petite taille
- Elle offre aussi des migrations transparentes pour les clients et sans downtime, ce qui permet de fournir une DBaaS hautement élastique
- DocDB peut scinder des shards de base de données en cas de pic de trafic et, lorsque le trafic baisse, regrouper des milliers de bases via du bin packing
Comment Stripe a construit son infrastructure de base de données
- Lors du lancement de Stripe en 2011, l’entreprise a choisi MongoDB comme base de données en ligne, estimant qu’il offrait une meilleure productivité développeur qu’une base relationnelle standard
- Stripe voulait exploiter au-dessus de MongoDB une infrastructure de base de données robuste, privilégiant la fiabilité de l’API, mais n’a trouvé aucune DBaaS du marché répondant à ses besoins
- Répondre aux plus hauts niveaux de disponibilité, de durabilité et de performance
- Exposer un minimum de fonctionnalités base de données afin d’éviter les problèmes causés par des requêtes non optimisées des applications clientes
- Prendre en charge la scalabilité horizontale via le sharding
- Offrir une prise en charge de premier ordre du multitenant avec quotas imposés
- Fournir une sécurité forte grâce à l’application de politiques d’autorisation
- La solution a consisté à construire DocDB sur MongoDB comme moteur de stockage sous-jacent : une véritable DBaaS élastique et scalable, dont les migrations de données en ligne constituent le cœur
- Les applications produit de Stripe accèdent aux données de la base via une flotte de serveurs proxy de base de données développés en interne en Go afin d’imposer les exigences de fiabilité, de scalabilité, de contrôle d’allocation et de contrôle d’accès
- L’une des décisions architecturales clés a été d’utiliser le sharding comme mécanisme de scalabilité horizontale
- Des milliers de shards de base de données, chacun contenant une petite portion des données accumulées, constituent désormais la base de tous les produits Stripe
- Lorsqu’une application envoie une requête à un serveur proxy de base de données, celui-ci l’analyse, la route vers un ou plusieurs shards, puis agrège les résultats avant de les renvoyer à l’application
- Les serveurs proxy s’appuient sur un service de métadonnées des chunks pour associer les chunks aux shards de base de données, ce qui permet de retrouver facilement les shards pertinents pour une requête donnée
- Les événements de changement issus des écritures vers la base sont envoyés vers un système logiciel de streaming puis, à terme, archivés dans un stockage objet via une pipeline de change data capture (CDC)
- L’équipe Stripe provisionne, au niveau des applications produit, des conteneurs logiques de données appelés bases de données logiques, via un control plane interne pour les bases documentaires, incluant une ou plusieurs collections DocDB composées de documents ayant des finalités liées
- Les données de ces collections DocDB sont réparties sur plusieurs bases de données physiques, chacune stockant de petits chunks de collection
- Les bases physiques de DocDB résident sur des shards déployés sous forme de replica sets composés d’un nœud primaire et de plusieurs nœuds secondaires avec réplication et basculement automatique
Comment la Data Movement Platform a été conçue
- Pour créer un produit DBaaS scalable horizontalement et hautement élastique, capable de monter et descendre en charge selon les besoins des applications produit, il fallait pouvoir migrer les données entre shards de base de données sans downtime et de façon transparente pour les clients
- Il s’agit d’un problème complexe de systèmes distribués, encore compliqué par les exigences propres aux données financières critiques
- Cohérence et intégrité des données : il faut garantir que les données migrées conservent leur cohérence et leur intégrité à la fois sur le shard source et sur le shard cible
- Disponibilité : un downtime prolongé pendant une migration de données est inacceptable, car des millions d’entreprises dépendent de Stripe 24 h/24 pour encaisser les paiements de leurs clients
- L’objectif est de maintenir les étapes critiques du processus de migration en dessous du temps d’un basculement planifié du primaire de base de données, généralement de quelques secondes, et dans le budget de retry des applications produit
- Granularité et adaptabilité : à l’échelle de Stripe, il doit être possible de migrer un nombre arbitraire de chunks de données, depuis un nombre arbitraire de sources vers des shards cibles arbitraires
- Il ne doit pas y avoir de limite au nombre de migrations de chunks en cours dans la flotte, ni au nombre de migrations auxquelles un shard donné peut participer à un instant donné
- Comme une part importante des shards de base de données contient des volumes de données de l’ordre du téraoctet, il faut aussi pouvoir migrer à haut débit des chunks de tailles variées
- Aucun impact sur les performances des shards source : lors de la migration de chunks entre shards, l’objectif est de préserver les performances et le débit disponible des shards source, afin de ne pas dégrader les performances des requêtes utilisateur ni le débit utile
- Pour répondre à ces exigences, Stripe a construit une plateforme de déplacement de données qui invoque des services dédiés pour gérer les migrations de données en ligne entre shards de base de données
- Le composant Coordinator de la Data Movement Platform orchestre les différentes étapes liées à une migration de données en ligne et appelle les services concernés pour exécuter chacune des phases décrites ci-dessous
Étape 1 : enregistrement de la migration du chunk
- D’abord, l’intention de migrer un chunk de base de données depuis un shard source vers un shard cible arbitraire est enregistrée dans le service de métadonnées des chunks
- Ensuite, les index sont construits sur le shard cible pour les chunks en cours de migration
Étape 2 : import massif des données
- Ensuite, les données sont chargées dans un ou plusieurs shards de base de données à partir d’un snapshot du chunk sur le shard source à l’instant T
- Le service chargé de l’import massif prend en charge différents filtres de données et n’importe que les chunks satisfaisant les critères de filtrage
- Au départ, cela semblait simple, mais Stripe a rencontré des limites de débit lors du chargement massif de données dans les shards DocDB
- L’équipe a essayé de regrouper les écritures par lots et d’ajuster les paramètres du moteur DocDB pour optimiser l’ingestion massive, sans grand succès
- Une avancée majeure a toutefois été obtenue en exploitant le fait que DocDB utilise une structure de données en B-tree pour ordonner les données, et en cherchant à optimiser l’ordre d’insertion
- En triant les données selon les attributs d’index les plus courants de la collection puis en les insérant dans cet ordre, Stripe a fortement amélioré la proximité des écritures, ce qui a multiplié par 10 le débit d’écriture
Étape 3 : réplication asynchrone
- Une fois les données importées sur le shard cible, la réplication des écritures depuis le shard source vers le shard cible démarre à partir de l’instant T pour le chunk de base de données en cours de migration
- Le système de réplication asynchrone lit les changements provoqués par les écritures sur le shard source dans le système CDC et exécute les écritures sur le shard cible
- Le journal d’opérations, ou oplog, est une collection spéciale de chaque shard DocDB qui conserve l’historique de toutes les opérations modifiant les données des bases de ce shard
- Les oplogs de tous les shards DocDB sont envoyés vers Kafka, plateforme de streaming d’événements, puis archivés dans un service de stockage objet cloud comme Amazon S3
- Stripe a construit un service qui utilise les événements d’oplog de Kafka et d’Amazon S3 pour répliquer les changements depuis un ou plusieurs shards source DocDB vers un ou plusieurs shards cibles DocDB
- En s’appuyant sur les événements d’oplog du système CDC, ce service évite de consommer le débit de lecture disponible pour les requêtes utilisateur sur les shards source, et ne ralentit donc pas les requêtes utilisateur tout en n’étant pas limité par la taille de l’oplog des shards source
- Le service est conçu pour rester résilient même si les shards cibles deviennent indisponibles, et pour pouvoir démarrer, suspendre et reprendre la synchronisation à partir d’un checkpoint à tout moment
- Le service de réplication fournit également une fonctionnalité permettant de récupérer le lag de réplication
- Pendant la migration, les changements du chunk en cours sont répliqués dans les deux sens, du shard source vers le shard cible et inversement ; le service de réplication tague les écritures qu’il émet pour éviter une réplication asynchrone circulaire
- Il s’agissait d’un choix de conception délibéré, afin de conserver la possibilité de renvoyer le trafic vers le shard source si un problème survient lors du basculement du trafic vers le shard cible
Étape 4 : vérification de l’exactitude
- Une fois la réplication synchronisée entre les shards source et cible, Stripe vérifie de manière exhaustive l’intégrité et l’exactitude des données en comparant des snapshots pris au même instant
- Ce choix de conception a été fait délibérément pour ne pas impacter le débit des shards
Étape 5 : basculement du trafic
- Une fois que les données du chunk ont été importées depuis la source vers le shard cible et que les changements sont activement répliqués, le basculement du trafic est orchestré par le Coordinator
- Pour rediriger les chemins de lecture et d’écriture du chunk de données en cours de migration, il faut d’abord suspendre brièvement le trafic du shard source, mettre à jour le routage dans le service de métadonnées des chunks, puis faire en sorte que les serveurs proxy redirigent les lectures et les écritures vers le shard cible
- Le protocole de basculement du trafic repose sur une idée de version gating
- En régime normal, chaque serveur proxy ajoute un numéro de version token aux requêtes envoyées aux shards DocDB
- Stripe a ajouté des patchs personnalisés à MongoDB afin que les shards puissent vérifier si le numéro de version token des requêtes reçues des proxies est plus récent que celui qu’ils connaissent, et ne traiter que les requêtes répondant à ce critère
- Pour mettre à jour le routage des chunks, le Coordinator exécute les étapes suivantes :
- D’abord, il incrémente le numéro de version token du shard source DocDB. Ce numéro est stocké dans un document d’une collection spéciale de DocDB et, à partir de cet instant, toutes les lectures et écritures visant le chunk sur le shard source sont rejetées
- Ensuite, il attend que le service de réplication réplique les écritures encore en attente depuis le shard source
- Enfin, il met à jour le routage du chunk dans le service de métadonnées des chunks afin qu’il pointe vers le shard cible et le numéro de version token correspondant
- Une fois cela terminé, les serveurs proxy récupèrent dans le service de métadonnées des chunks le routage mis à jour du chunk ainsi que le numéro de version token le plus récent
- Les serveurs proxy utilisent ce routage mis à jour pour diriger les lectures et les écritures du chunk vers le shard cible
- L’ensemble du protocole de basculement du trafic prend moins de 2 secondes à s’exécuter, et toutes les lectures et écritures ayant échoué sur le shard source réussissent lors d’une nouvelle tentative
Étape 6 : désenregistrement de la migration du chunk
- Enfin, le service de métadonnées des chunks marque la migration comme terminée et supprime les données du chunk du shard source, ce qui clôt le processus de migration
Utilisation de la Data Movement Platform
- La capacité à migrer en ligne des chunks de données entre les shards DocDB aide Stripe à étendre horizontalement son infrastructure de base de données au rythme de sa croissance
- Les ingénieurs de l’équipe infrastructure bases de données peuvent, d’un simple clic, scinder des shards DocDB selon leur taille et leur débit afin de libérer de la capacité de stockage et de traitement pour les équipes produit
- En 2023, Stripe a utilisé la Data Movement Platform pour améliorer l’utilisation de son infrastructure de base de données
- Plus précisément, l’entreprise a migré 1,5 pétaoctet de données de manière transparente pour les applications produit afin de faire du bin packing sur des milliers de bases sous-utilisées et de ramener le nombre total de shards DocDB sous-jacents à environ trois quarts de son niveau initial
- Stripe a également utilisé la Data Movement Platform pour mettre à niveau sa flotte d’infrastructure de base de données en forklifant en une seule étape les données vers une version plus récente de MongoDB, sans passer par des versions majeures ou mineures intermédiaires
- L’équipe infrastructure bases de données de Stripe se concentre sur la construction de fondations robustes et fiables, capables d’évoluer avec la croissance de l’économie d’Internet
- Elle prototype actuellement un système de gestion de la chaleur qui équilibre proactivement les données entre shards selon leur taille et leur débit, et investit dans l’auto-scaling des shards pour répondre dynamiquement aux variations de trafic
Aucun commentaire pour le moment.