Le Storm User Group, c’est une initiative de quelques collègues autour du « big data temps réel ». Aujourd’hui, nous parlons de Storm et quelques infrastructures qui peuvent s’y connecter. Demain, il s’agira peut-être de Spark ou d’autres…

Halte là ! Je vais peut-être un peu vite ? Et d’abord, Storm, qu’est-ce que c’est ? Voilà une question à laquelle une partie de cette première rencontre va être consacrée.

Oui, Storm, qu’est-ce que c’est ?

C’est Florian Hussonois qui va répondre à cette question. Nous pourrions résumer la chose en déclarant simplement qu’il s’agit d’un Hadoop « temps réel ». Il s’agit en quelque sorte d’un middleware permettant le traitement d’évènements en mode flux.

Un (petit) peu d’historique

Storm a été développé par Nathan Marz chez BackType en 2011. La société est rachetée ensuite par Twitter qui promeut le projet et le passe en Open-Source. La première release officielle date de 2011. En Septembre 2014, le projet devient officiellement « Apache Top Level Project » alors même qu’il n’a pas encore atteint la release 1.0 !

Ecrit principalement en Clojure et en Java, ce « processeur d’évènements » est conçu pour traiter un flux de très nombreux évènements (des tuples dans la terminologie Storm), à savoir 1 millions de tuples par seconde et par noeud (1 seul coeur processeur), avec tolérance aux fautes, gestion de la scalabilité et garantie de traitement !

Les concepts clés

Pour bien comprendre Storm, il faut en saisir les concepts de base.

• Le Tuple : Nous en avons parlé, il s’agit de l’unité d’information à traiter. C’est l’évènement.
• Le Stream : c’est une séquence illimitée de tuples.
• Le Spout : C’est un connecteur producteur de tuples. En pratiques, ce sont des composants source de données. Il en existe de nombreux types (dans le projet officiel et en dehors) pour se connecter à différentes infrastructures.
• Le Bolt : Il s’agit du composant de traitement élémentaire. Il consomme bien entendu des tupples et peut en produire (mais pas obligatoirement). Il peut aussi se connecter à une base de données, par exemple.
• La Topologie : il s’agit de la structure de déploiement de votre configuration Storm. Dans la pratique, il s’agit d’un graphe acyclique (DAG).
• Groupements de streams : Si les bolts peuvent « splitter » des streams (façon CBR) ou les multicaster, ils peuvent aussi les regrouper. Il existe 7 types de regroupements.

Le parallélisme est intrinsèque à Storm. Chaque Bolt peut être instancié plusieurs fois (on les appellent « task »). Chaque tâche est prise en charge par un Executor qui correspond dans la pratique à un thread. Storm prend en charge la répartition des Executors sur des Workers (qui correspondent à une JVM). Chaque Worker devant être géré par un Supervisor. Ce dernier point est important, car les Workers peuvent tomber ! Un petit dessin vaut parfois mieux qu’un long discours…

Pour gérer et faire tourner l’ensemble, Storm met à notre disposition 3 briques importantes :

• Le Supervisor : nous en avons parlé, il gère un Worker, le relançant si nécessaire, et permet de surveiller sa charge.
• Zookeeper, qui a en charge de gérer une topologie
• Nimbus, qui gère les masters des topologies. Il doit lui-même tourner sous supervision.

Traiter en toute quiétude

Les graphes de traitement de Storm peuvent devenir des arbres très complexes ! Toutefois Storm s’y entend pour reconnaitre si un Tuple entrant a été traité sur la totalité de son arbre. Tout d’abord chaque Tuple a son id (sur 64 bits). Nathan Marz a développé un algorithme très complexe, basé sur le XOR pour identifier si un arbre a été complètement traité. Bien entendu, chaque Bolt opère son acquittement local, c’est le « Ack ».

Florian passe rapidement sur Trident qui permet d’assurer une sémantique « exactement 1 » aux traitements. J’avoue que le sujet est passé trop rapidement pour moi. Peut-être une occasion de creuser le sujet ultérieurement ? Il en va de même pour la fonctionnalité DRPC.

Si vous avez raté le live et que ma prose vous laisse de marbre, voici l’enregistrement de l’intervention de Florian lui-même !

Storm et Redis chez Twitter Foot

Ce retour nous était proposé par Benjamin Houdu. Cette présentation m’intéressait d’autant plus que j’ai participé au début de ce projet. Et je dois dire que ce dont Benjamin nous a gratifié est probablement le meilleur retour d’expérience auquel j’ai pu assister !

Le projet

Comme son nom l’indique, Twitter Foot traite des flux Twitter, suivant des comptes identifiés par l’AFP (7000 comptes sur 5 ligues), pour fabriquer des timelines spécialisées et toute sortes de statistiques, comme des tendances, la détection de viralité ou de popularité.

Techniquement, les particularités de cette mise en oeuvre de Storm repose d’une part sur la connexion Twitter via la streaming API en utilisant le connecteur Hosebird, et d’autre part sur la mise en oeuvre conjointe de Redis, un base NoSQL de type clé-valeur fonctionnant en mémoire. Redis est d’ailleurs très exploité ici, car on en fait un triple usage :

• Pour bufferiser le flux Twitter et alimenter le stream Storm. Incidemment, cela rend l’architecture plus testable, car les tests peuvent être faits simplement en peuplant Redis, sans connexion à Twitter, avec en prime la maitrise sur les données injectées !
• Pour sauvegarder les données de référence : aussi bien la topologie que l’on va injecter dans Zookeeper que les comptes sur lesquels on a des abonnements.
• En frontal, pour exposer les timelines résultantes et les données statistiques !

En pratique, la topologie est constituée de 3 machines abritant chacun un worker, auxquelles il faut rajouter le serveur frontal abritant le serveur Rest qui expose les services ainsi construits.

Et bien sûr, il y a le serveur hébergeant Redis !

Justement Redis, qu’est-ce que c’est ?

Nous l’avons dit, il s’agit d’une base NoSQL de type clé-valeur fonctionnant en mémoire. On devinera que ces choix l’orientent vers la performance, ce qui explique les autres choix techniques : elle est écrite en C et est … monothreadée ! Ce dernier choix peut paraitre curieux, mais de fait, il évite de devoir gérer les problèmes de contention. Il se justifie aussi par les excellentes performances de la base dont les requêtes sont non seulement traitées rapidement, mais aussi peu sensibles à l’augmentation de volume : la plupart des fonctions proposées ont des indices de performance en O (Log (n)) !

Parmi les fonctionnalités intéressantes de cette base, on pourra noter dans le désordre :

• La présence d’une API de type « publish / subscribe » bien pratique entre autre pour le débug !
• La présence de connecteurs pour un grand nombre de langages.
• La mise à disposition de structures intelligentes : sorted sets, Z sets, etc. qui permettent non seulement de retrouver un élément, mais de sélectionner un « range » d’éléments. Une fonctionnalité qui s’avérera particulièrement précieuse dans le cas d’utilisation de Twitter Foot !
• La présence d’un langage de script basé sur Lua qui permet d’écrire l’équivalent de procédures stockées dont l’atomicité d’opération est garantie par l’architecture monothreadée de la base !
• L’accès en mode interactif en ligne de commande, via redis-cli pour travailler sur la base en mode non programmatique.

Storm, au coeur de Twitter Foot !

Nous n’allons pas revenir sur le descriptif général de Storm que Florian a fort bien abordé. Benjamin attire toutefois notre attention sur les changements importants survenus entre les versions 0.8.x et 0.9.x, la première dépendait fortement de Zero MQ, ce qui n’est plus le cas des versions ultérieures. Il met aussi l’accent sur l’intérêt de Storm UI d’un point de vue opérationnel, surtout pour savoir quel tâche tourne sur quel worker ! En effet, il faudra abandonner l’idée que l’on traite l’affinité des tâches sur les workers / machines, c’est Storm qui gère cela.

En fait, l’un des enseignements que tire Twitter Foot, c’est que l’administration est un volet du projet aussi important que le développement, et il faut y faire face le plus tôt possible dans le projet ! Autre difficulté, la configuration dont les changements imposent des redémarrages de topologies. C’était une contrainte trop forte pour Twitter Foot, aussi l’équipe a-t-elle traité la configuration comme un Stream traversant les Bolts !

Des fenêtres bien glissantes…

Un concept est rapidement apparu sur Twitter Foot : la nécessité de faire des statistiques sur une durée fixe, mais relative au temps présent. Ce que l’on a appelé des « fenêtres glissantes », c’est à dire entre T0 et T-n minutes (ou heures, ou jours), avec un échantillonnage représentant la résolution de ces statistiques en x minutes ! Vous pouvez aussi dire « sliding windows » pour briller dans les salons, mais ne cherchez pas sur Google, c’est un concept maison !

