How a team of just two engineers tackled real-time persisted events for hundreds of millions of players Con solo dos ingenieros, Supercell tomó la difícil tarea de expandir su sistema de cuenta básica en una plataforma social que conecta a cientos de millones de jugadores. gestión de cuentas, solicitudes de amigos, promociones de juegos cruzados, chat, seguimiento de la presencia de jugadores y formación de equipos - todo esto tuvo que funcionar a través de sus cinco juegos principales. El ingeniero de servidores de Supercell, Edvard Fagerholm, compartió recientemente cómo su poderoso equipo de dos personas abordó esta tarea. Nota: Si te gusta escuchar sobre logros de ingeniería como este, únete a nosotros en Monster Scale Summit (gratuito + virtual). Ingenieros de Disney+/Hulu, Slack, Canva, Uber, Salesforce, Atlassian y más compartirán estrategias y estudios de caso. Nota: Si te gusta escuchar sobre logros de ingeniería como este, únete a nosotros en Monster Scale Summit (gratuito + virtual). Ingenieros de Disney+/Hulu, Slack, Canva, Uber, Salesforce, Atlassian y más compartirán estrategias y estudios de caso. Notas Monstruos de la Escala Título: ¿Quién es la Supercélula? Supercell es la compañía con sede en Finlandia detrás de los juegos de éxito Hay Day, Clash of Clans, Boom Beach, Clash Royale y Brawl Stars. Hasta hace poco, toda la funcionalidad de gestión de cuentas para los juegos que sirven a cientos de millones de usuarios activos mensuales estaba siendo construida y gestionada por solo dos ingenieros. La Genesis de Supercell ID Supercell ID nació como un sistema básico de cuentas – algo para ayudar a los usuarios a recuperar cuentas y moverlas a nuevos dispositivos. Edvard explicó: “El cliente podía realizar consultas HTTP a la API de la cuenta, que en su mayor parte devolvían tokens firmados que el cliente podía presentar al servidor del juego para demostrar su identidad. Algunas operaciones, como hacer solicitudes de amigos, requerían que la API de la cuenta enviara una notificación a otro jugador. Por ejemplo, ‘¿Aprovees esta solicitud de amigo?’ Entrar en la comunicación de dos vías Después de que Edvard se unió al proyecto Supercell ID a finales de 2020, comenzó a trabajar en el backend de notificaciones, principalmente para la promoción cruzada en sus cinco juegos. Los clientes se conectaron a una flota de servidores proxy, luego un mecanismo de enrutamiento empujó eventos directamente a los clientes (sin pasar por el juego). Esto fue suficiente para el objetivo inmediato de manejar las solicitudes de promoción cruzada y amigos. Ellos se dieron cuenta de que podían utilizar la comunicación bidireccional para aumentar significativamente el alcance del sistema de identificación de Supercell. Edvard explicó: “Básicamente, nos permitió implementar características que antes formaban parte del servidor de juegos. Nuestro objetivo era tomar características que cualquier nuevo juego en desarrollo podría necesitar y empaquetarlas en nuestro sistema – acelerando así su desarrollo”. Con eso, Supercell ID comenzó a transformarse en una red social de juegos que soportaba funciones como gráficos de amigos, equipo, chat y seguimiento del estado de amigos. Evolución de Supercell ID en Red Social Cross-Game En este punto, el lado de la Red Social del backend todavía era un proyecto de una sola persona, por lo que lo diseñaron con simplicidad en mente. Encontrar la abstracción correcta “Queríamos tener solo una abstracción simple que soportara todos nuestros usos y por lo tanto podría ser diseñada e implementada por un único ingeniero”, explicó Edvard. “En otras palabras, queríamos evitar construir un sistema de chat, un sistema de presencia, etc. Queríamos construir una cosa, no muchas”. Encontrar la abstracción correcta fue clave y un almacén de valores clave jerárquico con Change Data Capture se ajusta perfectamente a la factura. Las claves de nivel superior en la tienda de valores clave son temas a los que se puede suscribir. Hay un mapa de dos capas debajo de cada clave de nivel superior – mapa(corte, mapa(corte, cadena)). Cualquier cambio en los datos bajo una clave de nivel superior se transmite a todos los suscriptores de esa clave. Los valores en el mapa más íntimo también están timestampados.Cada fuente de datos controla sus propias timestamps y define el orden correcto.El cliente deja caer cualquier actualización con un timestamp más antiguo que lo que ya ha almacenado. mapa(string, mapa(string, string)) Un cambio típico en los datos sería algo como los cambios de “nivel igual a 10” a “nivel igual a 11”.A medida que los jugadores juegan, desencadenan todo tipo de actualizaciones como esta, lo que significa que muchos pequeños escritos están involucrados en la persistencia de todos los eventos. Encontrar la base de datos adecuada Necesitaron una base de datos que soporte sus requisitos técnicos y sea gestionable, dado su equipo minimalista. Gestiona muchos escritos pequeños con baja latencia Soporta un modelo de datos jerárquico Gestiona las operaciones de backup y cluster como un servicio ScyllaDB Cloud resultó ser un gran ajuste. (ScyllaDB Cloud es la versión completamente administrada de ScyllaDB, una base de datos conocida por proporcionar una latencia predictable a escala). Cómo se juega todo Para una idea de cómo esto se desempeña en los juegos de Supercell, echemos un vistazo a dos ejemplos. En primer lugar, considere los mensajes de chat. Un mensaje de chat simple podría estar representado en su modelo de datos de la siguiente manera: Edvard explicó: “La clave de nivel superior a la que se suscribe es el ID de la sala de chat. La clave de nivel siguiente es un UID de timestamp, por lo que tenemos un orden de cada mensaje y podemos consultar el historial de chat. A continuación, echemos un vistazo a la “presencia”, que se utiliza mucho en el nuevo (y altamente esperado) juego de Supercell, mo.co. El objetivo de la presencia, según Edvard: “Cuando te unas para la batalla, quieres ver en tiempo real el avatar y la construcción actual de tus amigos, básicamente las armas y el equipo de tus amigos, así como lo que están haciendo. Players’ state data is encoded into Supercell’s hierarchical map as follows: Note that: El nivel superior es el ID del jugador, el segundo nivel es el tipo, y el mapa interno contiene los datos. El Supercell ID no necesita entender los datos; simplemente los transmite a los clientes de juegos. Los clientes de juegos no necesitan conocer el gráfico de amigos ya que el enrutamiento es manejado por Supercell ID. Más profundidad en la arquitectura del sistema Terminemos con un recorrido por la arquitectura del sistema, como lo proporcionó Edvard. “El backend se divide en APIs, proxies y servidores de enrutamiento de eventos/almacenamiento. Los temas viven en los servidores de enrutamiento de eventos y se dividen entre ellos. Un cliente se conecta a un proxy, que gestiona la suscripción del tema del cliente. El proxy enrutará estas suscripciones a los servidores de enrutamiento de eventos correspondientes. Los puntos finales (por ejemplo, para chat y presencia) envían sus datos a los servidores de enrutamiento de eventos, y todos los eventos persisten en la nube ScyllaDB. Cada tema tiene un shard primario y de copia de seguridad. Si el primario desciende, el shard primario mantiene los números de secuencia de memoria para cada mensaje para detectar mensajes perdidos. El secundario enviará mensajes sin números de secuencia. Si el primario está abajo, el primario que aparece desencadenará un refresco de estado en el cliente, así como la restauración de los números de secuencia. La API para las capas de enrutamiento es una simple RPC post-evento que contiene un lote de temas, tipos, claves, tuples de valor. El trabajo de cada API es simplemente reescribir sus datos en la representación tuple anterior. Cada evento se escribe en ScyllaDB antes de transmitir a los suscriptores. Nuestras APIs son sincronizadas en el sentido de que si una llamada de API da una respuesta exitosa, el mensaje persistió en ScyllaDB. Enviar el mismo evento varias veces no hace daño ya que aplicar la actualización al cliente es una operación idempotente, con la excepción de posiblemente múltiples números de secuencia mapping al mismo mensaje. Cuando se conecta, el proxy descubrirá a todos sus amigos y se suscribirá a sus temas, lo mismo para los grupos de chat a los que pertenece. También nos suscribimos a los temas para el cliente que se conecta. Estos se utilizan para enviar notificaciones al cliente, como solicitudes de amigos y promociones cruzadas. Un reinicio del router desencadena una reinscripción a los temas desde el proxy. Usamos Protocol Buffers para ahorrar en el coste de ancho de banda. Todo el balance de carga está en el nivel TCP para garantizar que las solicitudes a través de la misma conexión HTTP/2 se traten por el mismo soporte TCP en el proxy. Esto nos permite cachear cierta información en la memoria en la escucha inicial, por lo que no necesitamos refetchar en otras solicitudes. Tenemos suficientes clientes simultáneos que no necesitamos cargar por separado los requerimientos HTTP/2 individuales, ya que el tráfico se distribuye uniformemente de todos modos, y las solicitudes son aproximadamente igualmente caras para manejar a través de diferentes usuarios. Usamos soportes persistentes entre proxies y routers. Pero no es juego terminado Si desea ver la conversación de tecnología completa, simplemente presione el juego abajo: Y si quieres leer más sobre el papel de ScyllaDB en el mundo del juego, también puedes leer: Epic Games: Cómo Epic Games utiliza ScyllaDB como un cache binario frente a NVMe y S3 para acelerar la distribución global de grandes activos de juegos utilizados por Unreal Cloud DDC. Tencent Games: Cómo Tencent Games construyó una arquitectura de servicios basada en CQRS y patrones de suministro de eventos con Pulsar y ScyllaDB. Discord: Cómo Discord utiliza ScyllaDB para impulsar su enorme crecimiento, pasando de una plataforma de juegos de nicho a una de las mayores plataformas de comunicación del mundo. Juegos de Epic: Juegos de Tencent: En discordia:
