Hoy voy a escribir sobre la arquitectura de células de slack, me resultó muy interesante este artículo porque habla sobre un problema bastante complejo que tenía slack. Todo parte desde la promesa que ellos tienen de que en un año Slack no puede estar caído por más de una hora.
Algunos términos que considere importantes van a estar en negrita y color, lo cual significa que van a estar definidos en el glosario al final de este texto para tener su definición a mano.
Primero lo primero, la fuente, y el artículo original.
Articulo original:
https://slack.engineering/slacks-migration-to-a-cellular-architecture/
Arquitectura de Slack: el comienzo
El artículo comienza explicando que Slack estuvo en el último año y medio migrando su arquitectura y el porqué de esta migración claro. Las arquitecturas por sí solas, mucho no importan en mi opinión, es verdaderamente en los casos de uso donde realmente se aprende y se ven los pros y contras de cada patrón o diseño.
Entonces Slack decide cambiar su arquitectura de Monolito a celular, que dicho sea de paso, monolito es una de las arquitecturas más fáciles para arrancar. Está todo concentrado en un solo lugar, y se le sirvió a slack hasta hace 18 meses (cuando ya slack tiene millones de usuarios) lo primero que deduzco es que para casi cualquier cosa que tenga que arrancar de cero, los monolitos son una buena opción. Siempre, como el caso de Slack, se puede cambiar más adelante, aunque lleve un esfuerzo extra. Es lo que muchos dicen, es mejor salir rápido y ágilmente al mercado, que tardar mucho y lanzar cuando quizás te gane de mano otro producto.
Vamos a lo interesante, la arquitectura, los sistemas, la programación y todo eso que es fascinante.
¿Por qué el cambio a células, cuál es el beneficio?
Principalmente destacan que este diseño se volvió bastante popular para los servicios online, ya que incrementa la redundancia (redundancy) y limita el alcance de los errores críticos en el sistema. (IONOS, 2022) Para resumir, si nuestro sistema está dividido en células, que manejan información redundante, si una célula falla, en principio el sistema no se vería afectado ya que otra célula puede trabajar por la que falla.
¿Cómo se tomó la decisión de hacer esta inversión?
Slack tenía toda su infraestructura en una zona geográfica (us-east-1). El 30 de junio del 2021, hubo un problema de redes en la zona, y eso generó básicamente en un servicio degradado para los usuarios de slack. Si usan slack, seguro experimentaron en los últimos años este tipo de cosas, imágenes que no se ven, mensajes que llegan tarde, o canales que no cargan. Después de tratar de levantar el error, y arreglar la red, volvió a fallar causando problemas nuevamente. Esto a los ingenieros de slack los obligó a preguntarse, ¿cómo puede ser que teniendo un sistema multi regional basado en “edges” el sistema falle por la caída de una zona geográfica?
Responder eso, es bastante complejo, implica entender todo su sistema, como desde el front-end se pide la información, y de ahí cómo es que finalmente se obtiene y vuelve. El artículo menciona que “resulta que detectar fallos en sistemas distribuidos es un problema difícil. Una sola solicitud de API de Slack por parte de un usuario (por ejemplo, cargar mensajes en un canal) puede desencadenar cientos de RPCs hacia los backends del servicio, cada uno de los cuales debe completarse para devolver una respuesta correcta al usuario. Nuestros frontends de servicio intentan continuamente detectar y excluir backends fallidos, pero tenemos que registrar algunos fallos antes de poder excluir un servidor fallido.” (Bethea, 2023)
En definitiva, lo que sucedía con este fallo específico fue que todos los servicios dentro del AZ (Availability Zone) afectado tomaban a los servicios dentro de la misma zona como funcionales, pero a los externos, en otros AZ, como caídos. Entonces, es lógico que el sistema se degrade, sin entrar en detalles, si A y B están dentro del AZ us-east, pero C por algún motivo está en el AZ us-west, A y B se comunican bien entre sí, pero tomaron a C como caído y esto traería problemas en general. Distintos componentes tenían perspectivas variadas sobre la disponibilidad del sistema y esto en Slack lo denominaron como una falla gris, es decir no es que el servicio como tal no funciona, sino que está degradado.
La solución: AZs como células.
En vez de tratar de solucionar inmediatamente estas fallas grises, que pueden ser difíciles de diagnosticar y solucionar, Slack comenzó a implementar a los AZs como células, permitiéndoles crear un botón para vaciar células con fallas grises. ¿Cómo es el vaciado? De forma gradual, evitando errores que puedan ver los usuarios, y redirigiendo el tráfico de los AZs con problemas a los AZs que funcionan bien. De esta manera se pueden apagar células hasta que funcionen nuevamente. (Bethea, 2023)
El concepto de Silos
Silo se refiere a la forma gráfica que se le da a la célula, cada AZ es una célula, y cada célula contiene todos los servicios, con lo cual puede redirigir el tráfico de las células que no funcionan a otros que sí lo hagan, y de a poco se va “apagando” el que no funciona. Todas las comunicaciones entre servicios están dentro de cada célula, no hay comunicación entre AZs lo cual permite este funcionamiento.
(Bethea, 2023)
Implementación
Ya para esto, creo que amerita otro artículo porque la explicación es muy profunda y se alargaría demasiado. Pero en resumen, Slack previamente fue migrando la forma de distribuir la carga de sus websockets (load-balancers) de HAProxy a Envoy, lo cual les permitió cumplir sus objetivos de la migración a células. Los principales objetivos eran:
- La propagación a través del plano de control es del orden de segundos; los distribuidores de carga de Envoy aplicarán nuevos pesos inmediatamente.
- Los drenajes son suaves; ninguna consulta a una AZ drenada será abandonada por la capa de equilibrio de carga.
- Los pesos que se aplican ofrecen drenajes graduales con una granularidad del 1%.
- Los distribuidores de carga de los edges se encuentran en regiones completamente diferentes, y el plano de control está replicado regionalmente y es resistente contra la falla de cualquier AZ individual. (Betheas, 2023)
En definitiva, la implementación implica a través de un botón (el de drenado) se envía una señal a Rotor, su sistema in house para controlar la configuración de Envoy, y este iría moviendo la carga de un AZ a otro. En este caso, se movería la carga de us-east a cualquier otro que tenga buen servicio.
Glosario
Redundancia: La duplicación de componentes o funciones críticas de un sistema para aumentar su fiabilidad. La redundancia se utiliza a menudo en sistemas informáticos y redes para garantizar que si un componente falla, un componente de respaldo puede tomar el control, evitando el tiempo de inactividad del sistema.
AZ (Availability Zones o Zonas de Disponibilidad): Un centro de datos distinto e independiente dentro de una región geográfica específica en la infraestructura de un proveedor de nube. Cada zona de disponibilidad está diseñada para estar aislada de las fallas de otras zonas de disponibilidad y, generalmente, cuentan con alimentación, refrigeración y redes independientes.
Edges (redes): Se refiere a la frontera descentralizada de la infraestructura de red más cercana a la fuente de datos que con frecuencia es el usuario final. Esta frontera descentralizada se ha vuelto crucial en el diseño de arquitecturas modernas, especialmente con la creciente demanda de procesamiento en tiempo real y la necesidad de reducir la latencia. En términos de sistemas en la nube, edge puede abordar múltiples conceptos como redes de borde que son redes descentralizadas que conectan dispositivos de borde al núcleo de la infraestructura de la nube. Estas redes son esenciales para garantizar una comunicación rápida y segura entre los dispositivos de borde y el centro de datos centralizado.
RPCs (Llamadas de Procedimiento Remoto): Un protocolo que permite que un programa provoque la ejecución de un procedimiento o función en otro espacio de dirección (comúnmente en otra computadora en una red compartida). Permite la comunicación entre procesos, como entre un cliente y un servidor.
Load-Balancer (Distribuidor de Cargas): Un load-balancer o distribuidor de cargas es una herramienta o dispositivo que distribuye eficientemente el tráfico de red o las solicitudes entrantes a través de múltiples servidores o recursos disponibles. Su objetivo principal es optimizar el uso de recursos, maximizar el rendimiento, minimizar el tiempo de respuesta y evitar la sobrecarga de un único recurso. Los distribuidores de cargas pueden ser implementados en hardware o software y pueden basar su distribución en diferentes criterios, como la carga actual del servidor, la capacidad, la velocidad de respuesta o incluso algoritmos específicos del negocio. Además, mejoran la disponibilidad y la confiabilidad de las aplicaciones, ya que pueden redistribuir el tráfico en caso de fallo de un servidor. En arquitecturas de nube y centros de datos modernos, el uso de distribuidores de cargas es fundamental para garantizar una experiencia de usuario eficiente y estable.
Websocket: Un protocolo de comunicación que proporciona canales de comunicación dúplex completo a través de una única conexión TCP.
HaProxy: Un servidor proxy open source que ofrece alta disponibilidad, distribución de carga y capacidad de proxy para aplicaciones basadas en TCP y HTTP. Se utiliza para mejorar el rendimiento y la fiabilidad de servidores y servicios.
Envoy: Un proxy de edge y servicio diseñado para aplicaciones basadas en microservicios. Se utiliza para gestionar el tráfico de red entre microservicios y para abordar problemas relacionados con el descubrimiento de servicios, el distribucion de carga, la autenticación y otros.
Referencias
IONOS. (2022, September 26). ¿Qué es la redundancia en informática?. IONOS Digital Guide. Recurso
Bethea, C. (2023, August 22). Slack’s migration to a cellular architecture. Slack Engineering. https://slack.engineering/slacks-migration-to-a-cellular-architecture/
