PlusPlus

Desafío

Solución

Hemos empezado con la parte más importante: la refactorización y la corrección del código. La antigua versión del bot estaba escrita en Python y necesitábamos portarla a Ruby,teniendo en cuenta todos los cambios adicionales que podrían surgir, así como arreglar los problemas existentes e implementar nuevas funcionalidades. Cuando estábamos planificando la infraestructura, basamos nuestras suposiciones sobre la carga en las estadísticas medias de uso del antiguo bot de Python: aproximadamente 500.000-700.000 acciones de usuarios por minuto. Ampliamos este nivel hasta ~1 millón de acciones de usuarios/minuto para tener cierto margen y proporcionamos un conjunto de pruebas de estrés.

Y aquí es donde apareció otro desafío. Resultó que Slack limita las pruebas a 1 mensaje por segundo y no tiene la funcionalidad para probar proyectos de alta carga. La carga real de PlusPlus era de más de 20-50 millones de acciones por minuto, y la infraestructura existente no podía soportarlo. Para cubrir la nuevos requerimientos, tuvimos que rehacer una parte importante de la lógica de la aplicación.

Users and objects logic optimization

El equipo de desarrollo de Redwerk necesitaba definir y optimizar cuidadosamente cualquier brecha e incluso las fugas más pequeñas de memoria y uso de CPU. La carga real del proyecto envió millones de acciones que contenían @usernames y @things en una sola línea. Los objetos requerían una lógica más avanzada que los usuarios, porque debían analizarse, luego verificar si existían en la base de datos, crear una nueva entrada si no existían, luego actualizar el puntaje, la tabla de posiciones y las tendencias globales. Con millones de tales acciones, la mayoría de ellas ocurriendo dentro de un solo mensaje, la base de datos se sobrecargó muy rápidamente, así como la memoria y la CPU.

Otra tarea de alta carga fue optimizar las actualizaciones de puntuación en las tablas de posiciones, ya que cada acción tenía que influir en la posición en las tablas de posiciones globales de usuarios y objetos. La cantidad increíblemente alta de elementos que debían analizarse, verificarse y actualizarse creó desafíos adicionales para el desarrollo.

Para optimizar todas estas acciones, nuestro equipo desarrolló una funcionalidad que utiliza múltiples núcleos de CPU en cada servidor, junto con un administrador de bots específico, que enruta cada bot a un nodo específico (Servidor + núcleo de CPU), un tipo de tarea que el balanceador de la carga de Amazon no pudo manejar. Después de eso, reconstruimos la lógica de solicitud para disminuir la cantidad de solicitudes.

También cambiamos de Ubuntu a CentOS. Ubuntu no nos permitía crear conexiones adicionales a una base de datos. CentOS, a su vez, proporcionó un entorno más estable mientras trabajaba con MongoDB y admitió la carga de acción excesiva. También nos permitió volver a configurar el servidor de AWS y actualizar la configuración central del sistema operativo en los nodos para mejorar el descriptor de archivos y los límites de los subprocesos.