93

El algoritmo detrás del chat en Platzi Conf 2021

6492Puntos

hace un mes

Curso Profesional de Arquitectura de Software
Curso Profesional de Arquitectura de Software

Curso Profesional de Arquitectura de Software

Aprender como escribir buen código es el primer paso, conocer diferentes tecnologías y saber cómo, cuándo y por qué usar una u otra dependiendo de los requerimientos del negocio es trabajo de un arquitecto de software. Conoce diferentes patrones de arquitectura, herramientas y estrategias para desarrollar software a nivel profesional.

Hoy te contaré un par de cosas que el equipo de Producto en Platzi, estuvo iterando para poder brindarles la mejor experiencia dentro de la plataforma.

La 15ava edición de Platzi Conf se desarrolló completamente en linea, todos los equipos trabajaron en sinergia para poder superar los retos y brindarles el contenido de mayor valor en la región para así seguir impulsando nuestra economía, en este artículo me enfocaré especialmente en un solo punto.

Soy ebar0n inicié en el equipo de Producto como Backend y actualmente soy DevOps Architect.

Platzi se construyó bajo una base Core escrita en Python con Django, la cual permitió tener en su momento mucha velocidad y poder dar valor con rápidas iteraciones, pero a medida que el equipo creció, fue necesario de forma natural irnos moviendo a una arquitectura más escalable que facilitara el trabajo colaborativo en microservicios, que precisamente es sobre lo que les quiero hablar hoy, nuestro sistema orquestado para mantener la experiencia del chat en Platzi Live.

El sistema del Chat que actualmente sirve Platzi, está construido in house con 7 componentes o microservicios independientes, donde tenemos código escrito en lenguajes de programación como Python, Javascript, Go y Rust, orquestados con Kubernetes, permitiéndonos ser elásticos para poder crecer lo necesario y volver al mínimo cuidando nuestra facturación; además de un par de servicios Core de AWS, incluso aprovechamos al máximo las ventajas de nuestro CDN - Cloudflare, usando estrategias de caché agresiva y el poder de los Workers, (al final del día no es necesario tener tanto cómputo si puedes sacarle partido a ese detalle, pero eso es un Plus, dejemóslo para profundizar en otro artículo)

Dentro de esos 7 componentes profundizaré en uno solo: MS-Daredevil, ¿y ese nombre? ¿Qué es eso?, Bueno en términos menos ñoños, nuestro Clasificador de mensajes, revelando una de sus múltiples sub rutinas, y aquí esto se pone interesante, ustedes podrán pensar que no es la gran cosa, pero realmente no se detectó hasta hacer pruebas de carga e irnos a escala, simplemente no fue prioridad hacerlo antes, siempre vamos mejorando sobre la marcha con nuestro objetivo se entregar valor lo mas rápido posible, recoger datos, iterar y continuar.

Entonces para poder describir la solución primero partamos del planteamiento, problema u oportunidad de mejora, eso que tanto nos gusta, porque es lo que debemos resolver y nos hace crecer.

fire.jpg

La oportunidad de mejora

Platzi crece cada día, soñamos con ver el acceso a la educación online efectiva súper masificada, y en esta edición de la Conf nos preparamos más o menos para 150 mil estudiantes simultáneos en las salas de la Conf (4 salas), siendo uno de los componentes clave el chat, nuestra comunidad es lo más valioso y tiene mucha importancia para todo el equipo en Platzi, poder facilitar esa interacción y conectarlos, mientras disfrutaban de todas las charlas en vivo… allí entramos en detalles.

¿Se imaginan qué pasa cuando 150 mil estudiantes escriben un mensaje? ¿En un segundo?, vámonos al ejemplo de carga mínima; tú, el/la/elle que está leyendo esta publicación, escribe un mensaje en el chat… desde que le das enviar, ese mensaje viaja al servidor, pasa por varios procesos hasta que finalmente es distribuido de regreso a 150 mil estudiantes o conexiones, un solo mensaje, es un chat en tiempo real, pero ahora ¿que pasa cuando todos escriben al mismo tiempo?, 150 mil mensajes replicados a 150 mil estudiantes, multipliquemos, nos da 22.500 millones de mensajes replicados, es una locura, ¿cuánto tiempo tardarían en difundirse?, y solo caímos en cuenta del problema palpable hasta la ejecución de unas pruebas de estrés cargadas de fuego purificador, al enviar trafico exagerado, llegaban olas de mensajes con retrasos importantes, y esto fue vital notarlo, todo debe probarse y llevarse al extremo, al final del día si no conoces esos límites, le das mucho pie a la incertidumbre y cualquier cosa puede salir mal, y así lo hagas créeme que lo que ha de fallar, fallará, está escrito, lo hemos vivido.

1.png

A 2 días antes de la Conf, eso aún funcionaba así, pero que va, no existe poder humano que permita leer 150mil mensajes en un segundo, ni incluso aquellas personas con la habilidad desarrollada de lectura rápida, y ademas tampoco tiene sentido ocupar esa cantidad de transferencia de datos, pero entonces ¿qué hacemos?

Revelando algunos detalles

Esos 150 mil mensajes si deben llegar a servidor, y deben ser guardados (los persistimos en lotes para no saturar el motor de base de datos), los necesitamos, son nuestra mina de metales preciosos para poder calcular métricas, y saber algunas cosas como aquellos momentos top de cada charla (por irnos a un ejemplo simple).

Pero ¿qué hicimos?, como cada componente tiene una función muy específica, simplemente añadimos algo de código en nuestro clasificador, justo antes de enviarlo al servicio de difusión.

Partimos de un rate limit llegando hasta muestreos estadísticos (ya vamos a ver por qué un rate limit por sí solo no era viable).

2.png

Partiendo de esa ilustración, si usamos un rate limit en tiempo llamado T y si decimos que ese valor tope de mensajes enviados es 500, al paso de los primeros 500 mensajes simplemente el chat dejaría de moverse por que se acabo la cuota en el primer segundo, y esa idea de “en tiempo real” se degradaría porque hasta los T segundos después no vería mensajes moverse, entonces no se ajusta a lo que deseamos, así que, luego de ese número tope, partimos de un porcentaje, una cantidad porcentual de mensajes que si deberían seguir difundiéndose y que el chat pueda seguir sintiéndose en vivo, o en otras palabras, muestreos, seguir difundiendo muestreos de mensajes.

3.png

Pero, ¿cuál porcentaje es el adecuado? 30%? 10%? para definir el muestreo 🤔 … ninguno de los 2, el 10% de 150 mil es 15 mil, aún sigue siendo demasiado, en unos pocos segundos tú puedes escribir N mensajes, entonces, si 149mil estudiantes envían solo 6 mensajes, ya estamos hablando de 1 millón de mensajes que tu recibirás en unos pocos segundos, así que, el algoritmo debe ser adaptativo, porque no queremos que sea el 10% de los 500 mensajes en rate limit, queremos que sean muestreos del 10% de todos los mensajes entrantes, y que por estadística a cada mensaje se le obtenga su valor ponderado si se encuentra entre el % aceptable o no, para poder ser replicado.

Así luego de superar el valor tope máximo, por algunas escalas, el porcentaje de muestreo debe irse recalculando para tomar cada vez un muestro más y más pequeño, y así, seguir teniendo tráfico de mensajes pero de una forma más controlada, y cada estudiante pueda seguir teniendo interacción segundo a segundo dentro de la comunidad, no lo verán todo, pero la estadística nos asegura que verán algo más humanamente procesable.

En resumen, nuestro chat sigue siendo real time, pero luego de ciertos umbrales de mensajes por segundo, el algoritmo comienza a tomar muestreos a difundir y así brindarte la mejor experiencia.

Si te gustaron estos detalles sin irnos tan profundo como ver código, dale like y comparte!.

