rabbitmq - Ataww/SDTD-Mazerunner Wiki

RabbitMQ

Présentation générale

RabbitMQ est un middleware de Pivotal facilitant l’échange de messages entre applications présentes sur un système informatique : message broker software. RabbitMQ implémente le protocole AMQP (conçu par un consortium international) qui standardise les échanges de messages. Écrit en Erlang, RabbitMQ est open-source et un support payant est disponible. Des librairies sont disponibles pour l’écrasante majorité des langages utilisés, est compatible avec les principaux systèmes d’exploitation et bénéficie d’une large communauté d’utilisateurs. Il est utilisé par de nombreuses entreprises pour répondre à leurs besoins en échange de messages, telles que Instagram, The New York Times, Nokia, SoundCloud...

Fonctionnalitées

RabbitMQ propose les fonctionnalités suivantes :

Principes de fonctionnement

RabbitMQ propose les différents cas d'utilisation :

La compréhension de RabbitMQ se limite à deux concepts :

Dans les faits, les émetteurs créent des exchanges dans lesquelles ils publient des messages. Les récepteurs eux, viennent brancher des queues aux exchanges pour récupérer les messages.

Infrastructure mise en place

Haute disponibilité

Pour se prémunir d'une éventuelle panne d'un serveur RabbitMQ et pour garantir une disponibilité du service, RabbitMQ propose un système de cluster. Dans notre application deux serveurs RabbitMQ forme un cluster. La réplication des queues de message peut être configurée. Dans notre cas nous avons fait le choix du répliquer par défaut toutes les queues présentes.

Sécurité

L'accès au service de RabbitMQ est sécurisé par des crédentials. Deux utilisateurs existent : spark_user et neo4j_user. Les services souhaitant publier des messages au sein du cluster doivent obligatoirement être authentifiés auprès de ce dernier. Dans le cas contraire, la requête est rejetée. Là encore les droits applicable sur les utilisateurs peuvent être configurés (droit en lecture, droit en écriture, type de queue, espace virtuel, etc...). Dans notre application nous n'avons pas configuré de droit spécifique car un isolement plus fin n'était pas pertinent.

Répartition de charge / DNS

Malgré la présence d'un cluster RabbitMQ, un client qui souhaite poster/récupérer un message doit quand même spécifier le serveur sur lequel il doit se connecter. Pour supprimer au sein des clients l'intelligence de se connecter sur un serveur A ou B suivant les machines disponibles, nous avons mis en place un load balancer, ici HaProxy. Ce dernier a la responsabilité de rediriger et répartir les requêtes en fonction des machines disponibles qu'il connait. Ainsi, les clients ne se posent plus de questions. Ils n'ont à connaître qu'une seule adresse/port. Bien sur ce choix technique est critiquable. En effet, si la machine qui héberge le load balancer tombe, nous aurons une indisponibilité de service. Mais c'est un choix que nous avons fait pour décharger les clients de la problématique décrite plus haut.

Monitoring

Sur les deux machines rabbitmq-1 et rabbitmq-2 un Monit est installé. Il surveille l'état de certains services et est capable, lorsqu'il le détecte, de redémarrer les services qui seraient potentiellement hors service. La configuration de la surveillance est la suivante :

De plus, une interface de management est disponible. Elle permet de voir plusieurs paramètres concernant le cluster:

Cette interface web est disponible via l'url http://[rabbitmq-1|rabbitmq-2]:15672

Déploiement

Le déploiement des serveurs, du HaProxy et du Monit est totalement automatisé et est assuré par des scripts python. Le déroulement de cette phase est la suivante :

Remarques:

Rôle applicatif

Dans notre application, RabbitMQ fait le lien entre les demandes de recommandation pour un utilisateur faites par Mazerunner API et le calcul de la recommandation calculer par orchestrator/jobSpark. Il y a donc 2 exchanges et 2 queues (jobs_to_do et jobs_done). Le schéma suivant résume son rôle: