🥇Tarantool Cartridge : sharding d'un backend Lua en trois lignes

Dans Mail.ru Group, nous avons Tarantool — c'est un serveur d'applications en Lua qui fait également office de base de données (ou vice versa ?). Il est rapide et performant, mais les capacités d'un seul serveur ne sont pas illimitées. Le scaling vertical n'est pas non plus une panacée, c'est pourquoi Tarantool propose des outils pour le scaling horizontal — le module vshard. [1]. Il permet de sharder les données sur plusieurs serveurs, mais il faut s'investir pour le configurer et intégrer la logique métier.

Bonne nouvelle : nous avons rencontré des obstacles (par exemple [2], [3]) et avons développé un nouveau framework qui simplifie considérablement cette problématique.

Tarantool Cartridge — est un nouveau framework pour le développement de systèmes distribués complexes. Il permet de se concentrer sur l'écriture de la logique métier plutôt que sur les problèmes d'infrastructure. Dans cet article, je vais expliquer comment ce framework fonctionne et comment l'utiliser pour écrire des services distribués.

Mais quel est donc le problème ?

Nous avons Tarantool, nous avons vshard — que demander de plus ?

Premièrement, il s'agit de la commodité. La configuration de vshard se règle via des tables Lua. Pour qu'un système distribué composé de plusieurs processus Tarantool fonctionne correctement, la configuration doit être identique partout. Personne ne veut s'en occuper manuellement. C'est pourquoi divers scripts, Ansible et des systèmes de déploiement sont utilisés.

Cartridge gère la configuration de vshard de manière autonome, en se basant sur sa propre configuration distribuée. En fait, c'est un simple fichier YAML dont une copie est conservée dans chaque instance de Tarantool. La simplification réside dans le fait que le framework veille lui-même à sa configuration et à son uniformité.

Deuxièmement, il s'agit encore de commodité. La configuration vshard n'a rien à voir avec le développement de la logique métier et ne fait que distraire le programmeur de son travail. Lorsque nous discutons de l'architecture d'un projet, il est généralement question de composants individuels et de leurs interactions. Il est encore tôt pour penser au déploiement d'un cluster sur 3 centres de données.

Nous avons résolu ces problèmes à maintes reprises, et à un moment donné, nous avons réussi à développer une approche qui simplifie le travail avec l'application tout au long de son cycle de vie : création, développement, test, CI/CD, maintenance.

Le Cartridge introduit le concept de rôle pour chaque processus Tarantool. Les rôles sont cette notion qui permet au développeur de se concentrer sur l'écriture de code. Tous les rôles disponibles dans le projet peuvent être lancés sur une seule instance de Tarantool, et cela suffira pour les tests.

Les principales fonctionnalités de Tarantool Cartridge :

l'orchestration automatisée du cluster ;
l'extension des fonctionnalités de l'application grâce à de nouveaux rôles ;
un modèle d'application pour le développement et le déploiement ;
le sharding automatique intégré ;
l'intégration avec le framework de test Luatest ;
la gestion du cluster via WebUI et API ;
des outils de packaging et de déploiement.

Hello, World!

J'ai hâte de montrer le framework lui-même, alors parlons de l'architecture plus tard, et commençons par quelque chose de simple. Si l'on suppose que Tarantool est déjà installé, il reste juste à faire

$ tarantoolctl rocks install cartridge-cli
$ export PATH=$PWD/.rocks/bin/:$PATH

Ces deux commandes installeront les utilitaires en ligne de commande et permettront de créer votre première application à partir du modèle :

$ cartridge create --name myapp

Et voici ce que nous allons obtenir :

myapp/
├── .git/
├── .gitignore
├── app/roles/custom.lua
├── deps.sh
├── init.lua
├── myapp-scm-1.rockspec
├── test
│   ├── helper
│   │   ├── integration.lua
│   │   └── unit.lua
│   ├── helper.lua
│   ├── integration/api_test.lua
│   └── unit/sample_test.lua
└── tmp/

C'est un dépôt git avec une application "Hello, World!" prête. Essayons de la lancer tout de suite, après avoir installé les dépendances (y compris le framework lui-même) :

$ tarantoolctl rocks make
$ ./init.lua --http-port 8080

Ainsi, nous avons une nœud de l'application shardée en cours d'exécution. Un curieux peut immédiatement ouvrir l'interface web, configurer le cluster à partir d'un nœud et profiter du résultat, mais il est encore trop tôt pour se réjouir. Pour l'instant, l'application ne peut rien faire d'utile, donc je parlerai du déploiement plus tard, et maintenant il est temps d'écrire du code.

Développement d'applications

Imaginez que nous concevons un projet qui doit recevoir des données, les enregistrer et générer un rapport une fois par jour.

Nous commençons à dessiner le schéma et y plaçons trois composants : gateway, storage et scheduler. Nous développons davantage l'architecture. Puisque nous utilisons vshard comme stockage, nous ajoutons vshard-router et vshard-storage au schéma. Ni le gateway ni le scheduler ne communiqueront directement avec le stockage, c'est le rôle du routeur, il est conçu pour ça.

