Comment Uber a optimisé son déploiement Cassandra

Décommissionnement, réparation, transactions légères… Uber revient sur quelques défis rencontrés avec le passage à l’échelle de 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 99^e 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