Architecture de messagerie en temps réel chez Slack

Slack a récemment publié comment il envoie quotidiennement des millions de messages en temps réel à travers le monde. L’entreprise donne un aperçu complet de son Pub/sous-marin architecture, conçue pour gérer les messages en temps réel à grande échelle. Il met en évidence les défis uniques posés par la diffusion de messages en temps réel dans différents fuseaux horaires et régions et la façon dont les ingénieurs de Slack ont ​​conçu l’infrastructure pour les gérer.

Sameera Tanguduingénieur logiciel senior chez Slack, explique l’importance de cette architecture :

Nos serveurs servent des dizaines de millions de canaux par hôte, des dizaines de millions de clients connectés, et notre système envoie des messages à travers le monde en 500 ms. Grâce à l’évolutivité linéaire de notre architecture actuelle, nos projections montrent que nous pouvons servir beaucoup plus de clients.

Elle déclare que l’entreprise prévoit d’améliorer son architecture pour servir une clientèle plus importante.

Le backend du système est composé de plusieurs services. Les serveurs de canaux (CS) sont des serveurs en mémoire avec état contenant l’historique des canaux. Un mécanisme de hachage cohérent mappe chaque CS à un sous-ensemble de canaux. Aux heures de pointe, chaque hôte dessert environ 16 millions de canaux. Les gestionnaires d’anneaux de hachage cohérents (CHARM) gèrent l’anneau de hachage cohérent pour les CS, garantissant le remplacement des CS défectueux dans les 20 secondes. Consul stocke la configuration à jour des hachages cohérents.

Source:

Les serveurs de passerelle (GS), comme les CS, sont des serveurs en mémoire avec état. Ils maintiennent les informations des utilisateurs et les abonnements aux canaux WebSocket et agissent comme une interface entre les clients Slack et les CS. Les GS sont déployés dans plusieurs régions géographiques pour optimiser les vitesses de connexion. Les serveurs d’administration (AS) sont des serveurs en mémoire sans état qui s’interfacent entre le backend de l’application Web et les CS. Enfin, les serveurs de présence (PS) suivent les utilisateurs en ligne, alimentant les points de présence verts dans les clients Slack.

Chaque client Slack dispose d’une connexion WebSocket persistante aux serveurs de Slack pour recevoir des événements en temps réel afin de maintenir son état. Le client configure une connexion WebSocket en plusieurs étapes, telles que la récupération du jeton utilisateur et des informations de configuration de la connexion WebSocket à partir du backend Webapp. Ensuite, le client initie une connexion WebSocket à la région périphérique la plus proche, et GS récupère les informations de l’utilisateur et envoie le premier message au client. Envoyé charge équilibre le trafic entrant et gère la terminaison TLS.

Source:

Une fois la configuration du client terminée, chaque message envoyé dans un canal est diffusé à tous les clients en ligne dans le canal. Les messages transitent par l’API Webapp, l’AS et le CS avant d’être envoyés à chaque GS abonné dans le monde. Chaque GS qui reçoit le message l’envoie à chaque client connecté abonné à cet ID de canal.

Source:

Outre les messages de chat, les événements sont un autre type de message qui modifie l’état du client en temps réel. Les événements transitoires, tels qu’un utilisateur tapant dans un canal, suivent un flux légèrement différent car une base de données ne conserve pas ces événements. Le schéma ci-dessous illustre ce flux.

Source: