Slack migre vers une architecture cellulaire

• Au cours des 18 derniers mois, Slack est passé d’une architecture monolithique à une architecture cellulaire afin d’augmenter la redondance et de limiter l’impact des défaillances de site
• Cette évolution a été motivée par la nécessité d’améliorer la résilience du service Slack après l’incident de panne réseau de juin 2021, qui avait entraîné une dégradation du service pour les clients de Slack
• L’architecture cellulaire fait fonctionner chaque service comme un service virtuel par zone de disponibilité (AZ), de sorte qu’une défaillance dans une AZ n’affecte pas les autres AZ
• Elle inclut aussi une fonctionnalité permettant de drainer le trafic d’une AZ en difficulté, afin de l’isoler efficacement du reste du système
• Le mécanisme de drainage a été conçu pour être rapide, fiable, progressif et indépendant des ressources de l’AZ en cours de drainage
• La transition vers l’architecture cellulaire comprend également une stratégie de cloisonnement (siloing), qui permet aux services de ne recevoir et n’émettre du trafic qu’au sein de leur propre AZ. Cela aide à contenir toutes les défaillances à l’intérieur d’une seule AZ
• La mise en œuvre du mécanisme de déplacement du trafic s’est concentrée sur le système qui achemine les requêtes des utilisateurs vers les services centraux
• La nouvelle architecture prend en charge le drainage des AZ en s’appuyant sur des fonctionnalités d’Envoy, notamment les weighted clusters et l’attribution dynamique de poids via RTDS
• Cette transition a modifié la manière dont Slack exploite ses systèmes et construit ses services, en apportant de nouveaux outils puissants pour la gestion du trafic et l’atténuation des défaillances
• De futurs billets de blog approfondiront les détails de l’implémentation technique et examineront l’impact de cette nouvelle architecture sur les opérations de Slack

[GN⁺]

Avis Hacker News

• La migration de Slack vers une architecture cellulaire a suscité de l’intérêt en raison de son approche particulière en matière d’exploitation et de supervision.
• La stratégie de l’entreprise consiste à traiter les requêtes au sein d’une seule zone de disponibilité AWS (AZ), afin de simplifier les opérations et de faciliter la supervision.
• Cette approche permet de détecter et d’atténuer plus facilement les incidents sur un cluster unique en comparant les métriques entre les clusters.
• Cependant, cette stratégie introduit de la redondance au niveau du calcul, du cache, etc., puisque la plupart des services doivent s’exécuter sur plusieurs clusters.
• Certains utilisateurs s’interrogent sur l’efficacité du système de requêtes API de Slack, qui peut faire du fan-out vers des centaines de RPC côté backend des services.
• Un débat existe sur la différence entre l’utilisation de l’affinité avec les zones de disponibilité AWS et le simple fait d’écarter une AZ hors service au niveau du point de routage supérieur.
• Des inquiétudes ont été soulevées concernant la redondance du fait d’exécuter l’ensemble sur AWS USE1, car un problème lié à USE1 pourrait affecter plusieurs services.
• Des questions ont été posées sur la manière dont les données utilisateur sont gérées dans cette architecture, en particulier lors de la multiplication des AZ.
• Certains utilisateurs évoquent des architectures similaires sur lesquelles ils ont travaillé par le passé, comme un système d’exploitation distribué appelé Metal Cell.
• Une discussion porte sur le risque que des tâches gourmandes en ressources continuent à s’exécuter indéfiniment dans une AZ isolée, même en l’absence de nouvelles requêtes utilisateur.
• Les utilisateurs se demandent dans quel langage de programmation Slack est actuellement écrit, et si c’est toujours en Hack/PHP.
• Certains utilisateurs expriment leur déception vis-à-vis des performances de Slack, qu’ils jugent inférieures à celles d’autres applications de chat comme Discord.