Plusieurs essais d’implémentations en ont été faites. Benjamin nous parle de deux d’entre-elles.

Tout d’abord, on peut s’appuyer sur un concept Storm : les Rolling Buffers. Ils sont plutôt complexes à mettre en oeuvre, mais ils présentent entre autre l’avantage de gérer automatiquement l’éviction des échantillons quittant la fenêtre glissante !

Autre possibilité : s’appuyer sur les ZSets de Redis. Redis permet même d’opérer des aggrégations par x minutes et donc de gérer pratiquement automatiquement l’échantillonnage ! Par contre l’éviction des vieux échantillons doit se faire programmatiquement.

Quelques mots sur la testabilité

J’ai été agréablement surpris de voir Benjamin aborder ce point finalement assez déconnecté des problématiques purement techniques de Storm (bien qu’il y ait bien sûr des corolaires techniques). Le projet a en effet mis en oeuvre tôt dans ses premières phases une approche ATDD impliquant le client et s’appuyant sur le paradigme « Given When Then » outillé avec Cucumber JVM. Cette approche a réellement permit une convergence et appréhension fine des fonctionnements attendus.

D’un point de vue technique, il a été possible de se servir de l’alimentation par Redis pour effectuer ces tests déconnecté de Twitter en injectant dans Redis des Tweets « forgés ». Autre point délicat, la nécessité de ne pas redémarrer la topologie entre chaque tests afin de garder des temps d’exécution raisonnables.

Et le monitoring ?

Nous l’avons dit, avec Storm on fait beaucoup d’administration, ce qui a quelques implications.

D’abord, plus encore qu’ailleurs, les opérations réalisées fréquemment doivent être en « push button ». Jenkins est d’une aide appréciable à ce niveau.

Le Storm Supervisor : il est indispensable, et il en faut un par machine.

L’équipe a aussi utilisé avec bénéfice Monit, un watchdog qui s’est avéré d’une grande utilité. Notre orateur est dithyrambique à ce sujet !

Du côté de Redis, c’est redis-rdb-tools qui s’est avéré indispensable. Le gros avantage est le parse des logs offline, donc sans impacter la machine de production. Dans la pratique, beaucoup d’investigations peuvent être menées à bien en différé.

Si on a réellement besoin de connaitre l’état de santé de l’instance en live, il y a … Redis Live !

Quelques mots sur le débug et les best practices

L’investigation de problèmes sur une architecture Storm peut très facilement se transformer en chemin de croix ! Il faut anticiper cela au niveau de la conception et penser les Bolts avec des responsabilités bien séparées (principe SRP de Bob Martin). En fait, Benjamin nous suggère de séparer les Bolts de contrôle des Bolts d’action !

Même chose sur Redis : bien séparer les actions d’insertion des actions de nettoyage.

Enfin, même les topologies peuvent être décomposées, une leçon qui est arrivée hélas bien tardivement sur Twitter Foot ! De plus petites topologies se testent plus facilement et sont plus robustes. Mais attention, ne pensez pas mutualiser les workers : un worker ne peut appartenir qu’à une topologie.

Autre problème bien connu, celui de l’auditabilité : comment retrouver l’origine du problème ? L’équipe Twitter Foot nous propose la technique du « Carbon dating » : injecter dans les Tuples des informations de trace des Bolts traversés !

Du côté Redis enfin, si l’aspect « sans schéma » est apparemment une liberté bienvenue, on touche vite les limites de ce manque de typage. Ici, c’est l’emploi de json-schema que vient nous recommander l’équipe.

Si vous préféreez la présentation de benjamin in extenso, ne pleurez plus, la voici !

Ce que j’en ai pensé

Je l’ai dit au début : l’orateur nous a gratifié là d’un retour d’expérience d’un niveau de qualité que j’ai rarement (jamais ?) vu !

La mise en oeuvre d’un projet avec Storm est réellement quelque chose de complexe. On perçoit cette impression rapidement, mais les dimensions de cette complexité apparaissent clairement dans cette présentation !

Mais on va plus loin ici : les voies à explorer, les points d’attention dans le projet, les outils indispensables et leur utilité, tout nous est clairement exposé. Un grand bravo !