Ahora te pregunto: ¿Notaste algo diferente durante la Conf? o no solo la Conf, ¿qué fue lo último nuevo que notaste en la plataforma? Algunas cosas son invisibles, pero esta fue solo una de las tantas mejoras que se implementan con el día a día, en Platzi hacemos despliegues continuos y en un solo día enviamos muchas mejoras.

Déjame en los comentarios que mejora de Platzi ha cambiado tu experiencia dentro la plataforma.

Curso Profesional de Arquitectura de Software
Curso Profesional de Arquitectura de Software

Curso Profesional de Arquitectura de Software

Aprender como escribir buen código es el primer paso, conocer diferentes tecnologías y saber cómo, cuándo y por qué usar una u otra dependiendo de los requerimientos del negocio es trabajo de un arquitecto de software. Conoce diferentes patrones de arquitectura, herramientas y estrategias para desarrollar software a nivel profesional.
Edwar
Edwar
ebar0n

6492Puntos

hace un mes

Todas sus entradas
Escribe tu comentario
+ 2
Ordenar por:
21
6675Puntos

Me encanta que no exista ese egoísmo sobre “no revelar secretos”, si bien no es una explicación con el código fuente si se explica el funcionamiento y el mensaje queda claro, la importancia de las pruebas y de como las optimizaciones se hacen con cálculos previos, no solo añadiendo más poder bruto.

6
31599Puntos
un mes

¡Hola Stanley! 👋🏽
Jajaja, totalmente de acuerdo. Me pasa que no puedo dejar de pensar en cómo se hizo x cosa en una plataforma. El que lo compartan es muy valioso. 😊

1
9124Puntos
un mes

Eso me suena como la frase que dice no hay un Yo en equipo

8
15198Puntos

Programación estocástica. Cool stuff! Gracias por el insight.

7
31599Puntos

Me encantó este post, me dejó una necesidad de seguir aprendiendo inalcanzable. Me falta tanto por aprender. 😫
¿Por dónde debería empezar? 👀

1
6235Puntos
un mes

Tienes una cantidad de cursos encima iris… como dice Platzi: “nunca pares de aprender”.

2
9584Puntos
un mes

Me paso igual, quede Plops, “Como asi, hay que regular el impacto de las interacciones en el chat, y eso como se hace.” Muy bueno entender como funciona la magia detras de cada componente de platzi.

5
537Puntos

Gracias por compartir, tuve que leer un par de veces el artículo para entenderlo y me pareció una genialidad lo que hicieron, realmente siempre pensamos que un chat debe ser realtime y no siempre debe ser así, de que sirve difundir millones de mensajes a una enorme audiencia si tampoco los pueden leer todos en tiempo real, eso equivale a hacer un volcado de logs en tiempo real a un servidor web que recibe millones de visitas, nunca podrás ver a detalle cada línea que va apareciendo en pantalla.

Ahorraron tiempo, ancho de banda, recursos y mejoraron la experiencia de usuario, la verdad genial! +1

2
44226Puntos

Realmente noté la diferencia en lo fluido del chat en la CONF, sobre todo en los momentos de más tráfico, ¡era impresionante!

Gracias por compartir esta información, me gusta conocer más sobre cómo funcionan las cosas.

2
11825Puntos

Genial el perfomance del chat en la CONF. Me gustaria saber que herramientas utilizan para las pruebas de estrés.

2
11825Puntos
un mes

Perfecto y tendrán algún curso de pruebas de Infraestructura que permita identificar estos escenarios.

2
6235Puntos

Me encanta porque en Platzi buscan y otra vez mejorar la experiencia de usuario en cosas tan sencillas como esas…

Por otra parte también veo que me falta muchisisisiisisimoooo por aprender!!! jajajaja voy en el proceso y es lo importante 🚀

1
30246Puntos

Wow, qué buena explicación, me dejó con ganas de seguir leyendo, tantas cosas que tomar en cuenta, qué buen trabajo equipo de DevOps son un sueño.

1
1652Puntos

Fabuloso, gracias 😃

1
1881Puntos

Gracias por todo el esfuerzo, se les quiere mucho !!!

