How Blitz scaled their game coaching app with lower latency and leaner operations es una startup de rápido crecimiento que proporciona entrenamiento personalizado para juegos como League of Legends, Valorant y Fortnite. El objetivo es ayudar a los jugadores a convertirse en leyendas de League of Legends a través de insights en tiempo real y análisis post-match. Blitz Mientras los jugadores juegan, la aplicación hace bastante trabajo. captura los datos de los partidos en vivo, los analiza rápidamente y los utiliza para superponerse en pantalla de juegos en tiempo real, además de un entrenamiento post-juego personalizado.La guía se basa en la actividad actual e histórica de cada jugador, así como en los datos recopilados en miles de millones de partidos que involucran a cientos de millones de usuarios. Gracias a la creciente conciencia de las estadísticas populares de Blitz y la aplicación de entrenamiento de juegos, su creciente base de usuarios empujó su arquitectura original basada en Postgres y Elixir a sus límites. Para proporcionar baja latencia, alta disponibilidad y escalabilidad horizontal a su creciente base de usuarios, en última instancia: TL;DR Migración de servicios de backend de Elixir a Rust. Reemplazo de Postgres con ScyllaDB Cloud. Redujo considerablemente su huella. Eliminó su clúster Riak. Procesamiento de la cola sustituido por procesamiento en tiempo real. Infraestructura consolidada desde más de un centenar de núcleos de microservicios hasta cuatro nodos Google Cloud n4‐4 estándar (más una pequeña instancia de Redis para el caché de borde) Como un bono adicional, estos cambios acabaron reduciendo los costes de infraestructura de Blitz y reduciendo la carga de la base de datos sobre su personal de ingeniería. Blitz en el fondo Como explicó Naveed Khan (Chef de Ingeniería de Blitz), “Recopilamos una gran cantidad de datos de los editores de juegos y durante el juego.Por ejemplo, si usted está jugando a League of Legends, usamos la API de Riot para extraer datos de encuestas, y si usted instala nuestra aplicación también monitoreamos el juego en tiempo real. Escalar Pasados Postgres Una parte clave del sistema de Blitz es la API Playstyles, que analiza los datos pre-juego para los compañeros de equipo y los oponentes. Este proceso intensivo evalúa hasta 20 partidos por jugador y se ejecuta nueve veces por juego (una vez para cada jugador en el partido). El equipo refactorizó estratégicamente y consolidó numerosos microservices para mejorar el rendimiento. Pero el volumen de datos permaneció intenso. Según Brian Morin (Ingeniero Principal de Backend en Blitz), “Encontrar una solución de base de datos capaz de manejar este volumen de consulta fue crucial”. Originalmente usaron Postgres, que les sirvió muy temprano. No obstante, a medida que sus cargas de trabajo de escritura crecían, la complejidad operativa y los costos en Google Cloud crecieron significativamente. Además, la escalación de Postgres se hizo bastante compleja. Naveed compartió, “Intentamos todo tipo de cosas para escalar. Construimos múltiples servicios alrededor de Postgres para obtener la escala que necesitábamos: un clúster Redis, un clúster Riak y colas de Elixir Oban que ocasionalmente se inundaban. A medida que las startups crecen, a menudo cambian de “sólo usar Postgres” a “sólo usar NoSQL”. apropiadamente, el equipo de Blitz consideró cambiar a MongoDB, pero finalmente lo descartó. “Tuvimos mucha experiencia MongoDB en el equipo y a algunos de nosotros realmente nos gustó. sin embargo, nuestra carga de trabajo es muy pesada, con miles de jugadores simultáneos generando un flujo constante de datos. crearía una barrera para su carga de trabajo específica y el crecimiento esperado. Arquitectura primaria y secundaria de MongoDB Luego decidieron avanzar con RocksDB debido a su baja latencia y consideraciones de costo. Las pruebas mostraron que satisfacerían sus necesidades de latencia, por lo que realizaron el (re)modelo de datos requerido y migraron algunos juegos más pequeños de Postgres a RocksDB. Sin embargo, finalmente decidieron contra RocksDB debido a preocupaciones de escala y alta disponibilidad. “Baseado en los datos disponibles de nuestras pruebas, estaba claro que RocksDB no sería capaz de manejar la carga de nuestros juegos más grandes – y no podíamos arriesgar escalar verticalmente una sola instancia, y entonces tener esa una instancia baja”, explicó Naveed. ¿Por qué ScyllaDB Uno de sus ingenieros de backend sugirió ScyllaDB, por lo que alcanzaron y ejecutaron una prueba de concepto. Primero lo probaron en su propio hardware, luego se trasladaron a ScyllaDB Cloud. Por Naveed, “El costo era bastante cercano a la auto-hosting, y recibimos la gestión completa de forma gratuita, por lo que fue un no-brainer. Ahora tenemos un clúster Redis significativamente reducido, además nos deshacemos del clúster Riak y de las dependencias de la cola de Oban. Solo escriba a ScyllaDB y todo funciona. En términos de rendimiento, el cambio cumplió con su objetivo de nivelar la experiencia del usuario ... y también simplificó la vida de sus equipos de ingeniería. Brian añadió: “ScyllaDB ha demostrado ser excepcional, ofreciendo un rendimiento robusto con capacidad para ahorrar después de la optimización. Nuestro producto de League alcanza los picos a alrededor de 5k ops/sec con el cluster reportando bajo el 20% de carga. Nuestra mayor restricción ha sido el uso de discos, que hemos lanzado múltiples actualizaciones para mitigar. El nuevo sistema ahora puede devolver resultados inmediatamente en lugar de depender de datos en caché, proporcionando más información actualizada sobre otros jugadores e incluso identificando a compañeros de equipo frecuentes. Los resultados de esta migración han sido impresionantes: más de cien núcleos de microservices han sido re High-Level Architecture of Blitz Server with Rust and ScyllaDB Reescribir servicios de Elixir en Rust Como parte de una gran revisión de backend, el equipo de Blitz comenzó a repensar toda su infraestructura – más allá de la transición descrita anteriormente de Postgres al ScyllaDB de alto rendimiento y distribuido. Junto a esta migración de bases de datos, también eligieron poner en marcha sus servicios basados en Elixir en favor de un lenguaje más moderno. Después de una evaluación cuidadosa, Rust apareció como la elección clara. “Elixir es grande y sirvió bien a su propósito”, explicó Naveed. “Pero queríamos avanzar hacia algo con una adopción más amplia y un ecosistema de nivel de sistemas más fuerte. Ahora que el primer lote de servicios de reescritura de Rust está en producción, Naveed y el equipo no miran atrás: “Rust es fantástico. Es rápido, y el compilador te obliga a escribir código seguro de memoria de antemano en lugar de deshabilitar problemas de recogida de basura más tarde.
