Principaux points à retenir
Notre migration Binance Ledger visait à résoudre le problème de compte chaud inhérent à notre ancien serveur de base de données relationnelle.
Un échange cryptographique fonctionne 24 heures sur 24, 7 jours sur 7, 365 jours par an, sans fenêtre de maintenance à exploiter, contrairement à un échange régulier, qui a des heures de pause quotidiennes.
La migration vers un nouveau Binance Ledger devait s'effectuer en ligne, conserver les actifs des utilisateurs SAFU et n'entraîner aucun impact commercial, de sorte que l'expérience des utilisateurs finaux restait transparente.
Nous avons choisi une stratégie de migration progressive, compte par compte, au lieu d'une stratégie de basculement simultanée comme celle utilisée par l'outil gh-ost.
Apprenez-en davantage sur notre migration Binance Ledger et sur les outils et techniques utilisés tout au long du processus.
Binance Ledger sous-tend nos opérations techniques et traite des millions de transactions quotidiennes auprès d'une vaste base d'utilisateurs. Vous pouvez en savoir plus sur le système, ses objectifs et ses défis sur notre blog Comment Binance Ledger alimente votre expérience Binance. Notre processus de migration de l'ancienne vers la nouvelle version a été confronté à un défi typique : comment pouvons-nous mettre à niveau le moteur à la volée alors que l'avion est encore en vol ? Nous avons dû migrer les actifs de nos utilisateurs et conserver les fonds SAFU était notre priorité absolue.
Les principaux défis de migration de Binance
La liste suivante de défis a dû être relevée pour atteindre nos objectifs établis :
S'assurer de l'exactitude totale du nouveau grand livre
Être capable de détecter tout problème de fonds et de le résoudre en temps opportun et avec précision
Ne subissez aucun temps d’arrêt pour les amonts
Comparaison de notre mission de migration avec la base de données en ligne DDL
Avant d’entrer dans les détails de notre solution, examinons le problème courant lié à l’exécution d’un DDL (langage de définition de données) en ligne pour une grande table. Qu’est-ce que le DDL exactement ? Eh bien, imaginez un tableau avec des centaines de millions de lignes auquel nous devons ajouter une autre colonne. Nous voulons le faire en ligne sans perturber l'activité.
L'outil gh-ost est largement utilisé pour résoudre ce problème, et vous pouvez voir comment il fonctionne dans le diagramme suivant.
Le processus se compose essentiellement de deux phases :
La phase de synchronisation, qui se poursuit jusqu'à ce que la nouvelle table soit totalement identique à la table d'origine. Il existe deux types de données à synchroniser :
Données existantes
Données incrémentielles (nouvelles données générées à partir de la table d'origine lors du processus de migration en cours)
La phase de basculement échange la table d'origine avec la nouvelle sans interrompre les transactions en cours.
Où les problèmes de Binance Ledger différaient
Malgré certaines similitudes, Binance Ledger a dû relever des défis intrinsèquement uniques dans sa mission de migration en ligne.
Premièrement, les systèmes backend de Binance fonctionnent dans un environnement distribué, tandis que la base de données en ligne DDL se trouve dans un environnement monolithique. Deuxièmement, nous ne pouvons pas nous permettre d’adopter une approche de basculement d’un seul coup, car les données constituaient l’actif de nos utilisateurs. Enfin, nous devons nous assurer que tous les services concernés fonctionnent dans leur ensemble avant de commencer à effectuer une migration massive.
Comme dans l'exemple DDL en ligne précédent, notre migration comportait également deux phases :
La phase de synchronisation, où un service de réplication dédié a été spécialement conçu pour synchroniser les soldes de l'ancien grand livre vers le nouveau grand livre.
La phase de bascule compte par compte
Approches basées sur les phases
La tâche était immense et, comme on dit, Rome ne s’est pas construite en un jour. L’approche diviser pour régner fonctionne souvent à merveille face à un domaine de problèmes vaste et complexe.
Phase 1 : Réplication
Le pourquoi
Nous pouvons résumer ici notre réflexion en deux points principaux :
Nous avons modélisé Binance Ledger comme un nouvel esclave rejoignant le cluster MySQL existant, qui alimente le système de registre actuel. En tirant parti des techniques de réplication, nous pourrions maintenir les soldes des utilisateurs entièrement synchronisés de manière asynchrone.
Nous pourrions ensuite acheminer le trafic de production textuellement vers Binance Ledger pour valider son exactitude et sa robustesse. Même si les choses tournent mal pendant cette phase, il n’y a aucun impact pour nous et nos utilisateurs.
Le quoi
Ci-dessous, nous avons illustré le pipeline de réplication global. Le chemin critique auquel il faut prêter attention est :
Transfert → Ledger → Réplicateur Binance Ledger → Binance Ledger
Le comment
Nous avons décomposé le processus de réplication en deux étapes distinctes :
J'ai vidé un instantané de la base de données du grand livre, puis je l'ai importé dans Binance Ledger.
Réplication du journal bin de la base de données du grand livre après le moment où l'instantané a été vidé.
À terme, les données des soldes et des journaux de soldes seraient conservées en parfaite synchronisation entre l'ancien grand livre et le Binance Ledger, qui peuvent en outre être validées par le module de réconciliation complet.
Le quand
Binance Ledger a été mis en ligne début août 2022. Nous avons ensuite lancé le processus de réplication, qui a duré jusqu'à la mi-novembre 2022. Ce processus a été une période importante pour nous car l'exactitude du nouveau système de grand livre devait être validée à 100 %. Cette étape ne pouvait être ignorée avant de passer à la prochaine phase de migration.
En fin de compte, nous n’avons trouvé aucun problème et avons effectué plusieurs routines de publication pour nous familiariser davantage avec la situation. Le processus de trois mois n’a pas été particulièrement rapide, mais il était nécessaire pour atteindre notre objectif SAFU.
Phase 2 : migration en ligne
Le pourquoi
Pour migrer des centaines de millions de comptes, nous avons créé un travail de migration personnalisé.
Le quoi
Ci-dessous, nous avons décrit le flux de migration principal pour un compte :
Voici quelques notes clés à garder à l’esprit :
Le système de compte gère le mappage de propriété pour chaque compte.
Compte A → grand livre
Compte B → Grand livre Binance
Compte C → interdit
Avant la migration d'un compte, s'il existait une transaction simultanée en attente, elle serait ignorée afin de réduire l'impact commercial.
Nous avons modifié le mappage de propriété de grand livre à interdit, interdisant toute mise à jour ultérieure du solde, le rendant ainsi immuable.
Nous avons rapproché les soldes entre l'ancien grand livre et le Binance Ledger.
Nous avons modifié le mappage de propriété d'interdit à Binance Ledger, permettant aux futures mises à jour de solde d'être acheminées directement vers Binance Ledger.
Selon notre métrique de performances, il a fallu en moyenne 150 ms entre l'étape 3 et l'étape 5. En théorie, les utilisateurs ne peuvent effectuer aucune transaction pendant cette période de migration de 150 ms. Il s’est avéré qu’il n’y avait aucune transaction impactée.
L'exécution
Chez Binance, nous préconisons le principe de « bonne exécution plutôt que planification méticuleuse ». Une exécution solide est essentielle à notre succès, et la sécurité des fonds est toujours notre priorité absolue. Nous avons adopté une stratégie de migration progressive sur une période de trois semaines pour détecter les problèmes le plus tôt possible, ce qui a permis de réduire l'ampleur de l'impact négatif.
Le processus de réconciliation
La réconciliation est extrêmement importante pour détecter en temps opportun les anomalies potentielles d’équilibre, dans une perspective impartiale. Nous pouvons mener le processus presque en temps réel pour prendre des mesures rapides avant que les choses n’empirent. Deux types de modules de réconciliation sont développés spécifiquement pour le processus de migration en ligne : en temps réel et complet.
Temps réel
Le processus de rapprochement basé sur les transactions est conçu pour détecter tout problème de fonds en temps réel.
Complet
Nous pouvons effectuer périodiquement un rapprochement complet en fonction des instantanés synchronisés avec l'entrepôt de données. Ce processus garantit que tous les soldes sont les mêmes entre l'ancien grand livre et le grand livre Binance.
Par exemple, disons que 10 millions d’utilisateurs résident toujours sur l’ancien grand livre. Nous pouvons utiliser ce rapprochement complet pour vérifier que les soldes et les journaux de soldes sont les mêmes entre l'ancien grand livre et le grand livre Binance.
Conclusion du processus de migration
En un mot, la mission a été accomplie en 1) utilisant des techniques de réplication pour valider l'exactitude du nouveau Binance Ledger 2) en mettant en œuvre une stratégie de migration compte par compte pour mettre à niveau le moteur lentement, en toute sécurité mais sûrement.
Nous pensons que le paradigme de migration en ligne susmentionné peut être réutilisé dans des tâches similaires. Si les processus et les sujets abordés ont piqué votre intérêt, pourquoi ne pas envisager de rejoindre l’équipe ? Nous sommes toujours à la recherche de personnes dévouées ayant de nouvelles perspectives sur nos défis quotidiens chez Binance.
Les références
Comment Binance Ledger alimente votre expérience Binance
Outil de migration de schéma en ligne de GitHub pour MySQL
Lectures complémentaires
Utiliser MLOps pour créer un pipeline d'apprentissage automatique de bout en bout en temps réel | Blog Binance
Binance est-il le bon endroit pour vous ? Raisons de ne pas rejoindre Binance | Blog Binance