How strategic database migration + data (re)modeling improved latencies and cut database costs 5X ZEE est la plus grande entreprise de médias et de divertissement de l'Inde, couvrant la télévision, les films, les médias en streaming et la musique. ZEE5 est leur premier service de streaming OTT, disponible dans plus de 190 pays avec 150 millions d'utilisateurs actifs mensuels. Les ingénieurs derrière le système savaient que la poursuite de la croissance des entreprises mettrait l’accent sur leur infrastructure (ainsi que sur les personnes qui examinent les factures de la base de données).L’équipe a donc décidé de repenser le système avant qu’il ne provoque des crises cardiaques.Tl;DR, ils ont conçu un système qui est aimé à l’intérieur et par les utilisateurs.Et Jivesh Threja (Tech Lead) et Srinivas Shanmugam (architecte principal) nous ont rejoint le jour de la Saint-Valentin l’année dernière pour partager leurs expériences. Ils ont décrit les exigences techniques pour le remplacement (neutralité dans le cloud, disponibilité pour plusieurs locataires, simplicité d’introduction de nouveaux cas d’utilisation, haut débit et faible latence à des coûts optimaux) et comment cela a conduit à ScyllaDB. Enveloppant, ils ont partagé des leçons apprises qui pourraient bénéficier à quiconque envisageant ou utilisant ScyllaDB. 5X cost savings (from $744K to $144K annually) and single-digit millisecond P99 read latency https://youtu.be/nArmqus9fbo?embedable=true Voici quelques extraits de ce discours... Qu’est-ce qu’un Heartbeat ? "Heartbeat" se réfère à une demande qui est lancée à intervalles réguliers pendant la lecture vidéo sur la plate-forme OTT ZEE5. Ces demandes simples suivent ce que les utilisateurs regardent et jusqu'où ils ont progressé dans chaque vidéo. Ils sont essentiels pour la fonctionnalité "continuer de regarder" de ZEE5, qui permet aux utilisateurs de pauser le contenu sur un appareil puis de le reprendre sur n'importe quel appareil. Pourquoi changer ? Le système de battement de cœur original de ZEE5 était un réseau de bases de données différentes, chacune traitant d'une partie spécifique de l'expérience de streaming. Ils voulaient un système qui n’était pas verrouillé dans un fournisseur de cloud particulier, coûterait moins cher à fonctionner et pouvait gérer leur échelle massive avec des performances constamment rapides – en particulier, des réponses millisecondes à un seul chiffre. De plus, ils voulaient la flexibilité d’ajouter facilement de nouvelles fonctionnalités et la possibilité d’offrir leur système à d’autres plates-formes de streaming. Comme Srinivas l’a dit: «Il fallait être prêt à plusieurs locataires pour qu’il puisse être réutilisé pour n’importe quel fournisseur OTT. Et il fallait être facilement extensible à de nouveaux cas d’utilisation sans changements architecturaux majeurs.» Architecture du système, avant et après Voici un aperçu de leur architecture de système originale avec plusieurs bases de données: DynamoDB pour stocker les données cardiaques de base Amazon RDS pour stocker les informations des épisodes suivants et précédents Apache Solr pour stocker des métadonnées persistantes Une instance Redis pour cacher les métadonnées Une autre instance de Redis pour stocker les détails des téléspectateurs L'équipe ZEE5 a examiné quatre options de base de données principales pour ce projet: Redis, Cassandra, Apache Ignite et ScyllaDB. Après évaluation et benchmarking, ils ont choisi ScyllaDB. Nous n'avons pas besoin d'une couche de cache supplémentaire en haut de la base de données persistante. ScyllaDB gère à la fois la couche de cache et la base de données persistante dans la même infrastructure, assurant une faible latence entre les régions, la réplication et la disponibilité multi-cloud. Nous n'avons pas besoin d'une couche de cache supplémentaire en haut de la base de données persistante. ScyllaDB gère à la fois la couche de cache et la base de données persistante dans la même infrastructure, assurant une faible latence entre les régions, la réplication et la disponibilité multi-cloud. La nouvelle architecture simplifie et affine la structure architecturale du système précédent. Maintenant, tous les événements de battement de cœur sont poussés dans leur thème de battement de cœur, traités via le traitement de flux et ingérés dans le Cloud ScyllaDB en utilisant les connecteurs ScyllaDB. Chaque fois que le contenu est publié, il est ingéré dans leur thème de métadonnées et ensuite inséré dans le Cloud ScyllaDB via les connecteurs de métadonnées. Srinivas conclut : « Avec cette nouvelle architecture, nous avons migré avec succès les charges de travail de DynamoDB, RDS, Redis et Solr vers ScyllaDB. ” 5x cost reduction, bringing our monthly expenses down from $62,000 to around $12,000. Plus profondément dans le design Jivesh a partagé plus sur leur design de bas niveau... Pipe de traitement de flux en temps réel Dans le pipeline de traitement du flux en temps réel, les battements cardiaques sont envoyés à ScyllaDB à intervalles réguliers. L'intervalle de battement cardiaque est défini à 60 secondes, ce qui signifie que chaque client front-end envoie un battement cardiaque toutes les 60 secondes pendant qu'un utilisateur regarde une vidéo. Ces battements cardiaques passent par le système de traitement du flux de lecture, les consommateurs de logique d'affaires transforment ces données dans le format requis - puis les données traitées sont stockées dans ScyllaDB. Couche API évolutive Le premier composant de la couche d'API évolutive est le service Heartbeat, qui est responsable du traitement de grands volumes d'ingestion de données. Un autre service de couche d’API remarquable est le service Concurrent Viewership Count. Ce service utilise ScyllaDB pour récupérer des données de visualisation simultanées – soit par utilisateur, soit par actif (par exemple, par ID). Cas d'utilisation de la gestion des métadonnées L’un des premiers défis majeurs auxquels ZEE5 a été confronté a été la gestion des métadonnées pour leur plate-forme OTT massive. Initialement, ils se sont appuyés sur une combinaison de trois bases de données différentes – Solr, Redis et Postgres – pour gérer leurs vastes besoins en métadonnées. En cherchant à optimiser et à simplifier, ils ont redessiné leur modèle de données pour fonctionner avec ScyllaDB au lieu de cela – en utilisant ID comme clé de partition, ainsi que des vues matérialisées. Voici un aperçu de leur modèle de métadonnées : create keyspace.meta_data ( id text, title text, show_id text, …, …, PRIMARY KEY((id),show_id) ) with compaction = {‘class’: ‘LeveledCompactionStrategy’ }; Dans ce modèle, l'ID sert de clé de partition. Puisque cette table a relativement peu d'écriture (une écriture se produit uniquement lorsqu'un nouvel actif est publié), mais beaucoup plus de lecture, ils ont utilisé la stratégie de compactage de niveau pour optimiser les performances. Vidéo Count Use Case Viewership Count est un autre cas d’utilisation qu’ils ont déplacé à ScyllaDB. Le nombre de vues peut être suivi par utilisateur ou par ID d’actif. ZEE5 a décidé de concevoir une table où l’ID d’utilisateur sert de clé de partition et l’ID d’actif de clé de tri – permettant aux données de vues d’être interrogées efficacement. Ils ont configuré le TTL de ScyllaDB pour correspondre à l'intervalle de battement cardiaque de 60 secondes, en veillant à ce que les données expirent automatiquement après l'heure désignée. Jivesh a expliqué : « Ce tableau est continuellement mis à jour avec des battements de cœur de chaque extrémité avant et de chaque utilisateur. À mesure que les battements de cœur arrivent, le nombre de téléspectateurs est suivi en temps réel et nettoyé automatiquement lorsque le TTL expire. Voici leur modèle de données de comptage des téléspectateurs : 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 Résultats et leçons apprises Le rapport de test de charge suivant montre un débit de 41,7 K de requêtes par seconde. Ce critère a été réalisé au cours du processus de sélection de la base de données pour évaluer les performances sous une charge élevée. Jivesh a commenté : « Même avec un débit aussi élevé, nous pouvions atteindre une latence d’écriture de microsecondes et une latence de lecture moyenne de microsecondes. Il a ensuite continué à partager quelques faits qui éclairent l’ampleur du déploiement de ScyllaDB de ZEE5 : « Nous avons environ 9 TB sur ScyllaDB. Même avec un tel volume de données, il est capable de gérer les latences dans les microsecondes et une milliseconde à un seul chiffre, ce qui est assez énorme. Chaque seconde, nous écrivons autant de données dans ScyllaDB et en tirons autant de données. Nous traitons plus de 100 milliards de battements cardiaques par jour, ce qui est assez énorme. » La conférence s’est achevée avec les leçons suivantes : La modélisation des données est le facteur le plus critique pour atteindre des latences millisecondes à un seul chiffre. Choisissez le bon quorum et la stratégie de compression. Par exemple, un rythme cardiaque doit-il être écrit à chaque nœud avant de pouvoir être lu, ou un quorum local est-il suffisant? Choisissez les clés de partition et de groupe avec sagesse – il n’est pas facile de les modifier plus tard. Utilisez les vues matérialisées pour effectuer des recherches plus rapides et éviter les requêtes de filtrage. Utilisez des déclarations préparées pour améliorer l'efficacité. Par exemple, dans le modèle de métadonnées, 20 requêtes synchrones ont été exécutées en parallèle et ScyllaDB les a traitées en millisecondes. Les clients ScyllaDB conscients de la zone aident à réduire les coûts de réseau cross-AZ (zone d'accessibilité).Récupérer des données dans la même zone d'accessibilité minimise la latence et réduit considérablement les coûts de réseau.