1
4684Puntos

muy bueno el informe para poder realzar la importancia y arduo trabajo del equipo que aveces no contemplamos.

Me parece sorprendente el esfuerzo y trabajo de todos, ademas de la manera de plantear la solucion para los mensajes y que haga mas facil para el usuario el leerlo, muchas gracias por el esfuerzo.

1
14287Puntos

Wa, no entendí nada JAJAJA pero me alegro mucho que la conf haya salido de maravilla

1
9124Puntos

Eso me recuerda los poderosos algoritmos chinos que revisan 20,000 páginas de internet para desarrollar su propia versión de una pagina web

1
26923Puntos

Muchas gracias por el post Edwar.
Mencionaste que usan una arquitectura de microservicios…¿Cómo se comunican entre si los servicios?
¿Usan algún patrón event bus (Event-driven communication) u otro patrón?

1
308Puntos

Starting with the example, the conversation will come to a halt if the speed limit is T and the maximum number of messages delivered is 500. This is because the quota for the first second has been reached.

1
2080Puntos

Excelente post, me parece muy buen trabajo el que realizaron para poder soportar toda esa cantidad de transacciones… Me gustaría ver los 7 componentes que mencionas explicados, creo que todos deben tener algo de lo que se pueda aprender…

Particularmente me enfrenté a un problema similar en el trabajo y lo resolví igualmente por lotes como mencionas (por que el punto más débil en este esquema es el más lento, es decir, la base de datos) sin embargo, dos preguntas:

  1. ¿Como calcularon el tamaño exacto de los bloques a persistir?
  2. ¿Como relacionaron este dato con el precio de la facturación?

Es decir, teniendo diferentes stacks como mencionas, algunos lenguajes son más fuertes que otros en este tipo de problemas y la elección lenguaje vs costo se vuelve fundamental.

Muchisimas gracias por este post.

1
7749Puntos

Simplemente increíble, jamás me hubiera imaginado que un chat tuviese tanta complejidad, muchas gracias por compartir esta información. Aun me queda mucho por aprender.

1
20541Puntos

¿qué fue lo último nuevo que notaste en la plataforma?
En el chat ya no se puede enviar muchos mensajes unos detras de otros, ya que ha puedo un tiempo de esperar entre cada grupo de mensajes, osea si envío como 5 mensajes seguidos, tengo que esperar unos segundos para volver a enviar mensajes el chat

1
9584Puntos

Es sorprendente como cada caracteristica de platzi tiene detras muchas iteraciones, ideas, revisiones, pruebas. Que grandes son.

1
20180Puntos

Me agradan este tipo de post’s sobre los detrás de cámaras de algunas cosas que son invisibles por lo bien que funcionan.

Honestamente el artículo en partes muy puntuales lo sentí bastante confuso, aun teniendo presente que es un tema técnico y bastante interesante.

Esta platzi conf, en comparación a la pasada, estuvo muchísimo mejor “orquestrada” que la pasada. ¡Felicitaciones!

1
5469Puntos

¿Llega un momento en donde limitan la posibilidad de enviar menajes continuamente, imagino que eso puede ser cuando realmente hay sobrecarga en los comentarios no? Recuerdo que en la última conferencia de Freddy el “recharging time" era de como 300 segundos.
Es interesante como implementaron su solución, creo que si se puede ver como es diferente su sistema en comparación del live chat de YouTube, donde se entiende más eso de miles de mensajes en segundos.
¡Ojalá puedan darle seguimiento a este tema! Gracias por compartir.

2
6492Puntos
un mes

Tenemos varios controles, efectivamente como dices, todo debe ser adaptable dependiendo la sobrecarga, y la posibilidad de que estos controles se activen automáticamente, también tenemos la forma de evitar que un mismo estudiante sea el que inunde el chat de mensajes; pero aquí nos enfocamos más cuando incluso ese control se queda corto porque sólo envías un mensaje, pero lo hacen todos los conectados en la misma sala, y cuando son cientos de miles.