Pour gérer vos consentements :

Comment Uber a optimisé son déploiement Cassandra

Gestion interne ou externe ? Uber a fait le premier choix pour les réparations sur Cassandra.

En 2016, l’entreprise déployait la version open source de cette base de données, en tant que service managé. Elle s’étend aujourd’hui sur des centaines de clusters, pour des dizaines de milliers de nœuds. L’orchestration et la configuration sont réalisés avec un système interne appelé Odin.

Optimiser le processus de décommissionnement

Avec le passage à l’échelle, divers problèmes se sont manifestés. Par exemple, sur le remplacement des nœuds. Cette opération s’enclenche essentiellement lors de pannes matérielles et d’optimisations de la flotte. Moins fréquemment, lors de modifications de la topologie de déploiement ou en cas de récupération après sinistre.

La procédure a posé plusieurs soucis : blocage de décommissionnements, échecs intermittents des ajouts, incohérence des données. Assez pour potentiellement monopoliser plusieurs ingés.

Cette situation tenait, en particulier, à l’absence de nettoyage des fichiers hint pour les nœuds orphelins. Ces fichiers pouvaient, à terme, consommer plusieurs To. En outre, les nœuds décommissionnés les transféraient à leur successeur.

Le code gérant le décommissionnement a un limiteur de débit. Sa vitesse est inversement proportionnelle au nombre de nœuds. Dans le contexte d’un très grand cluster, le transfert des hints peut prendre des jours.

Une purge anticipée et un ajustement dynamique du limiteur de débit ont éliminé le problème… temporairement. Celui-ci ayant fini par se représenter, Uber a réexaminé son déploiement. Et constaté que l’étape de décommissionnement engendrait parfois des erreurs, souvent dues à une autre activité parallèle tel un rolling restart lié aux mises à jour de la flotte.

À défaut d’indicateurs adéquats, le plan de contrôle ne pouvait pas interroger Cassandra à propos de l’état du décommissionnement. Ni, d’ailleurs, du bootstrap. Uber a donc décidé d’exposer ces indicateurs par l’API JMX. En y ajoutant quelques correctifs, le processus de remplacement de nœuds, intégralement automatisé, a atteint une fiabilité de 99,99 %.

Mieux gérer les erreurs sur les transactions légères

Les transactions légères fonctionnent sur le même principe que le verrouillage optimiste. Elles permettent de conditionner des modifications à la valeur d’un champ récupéré à la lecture.

Il arrivait que le taux d’erreur sur ces transactions soit élevé. En cause : de multiples range movements (déplacement de tokens entre nœuds) étaient en attente. Une des raisons possibles était le déclenchement simultané d’opérations de remplacement de nœuds.

Passé quelques corrections sur le plan de contrôle, Uber s’est concentré sur Cassandra. Il a constaté que la majorité des nœuds supposaient l’existence d’un seul déplacement de tokens. Cela finissait par engendrer une exception dans le protocole gossip, due à un échec de résolution DNS.
Effectivement, une fois qu’un nouveau nœud avait rejoint un cluster, le protocole continuait à résoudre l’adresse IP de l’ancien. Il en résultait une désynchronisation des caches. La seule solution était alors de relancer le nouveau nœud. Uber a amélioré la gestion des erreurs à ce niveau, jusqu’à supprimer la nécessité d’interventions manuelles.

Automatiser les réparations

Censées résoudre les incohérences de données, les réparations (« anti-entropie ») avaient, au contraire, tendance à en occasionner.

Uber souhaitait que cette activité soit intégrée à Cassandra. Au sein de son déploiement, il a assigné un pool de threads au planificateur de réparations. Celui-ci maintient, sous le keyspace system_distributed, une table où se trouve l’historique de réparation de chaque nœud. Cela lui permet d’ordonner les opérations, y compris en les exécutant en simultané.

Le tout s’exécute dès le lancement d’un cluster, comme la compression, sans intervention manuelle ni dépendance envers le plan de contrôle. La durée de réparation au 99e percentile est passée de « plusieurs dizaines de jours » à « juste en-dessous d’un nombre de jours à un chiffre », pour reprendre les mots d’Uber…

Illustration © Siarhei – Adobe Stock

Recent Posts

FinOps : la spécification FOCUS dépassera-t-elle le IaaS ?

Premier stade de maturité atteint pour le projet FOCUS (FinOps Open Cost & Usage Specification),…

7 heures ago

CentOS en fin de vie : quelques portes de sortie

Le 30 juin 2024, c'en sera fini du projet CentOS. Parallèlement aux initiatives de Red…

10 heures ago

GenAI : Anthropic lance Claude 3.5 Sonnet

Trois mois après le lancement de Claude, sa gamme de LLM, Anthropic lance une mise…

11 heures ago

Kaspersky banni aux États-Unis : les grandes lignes du dispositif

Déjà banni des réseaux fédéraux étasuniens, Kaspersky l'est désormais dans tout le pays. Que prévoit…

13 heures ago

HP adhère avec modération au concept du PC Copilot+

HP lance ses premiers PC Copilot+, mais les met en avant sous une marque spécifique…

1 jour ago

Controversé, l’index de transparence LLM de Stanford passe en v2

Stanford a récemment actualisé son index de transparence des LLM, l'étendant à 14 fournisseurs dont…

2 jours ago