Ce schéma ne reflète toujours pas tout à fait ce que nous allons créer dans le projet, car les composants apparaissent abstraits. Nous devons encore examiner comment cela se projette sur le véritable Tarantool — groupons nos composants par processus.

Il n'a pas beaucoup de sens de garder le vshard-router et la passerelle sur des instances séparées. Pourquoi devrions-nous traverser le réseau un de plus, si cela fait déjà partie des responsabilités du routeur ? Ils doivent être lancés dans un seul processus. Cela signifie que la passerelle, ainsi que vshard.router.cfg, doivent s'initialiser dans un même processus, et qu'ils puissent interagir localement.

À la phase de conception, travailler avec trois composants était pratique, mais je, en tant que développeur, ne veux pas réfléchir au lancement de trois instances de Tarnatool pendant que j'écris du code. J'ai besoin de lancer des tests et de vérifier que j'ai correctement écrit la passerelle. Ou peut-être que je veux présenter une caractéristique à mes collègues. Pourquoi devrais-je me compliquer la vie avec le déploiement de trois instances ? C'est ainsi qu'est née la concept de rôles. Un rôle est simplement un module Lua dont le cycle de vie est géré par Cartridge. Dans cet exemple, il y en a quatre : passerelle, routeur, stockage, planificateur. Dans un autre projet, il pourrait y en avoir plus. Tous les rôles peuvent être lancés dans un seul processus, et cela suffira.

Et quand il s'agira de déploiement en staging ou en production, nous attribuerons à chaque processus Tarantool son propre ensemble de rôles en fonction des capacités matérielles :

Gestion de la topologie

Les informations concernant l'endroit où certaines rôles sont exécutées doivent être stockées quelque part. Et ce « quelque part » est une configuration distribuée, dont j'ai déjà parlé précédemment. Le plus important dans cela est la topologie du cluster. Ici, trois groupes de réplication constitués de cinq processus Tarantool sont représentés :

Nous ne voulons pas perdre de données, donc nous prenons soin des informations concernant les processus en cours d'exécution. Cartridge surveille la configuration grâce à un commit en deux phases. Dès que nous voulons mettre à jour la configuration, il vérifie d'abord la disponibilité de toutes les instances et leur capacité à accepter une nouvelle configuration. Ensuite, lors de la deuxième phase, la configuration est appliquée. Ainsi, même si une instance devient temporairement indisponible, rien de grave ne se produira. La configuration ne sera tout simplement pas appliquée et vous verrez une erreur à l'avance.

Dans la section topologie, un paramètre important est également défini, à savoir le leader de chaque groupe de réplication. Généralement, il s'agit de l'instance sur laquelle les écritures sont effectuées. Les autres sont le plus souvent en mode lecture seule, bien qu'il puisse y avoir des exceptions. Parfois, des développeurs audacieux n'ont pas peur des conflits et peuvent écrire des données sur plusieurs répliques en parallèle, mais certaines opérations, quelles qu'en soient les circonstances, ne doivent pas être exécutées deux fois. C'est ce qu'on appelle le leader.

Cycle des rôles

Pour qu'un rôle abstrait puisse exister dans une telle architecture, le cadre doit les gérer d'une manière ou d'une autre. Évidemment, la gestion se fait sans redémarrer le processus Tarantool. Il existe 4 callbacks pour la gestion des rôles. Cartridge les appellera lui-même en fonction de ce qui est écrit dans sa configuration distribuée, appliquant ainsi la configuration à des rôles spécifiques.

function init()
function validate_config()
function apply_config()
function stop()

Chaque rôle possède une fonction init. Elle est appelée une fois lors de l'activation du rôle ou lors du redémarrage de Tarantool. C'est pratique, par exemple, pour initialiser box.space.create, ou le planificateur peut démarrer un certain fiber en arrière-plan qui effectuera des tâches à intervalles réguliers.

Une seule fonction init peut ne pas suffire. Cartridge permet aux rôles d'utiliser la configuration distribuée qu'il utilise pour stocker la topologie. Nous pouvons déclarer une nouvelle section dans cette même configuration et y stocker un fragment de configuration métier. Dans mon exemple, cela peut être un schéma de données ou des paramètres de planification pour le rôle scheduler.

Le cluster appelle validate_config et apply_config à chaque modification de la configuration distribuée. Lorsque la configuration est appliquée par un commit en deux phases, le cluster vérifie que chaque rôle est prêt à accepter cette nouvelle configuration et informe l'utilisateur d'une erreur si nécessaire. Une fois que tout le monde est d'accord sur le fait que la configuration est normale, apply_config.

Les rôles ont également une méthode stop, qui est nécessaire pour nettoyer les résultats de l'activité du rôle. Si nous disons que le scheduler sur ce serveur n'est plus nécessaire, il peut arrêter les fibers qu'il a lancés à l'aide de init.

Les rôles peuvent interagir entre eux. Nous avons l'habitude d'écrire des appels de fonctions en Lua, mais il peut arriver qu'il n'y ait pas le rôle dont nous avons besoin dans ce processus. Pour faciliter les appels à distance, nous utilisons un module auxiliaire rpc (remote procedure call), basé sur le netbox standard intégré dans Tarantool. Cela peut être utile si, par exemple, votre gateway souhaite demander directement au scheduler d'exécuter une tâche immédiatement, plutôt que d'attendre une journée.

