Cartouche Tarantool: Sharding Lua Backend en trois lignes

Dans Mail.ru Group, nous avons Tarantool, un serveur d'applications basé sur Lua et une base de données unie. C'est rapide et élégant, mais les ressources d'un seul serveur sont toujours limitées. La mise à l'échelle verticale n'est pas non plus la panacée. C'est pourquoi Tarantool a quelques outils pour la mise à l'échelle horizontale, ou le module vshard [1] . Il vous permet de répartir les données sur plusieurs serveurs, mais vous devrez les bricoler pendant un certain temps pour les configurer et renforcer la logique métier.

Bonne nouvelle: nous avons obtenu notre part de bosses (par exemple, [2] , [3] ) et avons créé un autre framework, ce qui simplifie considérablement la solution à ce problème.

Tarantool Cartridge est le nouveau cadre de développement de systèmes distribués complexes. Il vous permet de vous concentrer sur l'écriture de la logique métier au lieu de résoudre les problèmes d'infrastructure. Sous la coupe, je vais vous dire comment ce cadre fonctionne et comment il pourrait aider à écrire des services distribués.

Alors quel est exactement le problème?

Nous avons Tarantool et vshard - que voulons-nous de plus?

Premièrement, c'est une question de commodité. Vshard est configuré dans les tables Lua. Mais pour qu'un système distribué de plusieurs processus Tarantool fonctionne correctement, la configuration doit être la même partout. Personne ne voudrait le faire manuellement, donc toutes sortes de scripts, d'Ansible et de systèmes de déploiement sont utilisés.

La cartouche elle-même gère la configuration vshard sur la base de sa propre configuration distribuée . En fait, il s'agit d'un simple fichier YAML, et sa copie est stockée sur chaque instance de Tarantool. En d'autres termes, le framework surveille sa configuration pour qu'il en soit de même partout.

Deuxièmement, c'est encore une question de commodité. La configuration Vshard n'est pas liée au développement de la logique métier et ne distrait qu'un développeur de son travail. Lorsque nous discutons de l'architecture d'un projet, la question concerne très probablement des composants séparés et leur interaction. Il est encore trop tôt pour penser à déployer un cluster pour 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 afin de simplifier le travail avec l'application tout au long de son cycle de vie: création, développement, test, CI / CD, maintenance.

La cartouche introduit le concept de rôles pour chaque processus Tarantool. Les rôles permettent au développeur de se concentrer sur l'écriture de code. Tous les rôles disponibles dans le projet peuvent être exécutés sur la seule instance de Tarantool, ce qui serait suffisant pour les tests.

Caractéristiques principales de la cartouche Tarantool:

• orchestration automatisée des clusters;
  
• fonctionnalité d'application étendue avec de nouveaux rôles;
  
• modèle d'application pour le développement et le déploiement;
  
• sharding automatique intégré;
  
• intégration avec le framework Luatest;
  
• gestion de cluster à l'aide de WebUI et API;
  
• outils de packaging et de déploiement.
  

Bonjour tout le monde!

J'ai hâte de vous montrer le cadre lui-même, alors sauvegardons l'histoire de l'architecture pour plus tard et commençons par une tâche facile. En supposant que Tarantool est déjà installé, tout ce que nous avons à faire est

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

En conséquence, les utilitaires de ligne de commande sont installés, ce qui vous permet de créer votre première application à partir du modèle:

 $ cartridge create --name myapp 

Et voici ce que nous obtenons:

 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/ 

Ceci est un référentiel git avec un "Hello, World!" Prêt à l'emploi application. Essayons de l'exécuter après avoir installé les dépendances (y compris le framework lui-même):

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

Nous avons lancé un nœud de notre future application fragmentée. Si vous êtes curieux, vous pouvez immédiatement ouvrir l'interface Web, qui fonctionne sur localhost : 8080, utiliser une souris pour configurer un cluster à un nœud et profiter du résultat, mais ne vous excitez pas trop tôt. L'application ne sait pas comment faire quoi que ce soit d'utile pour l'instant, je vais donc vous parler du déploiement plus tard, et maintenant il est temps d'écrire du code.

Développer des applications

Imaginez que nous concevions un système qui devrait recevoir des données, les enregistrer et créer un rapport une fois par jour.


Nous dessinons donc un diagramme avec trois composants: passerelle, stockage et ordonnanceur. Continuons à travailler sur l'architecture. Puisque nous utilisons vshard comme stockage, ajoutons vshard-router et vshard-storage au diagramme. Ni la passerelle ni le planificateur n'accéderont directement au stockage - un routeur est explicitement créé pour cette tâche.


Ce diagramme semble abstrait car les composants ne reflètent toujours pas ce que nous allons créer dans le projet. Nous devrons voir comment ce projet correspond au vrai Tarantool, nous regroupons donc nos composants par processus.


