Slack migra a una arquitectura celular

• Slack pasó los últimos 1.5 años cambiando de una estructura única a una estructura basada en celdas (Cellular Architecture) para aumentar la redundancia y limitar el impacto de las fallas del sitio
• El cambio fue impulsado por la necesidad de mejorar la resiliencia del servicio de Slack después del incidente de junio de 2021, cuando una interrupción de red causó degradación del servicio para los clientes de Slack
• La arquitectura celular hace que cada servicio opere como un servicio virtual por zona de disponibilidad (AZ), de modo que una falla en una AZ no afecte a las demás
• También incluye una función para drenar el tráfico desde una AZ con problemas, aislándola de forma efectiva del resto del sistema
• El mecanismo de drenaje fue diseñado para ser rápido, sin errores, gradual e independiente de los recursos de la AZ que está siendo drenada
• La transición a una arquitectura celular incluyó una estrategia llamada siloing, que permite que los servicios solo reciban y envíen tráfico dentro de su propia AZ. Esto ayuda a contener cualquier falla dentro de una sola AZ
• La implementación del mecanismo de movimiento de tráfico se centró en el sistema que enruta las consultas de los usuarios hacia los servicios centrales
• La nueva arquitectura aprovecha funciones de Envoy, como weighted clusters y la asignación dinámica de pesos mediante RTDS, para soportar el drenaje de AZ
• Esta transición cambió la forma en que Slack opera y construye sus servicios, y le dio nuevas herramientas sólidas para la gestión del tráfico y la mitigación de fallas
• En futuras publicaciones del blog profundizarán en los detalles de implementación técnica y discutirán cómo la nueva arquitectura impactó las operaciones de Slack

[GN⁺]

Comentarios en Hacker News

• La migración de Slack a una arquitectura celular despertó interés por su enfoque particular de operación y monitoreo.
• La estrategia de la empresa consiste en resolver las solicitudes dentro de una sola zona de disponibilidad (AZ) de AWS, simplificar las operaciones y facilitar el monitoreo.
• Este enfoque permite detectar y mitigar con facilidad incidentes en un solo clúster al comparar métricas entre clústeres.
• Sin embargo, esta estrategia genera redundancia en cómputo, caché y otros recursos, ya que la mayoría de los servicios deben ejecutarse en varios clústeres.
• Algunos usuarios cuestionan la eficiencia del sistema de solicitudes API de Slack, ya que puede hacer fan-out de cientos de RPC hacia los backends de servicio.
• Hay debate sobre la diferencia entre usar afinidad con zonas de disponibilidad de AWS y simplemente descartar una AZ caída en un punto de enrutamiento superior.
• Se plantearon preocupaciones sobre la redundancia de ejecutar todo en AWS USE1, ya que los problemas relacionados con USE1 podrían afectar a múltiples servicios.
• También surgieron dudas sobre cómo se manejan los datos de los usuarios en esta arquitectura, especialmente en caso de fallas de una AZ.
• Algunos usuarios recordaron arquitecturas similares en las que trabajaron en el pasado, como un sistema operativo distribuido llamado Metal Cell.
• Se discutió el posible problema de que tareas que consumen muchos recursos sigan ejecutándose indefinidamente en una AZ aislada, incluso si ya no llegan nuevas solicitudes de usuarios.
• Los usuarios sienten curiosidad por saber en qué lenguaje de programación está escrito Slack actualmente, y preguntan si sigue siendo Hack/PHP.
• Algunos usuarios expresaron decepción con el rendimiento de Slack y lo compararon desfavorablemente con otras apps de chat como Discord.