Un autre point important est l'assurance de la tolérance aux pannes. Pour le suivi de l'état de santé, Cartridge utilise le protocole SWIM. [4]. Pour résumer, les processus échangent entre eux des 'rumeurs' via UDP : chaque processus informe ses voisins des dernières nouvelles, et ils répondent. Si une réponse ne parvient pas, Tarantool commence à suspecter quelque chose d’anormal, et après un certain temps, annonce la mort et commence à relater cette nouvelle à tous les environnants.

Sur la base de ce protocole, Cartridge organise un traitement automatique des pannes. Chaque processus surveille son environnement et, si le leader cesse soudainement de répondre, un replica peut prendre son rôle, et Cartridge configure les rôles lancés en conséquence.

Il faut être prudent ici, car des commutations fréquentes peuvent conduire à des conflits de données lors de la réplication. Activer le failover automatique de manière aléatoire n'est bien sûr pas conseillé. Il est essentiel de comprendre ce qui se passe et de s’assurer que la réplication ne échouera pas après que le leader se soit rétabli et qu'il ait récupéré sa couronne.

Tout ce qui a été dit peut donner l'impression que les rôles ressemblent à des microservices. En un sens, ils en sont, mais en tant que modules au sein des processus de Tarantool. Cependant, il existe plusieurs différences fondamentales. Tout d'abord, tous les rôles du projet doivent vivre dans une seule base de code. Et tous les processus Tarantool doivent être lancés à partir d'une seule base de code pour éviter des surprises telles que celles qui se produisent lorsque nous tentons d'initialiser un scheduler, mais qu'il est tout simplement absent. Il est également essentiel de ne pas permettre des différences dans les versions du code, car le comportement du système dans cette situation est très difficile à prédire et à déboguer.

Contrairement à Docker, nous ne pouvons pas simplement prendre une "image" de rôle, l'emporter sur une autre machine et là-la démarrer. Nos rôles ne sont pas aussi isolés que des conteneurs Docker. De plus, nous ne pouvons pas exécuter deux rôles identiques sur une même instance. Un rôle existe soit, soit il n'existe pas ; en quelque sorte, c'est un singleton. Enfin, dans tout le groupe de réplication, les rôles doivent être identiques, sinon ce serait absurde : les données sont identiques, mais la configuration est différente.

Outils de déploiement

J'ai promis de montrer comment Cartridge aide à déployer des applications. Pour faciliter la vie des autres, le framework emballe des packages RPM :

$ cartridge pack rpm myapp -- emballera pour nous .\/myapp-0.1.0-1.rpm
$ sudo yum install .\/myapp-0.1.0-1.rpm

Le package installé contient presque tout le nécessaire : l'application et ses dépendances Lua installées. Tarantool sera également installé sur le serveur comme dépendance du package RPM, et notre service sera prêt à être lancé. Cela se fait via systemd, mais il faut d'abord écrire un peu de configuration. Au minimum, il faut indiquer l'URI de chaque processus. Trois exemples suffiront.

$ sudo tee \/etc\/tarantool\/conf.d\/demo.yml <<CONFIG
myapp.router: {"advertise_uri": "localhost:3301", "http_port": 8080}
myapp.storage_A: {"advertise_uri": "localhost:3302", "http_enabled": False}
myapp.storage_B: {"advertise_uri": "localhost:3303", "http_enabled": False}
CONFIG

Il y a ici un détail intéressant. Au lieu d'indiquer simplement le port du protocole binaire, nous indiquons l'adresse publique du processus dans son intégralité, y compris le nom d'hôte. Cela est nécessaire pour que les nœuds du cluster sachent comment se connecter les uns aux autres. C'est une mauvaise idée d'utiliser l'adresse 0.0.0.0 comme advertise_uri, cela doit être une adresse IP externe, pas l'adresse de socket de liaison. Sans cela, rien ne fonctionnera, donc Cartridge ne permettra tout simplement pas de démarrer un nœud avec un advertise_uri incorrect.

Maintenant que la configuration est prête, nous pouvons lancer les processus. Étant donné qu'une unité systemd normale ne permet pas de démarrer plus d'un processus, les applications sur Cartridge installent des unités dites instanciées, qui fonctionnent ainsi :

$ sudo systemctl start myapp@router
$ sudo systemctl start myapp@storage_A
$ sudo systemctl start myapp@storage_B

Dans la configuration, nous avons spécifié le port HTTP que Cartridge utilise pour gérer l'interface web — 8080. Accédons-y et voyons :

Nous constatons que les processus sont lancés mais pas encore configurés. Le cartouche ne sait pas encore qui doit se répliquer avec qui et ne peut pas prendre de décision par lui-même, il attend donc nos actions. Nous avons peu de choix : la vie d'un nouveau cluster commence par la configuration du premier nœud. Ensuite, nous ajouterons les autres au cluster, leur attribuerons des rôles, et à ce stade, le déploiement pourra être considéré comme achevé.