How strategic database migration + data (re)modeling improved latencies and cut database costs 5X ZEE es el mayor negocio de medios y entretenimiento de la India, que cubre la transmisión de televisión, películas, medios de transmisión y música. ZEE5 es su primer servicio de transmisión OTT, disponible en más de 190 países con ~150 millones de usuarios activos mensuales. Los ingenieros detrás del sistema sabían que el crecimiento continuo de los negocios pondría énfasis en su infraestructura (así como en las personas que revisaban las facturas de la base de datos).Por lo tanto, el equipo decidió repensar el sistema antes de infligir cualquier ataque al corazón.Tl;DR, diseñaron un sistema que es amado internamente y por los usuarios.Y Jivesh Threja (Tech Lead) y Srinivas Shanmugam (Arquitecto Principal) se unieron a nosotros el año pasado para compartir sus experiencias en el Día de San Valentín. Describieron los requisitos técnicos para el reemplazo (neutralidad en la nube, disponibilidad de varios inquilinos, facilidad de embarque de nuevos casos de uso, alta transmisión y baja latencia a un costo óptimo) y cómo esto condujo a ScyllaDB. Luego, explicaron cómo lograron sus objetivos a través de una nueva tubería de procesamiento de flujo, nueva capa de API y (re)modelaje de datos. Envueltos, compartieron lecciones aprendidas que podrían beneficiar a cualquiera que considerara o usara ScyllaDB. 5X cost savings (from $744K to $144K annually) and single-digit millisecond P99 read latency https://youtu.be/nArmqus9fbo?embedable=true Aquí tenéis algunos destacados de ese discurso... ¿Qué es un Heartbeat? “Heartbeat” se refiere a una solicitud que se lanza a intervalos regulares durante la reproducción de vídeo en la plataforma ZEE5 OTT. Estas solicitudes simples rastrean lo que los usuarios están viendo y hasta dónde han avanzado en cada video. Son esenciales para la funcionalidad de “continuar viendo” de ZEE5, que permite a los usuarios pausar el contenido en un dispositivo y luego reanudarlo en cualquier dispositivo. ¿Por qué cambiar? El sistema de corazón original de ZEE5 era una red de bases de datos diferentes, cada una de las cuales manejaba una parte específica de la experiencia de streaming.Aunque técnicamente era funcional, este enfoque era caro y los encerró en un ecosistema de proveedores específico. El equipo reconoció una oportunidad para simplificar su infraestructura – y lo buscaron. quisieron un sistema que no estuviera bloqueado en ningún proveedor de nube en particular, costaría menos para operar, y podría manejar su enorme escala con un rendimiento consistentemente rápido – específicamente, las respuestas de milisegundos de un único dígito. Además, querían la flexibilidad para agregar nuevas características fácilmente y la capacidad de ofrecer su sistema a otras plataformas de streaming. Como Srinivas dijo: “Tenía que estar listo para varios inquilinos para que pueda ser reutilizado para cualquier proveedor de OTT. Y tenía que ser fácilmente extensible a nuevos casos de uso sin cambios arquitectónicos importantes”. Arquitectura del sistema, antes y después Aquí está una mirada a su arquitectura de sistema original con múltiples bases de datos: DynamoDB almacena los datos básicos de los latidos cardíacos Amazon RDS para almacenar la información del episodio siguiente y anterior Apache Solr para almacenar metadatos persistentes Una instancia de Redis para cachear metadatos Otra instancia de Redis para almacenar los detalles de la audiencia El equipo de ZEE5 consideró cuatro opciones de base de datos principales para este proyecto: Redis, Cassandra, Apache Ignite y ScyllaDB. Después de la evaluación y el benchmarking, eligieron ScyllaDB. No necesitamos una capa de caché adicional en la parte superior de la base de datos persistente. ScyllaDB gestiona tanto la capa de caché como la base de datos persistente dentro de la misma infraestructura, garantizando una baja latencia entre regiones, replicación y disponibilidad en múltiples nubes. Funciona con cualquier proveedor de nube, incluyendo Azure, AWS y GCP, y ahora ofrece soporte gestionado con un tiempo de vuelta de menos de una hora. No necesitamos una capa de caché adicional en la parte superior de la base de datos persistente. ScyllaDB gestiona tanto la capa de caché como la base de datos persistente dentro de la misma infraestructura, garantizando una baja latencia entre regiones, replicación y disponibilidad en múltiples nubes. Funciona con cualquier proveedor de nube, incluyendo Azure, AWS y GCP, y ahora ofrece soporte gestionado con un tiempo de vuelta de menos de una hora. La nueva arquitectura simplifica y aplanó la estructura anterior de la arquitectura del sistema. Ahora, todos los eventos de palpitaciones son empujados a su tema de palpitaciones, procesados a través del procesamiento de flujo y ingeridos en la nube de ScyllaDB usando conectores de ScyllaDB. Cada vez que se publica contenido, se ingiere en su tema de metadatos y luego se inserta en la nube de ScyllaDB a través de conectores de metadatos. Srinivas concluye: “Con esta nueva arquitectura, hemos migrado con éxito las cargas de trabajo de DynamoDB, RDS, Redis y Solr a ScyllaDB. ” 5x cost reduction, bringing our monthly expenses down from $62,000 to around $12,000. Más profundamente en el diseño Jivesh compartió más sobre su diseño de bajo nivel... Pipeline de procesamiento de flujo en tiempo real En la tubería de procesamiento de flujo en tiempo real, los latidos del corazón se envían a ScyllaDB a intervalos regulares. El intervalo de latido del corazón se establece en 60 segundos, lo que significa que cada cliente frontend envía un latido cada 60 segundos mientras un usuario está viendo un vídeo. Estos latidos del corazón pasan a través del sistema de procesamiento de flujo de reproducción, los consumidores de lógica empresarial transforman esos datos en el formato requerido - entonces los datos procesados se almacenan en ScyllaDB. Escalable API Layer El primer componente de la capa de API escalable es el servicio Heartbeat, que es responsable del manejo de grandes volúmenes de ingestión de datos. Los temas procesan los datos, luego pasan a través de un servicio de conector y se almacenan en ScyllaDB. Otro servicio de capa de API notable es el servicio Concurrent Viewership Count. Este servicio utiliza ScyllaDB para recuperar datos de visualización simultánea, ya sea por usuario o por activo (por ejemplo, por ID). Caso de uso de la gestión de metadatos Uno de los primeros desafíos importantes a los que se enfrentaba ZEE5 fue la gestión de metadatos para su enorme plataforma OTT. Inicialmente, se basaron en una combinación de tres bases de datos diferentes – Solr, Redis y Postgres – para manejar sus extensas necesidades de metadatos. Aquí está un vistazo a su modelo de metadatos: create keyspace.meta_data ( id text, title text, show_id text, …, …, PRIMARY KEY((id),show_id) ) with compaction = {‘class’: ‘LeveledCompactionStrategy’ }; En este modelo, el ID sirve como la clave de partición.Dado que esta tabla experimenta relativamente pocos escritos (una escritura ocurre sólo cuando se libera un nuevo activo) pero significativamente más lecturas, utilizaron la Estrategia de Compactación Nivelada para optimizar el rendimiento.Y, según Jivesh, "Elegir la partición correcta y las claves de agrupamiento nos ayudaron a obtener una latencia de milisegundos de un único dígito". Caso de uso Conto de uso Viewership Count es otro caso de uso que se trasladó a ScyllaDB. Viewership count se puede rastrear por usuario o por ID de activo. ZEE5 decidió diseñar una tabla donde el ID de usuario sirvió como la clave de partición y el ID de activo como la clave de clasificación - permitiendo que los datos de visualización se consultaran de manera eficiente. Configuraron el TTL de ScyllaDB para coincidir con el intervalo de latidos cardíacos de 60 segundos, asegurando que los datos expiran automáticamente después del tiempo designado.Además, utilizaron la estrategia de compactación de ventanas de tiempo de ScyllaDB para gestionar de manera eficiente los datos en la memoria, limpiando los registros caducados basados en el TTL configurado. Jivesh explicó: “Esta tabla se actualiza continuamente con los latidos del corazón de cada extremo frontal y de cada usuario. A medida que llegan los latidos del corazón, las cuentas de audiencia se rastrean en tiempo real y se borran automáticamente cuando expira el TTL. Aquí está su modelo de datos de cuenta de espectadores: CREATE TABLE keyspace.USER_SESSION_STREAM ( USER_ID text, DEVICE_ID text, ASSET_ID text, TITLE text, …, PRIMARY KEY((USER_ID), ASSET_ID) ) WITH default_time_to_live = 60 and compaction = { 'class' : 'TimeWindowCompactionStrategy' }; ScyllaDB Resultados y lecciones aprendidas El siguiente informe de prueba de carga muestra un rendimiento de 41.7K solicitudes por segundo.Este índice de referencia se realizó durante el proceso de selección de bases de datos para evaluar el rendimiento bajo alta carga. Jivesh comentó: “Incluso con una transmisión tan alta, podríamos alcanzar una latencia de escritura de microsegundos y una latencia promedio de lectura de microsegundos. Luego continuó compartiendo algunos hechos que arrojaron luz sobre la escala de la implementación de ScyllaDB de ZEE5: “Tenemos alrededor de 9 TB en ScyllaDB. Incluso con un volumen tan grande de datos, es capaz de manejar latencias dentro de microsegundos y un milisegundo de un dígito, lo que es bastante enorme. Cada segundo, estamos escribiendo tantos datos en ScyllaDB y obteniendo tantos datos de él Procesamos más de 100 mil millones de latidos cardíacos en un día, que es bastante enorme”. La charla concluyó con las siguientes lecciones aprendidas: El modelado de datos es el factor más crítico para lograr latencias de milisegundos de un único dígito. Elige la configuración del quórum correcta y la estrategia de compactación. Por ejemplo, ¿necesita que se escriba un ritmo cardíaco a cada nodo antes de que pueda ser leído, o es suficiente un quórum local? Elige particiones y claves de agrupación sabiamente: no es fácil modificarlas más adelante. Utilice Visualizaciones Materializadas para realizar búsquedas más rápidas y evitar consultas de filtro. Utiliza declaraciones preparadas para mejorar la eficiencia. Por ejemplo, en el modelo de metadatos, se ejecutaron 20 consultas sincronizadas en paralelo, y ScyllaDB las procesó dentro de milisegundos. Los clientes ScyllaDB conscientes de la zona ayudan a reducir los costes de red de la zona de disponibilidad (Cross-AZ).Recuperar datos dentro de la misma zona de disponibilidad minimiza la latencia y reduce significativamente los costes de red.