Il n'est pas très judicieux de conserver vshard-router et gateway sur des instances distinctes. Pourquoi irions-nous à nouveau sur le réseau, si cela est déjà la responsabilité du routeur? Ils doivent s'exécuter dans le même processus, c'est-à-dire que la passerelle et vshard.router.cfg doivent être initialisés dans le même processus et interagir localement.

Pendant la phase de conception, il était pratique de travailler avec trois composants, mais en tant que développeur, je ne veux pas penser à lancer trois instances de Tarantool lors de l'écriture de code. J'ai besoin d'exécuter les tests et de vérifier que j'ai correctement écrit le code de la passerelle. Ou je veux peut-être montrer une nouvelle fonctionnalité à mes collègues. Pourquoi devrais-je prendre des problèmes avec le déploiement de trois instances? Ainsi, le concept de rôles est né. Un rôle est un module Lua régulier, et la cartouche gère son cycle de vie. Dans cet exemple, il y en a quatre: passerelle, routeur, stockage et planificateur. Un autre projet peut avoir plus de rôles. Tous les rôles peuvent être lancés en un seul processus, et ce serait suffisant.


Et lorsque le problème concerne le déploiement vers la mise en production ou la production, nous attribuons un ensemble de rôles distinct à chaque processus Tarantool en fonction des capacités matérielles sous-jacentes:

Gestion de la topologie

Nous devons également stocker des informations sur les rôles en cours d'exécution quelque part. Et "quelque part" signifie la configuration distribuée susmentionnée. La chose la plus importante ici est la topologie de cluster. Vous pouvez voir ici 3 groupes de réplication de 5 processus Tarantool:


Nous ne voulons pas perdre les données, nous traitons donc les informations sur les processus en cours avec soin. La cartouche surveille la configuration à l'aide d'une validation en deux phases. Dès que nous voulons mettre à jour la configuration, il vérifie d'abord si les instances sont disponibles et prêtes à accepter la nouvelle configuration. Après cela, la configuration est appliquée dans la deuxième phase. Ainsi, même si une instance est temporairement indisponible, alors rien ne peut mal tourner. La configuration ne sera tout simplement pas appliquée et vous verrez une erreur à l'avance.

La section topologie a également un paramètre aussi important que le leader de chaque groupe de réplication. Il s'agit généralement de l'instance qui accepte les écritures. Les autres sont le plus souvent en lecture seule, bien qu'il puisse y avoir des exceptions. Parfois, les développeurs courageux n'ont pas peur des conflits et peuvent écrire des données sur plusieurs répliques en même temps. Néanmoins, certaines opérations ne doivent pas être effectuées deux fois. C'est pourquoi nous avons un leader.

Cycle de vie des rôles

Pour qu'une architecture de projet contienne des rôles abstraits, le cadre doit en quelque sorte être capable de les gérer. Naturellement, les rôles sont gérés sans redémarrer le processus Tarantool. Il existe quatre rappels conçus pour la gestion des rôles. La cartouche elle-même les appelle en fonction des informations de la configuration distribuée, appliquant ainsi la configuration aux rôles spécifiques.

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

Chaque rôle a une fonction init . Il est appelé une fois: soit lorsque le rôle est activé, soit lorsque Tarantool redémarre. Ici, il est pratique, par exemple, d'initialiser box.space.create, ou le planificateur peut exécuter une fibre d'arrière-plan qui terminerait la tâche à intervalles réguliers.

La fonction init seule peut ne pas suffire. La cartouche permet aux rôles d'accéder à la configuration distribuée utilisée pour stocker la topologie. Dans la même configuration, nous pouvons déclarer une nouvelle section et y stocker une partie de la configuration métier. Dans mon exemple, cela pourrait être un schéma de données ou des paramètres de planification pour le rôle de planificateur.

Le cluster appelle validate_config et apply_config chaque fois que la configuration distribuée change. Lorsqu'une configuration est appliquée dans une validation en deux phases, le cluster vérifie que chaque rôle sur chaque serveur est prêt à accepter cette nouvelle configuration et, si nécessaire, signale une erreur à l'utilisateur. Lorsque tout le monde est d'accord avec la configuration, apply_config est appelé.

Les rôles prennent également en charge une méthode d' stop pour nettoyer les ordures. Si nous disons que l'ordonnanceur n'est pas nécessaire sur ce serveur, il peut arrêter les fibres qu'il a commencé à utiliser init .

Les rôles peuvent interagir les uns avec les autres. Nous sommes habitués à écrire des appels de fonction Lua, mais le processus peut ne pas avoir le rôle nécessaire. Pour faciliter l'accès au réseau, nous utilisons un module auxiliaire appelé rpc (appel de procédure distante), qui est construit sur la base du module standard Tarantool net.box. Cela peut être utile, par exemple, si votre passerelle souhaite demander directement au planificateur d'effectuer la tâche maintenant, plutôt qu'en une journée.

