PlusPlus

Défi

PlusPlus est un chatbot pour Slack conçu pour le divertissement. Il permet de plus, moins et noter les choses que vos amis disent et font sur Slack en s’adressant aux objets et aux utilisateurs avec ‘@’. Il dispose d’un classement mondial et chaque action affecte les résultats généraux.

Le défi pour l’équipe Redwerk était de réécrire complètement le bot existant, développé à l’origine en Python, en utilisant Ruby comme technologie principale. Nous avons également été chargés d’augmenter la stabilité, de permettre la mise à l’échelle et d’optimiser les performances globales de ce projet à forte charge.

Solution

Nous avons commencé par la partie la plus importante — la refactorisation et la correction du code. L’ancienne version du bot était écrite en Python et nous devions la porter vers Ruby, en tenant compte de tous les changements supplémentaires que cela pourrait impliquer, en corrigeant les problèmes existants et en implémentant de nouvelles fonctionnalités. Lors de la planification de l’infrastructure, nous avons basé nos hypothèses sur la charge moyenne d’utilisation de l’ancien bot Python : environ 500 à 700 000 actions utilisateur par minute. Nous avons étendu ce niveau jusqu’à environ 1 million d’actions utilisateur par minute afin d’avoir une capacité de réserve et avons effectué une série de tests de charge sur staging.

Et c’est là qu’un autre défi est apparu. Il s’est avéré que Slack limite les tests à 1 message par seconde et ne dispose pas de la fonctionnalité pour tester des projets à forte charge. La charge réelle en production de PlusPlus a montré plus de 20 à 50 millions d’actions par minute, et l’infrastructure existante ne pouvait pas la supporter. Pour répondre à cette nouvelle demande, une grande partie de la logique de l’application a dû être retravaillée.

Optimisation de la logique des utilisateurs et des objets

L’équipe de développement de Redwerk a dû définir et optimiser soigneusement toutes les lacunes, même les plus petites fuites de mémoire et d’utilisation du CPU. La charge réelle du projet envoyait des millions d’actions contenant à la fois des @usernames et des @things sur une seule ligne. Les objets nécessitaient une logique plus avancée que les utilisateurs, car il fallait les analyser, vérifier s’ils existaient dans la base de données, en créer une nouvelle entrée s’ils n’existaient pas, puis mettre à jour le score, le classement et les tendances globales. Avec des millions d’actions de ce type, dont la plupart se produisant au sein d’un seul message, cela surchargeait très rapidement la base de données, ainsi que la mémoire et le CPU.

Une autre tâche à forte charge consistait à optimiser les mises à jour de scores dans les classements, car chaque action devait influencer la position dans les classements globaux des utilisateurs et des objets. L’incroyable quantité d’éléments qui devaient être analysés, vérifiés et mis à jour, a créé des défis supplémentaires pour le développement.

Afin d’optimiser toutes ces actions, notre équipe a développé une fonctionnalité qui utilise plusieurs cœurs de CPU sur chaque serveur, ainsi qu’un Bot Manager spécifique, qui achemine chaque bot vers un nœud spécifique (Serveur + cœur CPU) — un type de tâche qu’un Amazon load balancer ne pouvait pas gérer. Après cela, nous avons reconstruit la logique des requêtes pour réduire le nombre de requêtes.

Nous sommes également passés d’Ubuntu à CentOS. Ubuntu ne nous permettait pas de créer des connexions supplémentaires à une base de données. CentOS, quant à lui, offrait un environnement plus stable lors du travail avec MongoDB et supportait la charge d’actions excessive. Il nous a également permis de reconfigurer les serveurs AWS et de mettre à jour les paramètres du noyau du système d’exploitation sur les nœuds pour améliorer les limites de descripteurs de fichiers et de threads.