Un autre point important est d'assurer la tolérance aux pannes. La cartouche utilise le protocole SWIM [4] pour surveiller la santé. En bref, les processus échangent des «rumeurs» via UDP, c'est-à-dire que chaque processus informe ses voisins des dernières nouvelles, et ils répondent. S'il n'y a soudainement pas de réponse, Tarantool soupçonne que quelque chose ne va pas, et après un certain temps, il déclare la mort et envoie ce message à tout le monde.


Sur la base de ce protocole, Cartridge organise le basculement automatique. Chaque processus surveille son environnement et si le leader cesse soudainement de répondre, la réplique pourrait revendiquer son rôle et Cartridge configurerait les rôles en cours d'exécution en conséquence.


Vous devez être prudent ici car des allers-retours fréquents peuvent entraîner des conflits de données lors de la réplication. Le basculement automatique ne doit certainement pas être activé de manière aléatoire. Vous devez avoir une idée claire de ce qui se passe et être sûr que la réplication ne plantera pas lorsque le leader récupère et retrouve sa couronne.

D'après tout ce qui a été dit, les rôles peuvent sembler similaires aux microservices. Dans un sens, ils ne sont que des modules dans les processus Tarantool, et il existe plusieurs différences fondamentales. Tout d'abord, tous les rôles de projet doivent vivre dans la même base de code. Et tous les processus Tarantool devraient s'exécuter à partir de la même base de code, afin qu'il n'y ait pas de surprise, comme lorsque nous essayons d'initialiser le planificateur, mais qu'il n'y a tout simplement pas de planificateur. De plus, nous ne devons pas autoriser de différences dans les versions de code car le comportement du système est compliqué à prévoir et à déboguer dans une telle situation.

Contrairement à Docker, nous ne pouvons pas simplement prendre une "image" d'un rôle, le transférer sur une autre machine et l'exécuter là-bas. Nos rôles ne sont pas aussi isolés que les conteneurs Docker. De plus, nous ne pouvons pas exécuter deux rôles identiques sur la même instance. Le rôle est là ou non; dans un sens, c'est un singleton. Et troisièmement, les rôles devraient être les mêmes au sein de l'ensemble du groupe de réplication, car sinon, cela aurait l'air ridicule: les données sont les mêmes, mais le comportement est différent.

Outils de déploiement

J'ai promis de vous montrer comment la cartouche pourrait aider à déployer des applications. Pour vous faciliter la vie, le framework crée des packages RPM:

 $ cartridge pack rpm myapp # will create ./myapp-0.1.0-1.rpm $ sudo yum install ./myapp-0.1.0-1.rpm 

Le package installé contient presque tout ce dont vous avez besoin: à la fois l'application et les dépendances Lua installées. Tarantool arrive également sur le serveur en tant que dépendance de package RPM, et notre service est prêt à être lancé. Tout cela se fait en utilisant systemd, mais d'abord, nous devons faire une configuration, au moins spécifier l'URI de chaque processus. Trois suffiraient pour notre exemple.

 $ 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 un aspect intéressant à prendre en compte: au lieu de ne spécifier que le port du protocole binaire, nous spécifions l'adresse publique de l'ensemble du processus, y compris le nom d'hôte. Nous le faisons parce que les nœuds de cluster doivent savoir comment se connecter les uns aux autres. Ce serait une mauvaise idée d'utiliser l'adresse 0.0.0.0 comme advertise_uri, car ce devrait être une adresse IP externe, plutôt qu'une liaison de socket. Rien ne fonctionne sans cela, donc Cartridge ne laisserait tout simplement pas le nœud avec le mauvais advertise_uri démarrer.

Maintenant que la configuration est prête, nous pouvons démarrer les processus. Étant donné qu'une unité systemd régulière ne permet pas de démarrer plusieurs processus, les unités dites instanciées installent les applications sur la cartouche:

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

Nous avons spécifié le port HTTP pour l'interface Web de la cartouche dans la configuration: 8080. Allons là-bas et jetons un œil:


Nous pouvons voir que les processus ne sont pas encore configurés, bien qu'ils soient déjà en cours d'exécution. La cartouche ne sait pas encore comment la réplication doit être effectuée et ne peut pas décider seule, elle attend donc nos actions. Nous n'avons pas beaucoup de choix: la vie d'un nouveau cluster commence par la configuration du premier nœud. Ensuite, nous ajoutons d'autres nœuds au cluster, nous leur attribuons des rôles et le déploiement peut être considéré comme terminé avec succès.

Versons-nous un verre et relaxons après une longue semaine de travail. L'application est prête à l'emploi.

Résultats

Et les résultats? Veuillez tester, utiliser, laisser des commentaires et créer des tickets sur Github.

Les références

[1] Tarantool »2.2» Référence »Référence Rocks» Module vshard
[2] Comment nous avons mis en œuvre le cœur de métier d'investissement d'Alfa-Bank basé sur Tarantool
[3] Architecture de facturation de nouvelle génération: transition vers Tarantool
[4] SWIM - Cluster Building Protocol
[5] GitHub - tarantool / cartouche-cli
[6] GitHub - tarantool / cartouche