Le mois dernier, le Super Bowl qui a vu s’affronter Philadelphie et Kansas City a été regardé par un nombre record de 24 millions de spectateurs uniques en streaming. Il a fallu beaucoup de travail en coulisses pour s’assurer que ceux-ci puissent regarder le match dans les meilleures conditions possibles. Pour aider FOX à diffuser son contenu sans accroc, Hydrolix a fourni un système de stockage et de visualisation de logs CDN en temps réel.
Il s’agissait de notre plus gros évènement à ce jour (plus important encore que le plus gros match de l’an dernier), puisque Hydrolix a ingéré presque 200 téraoctets de données de logs tout au long des trois heures et demie du match. Passons directement aux chiffres, qui ont de quoi donner le vertige :
- Pic d’ingestion de données: 17,4 Go/seconde, soit l’équivalent de 1,4 pétaoctet par jour
- 55 millions de lignes de log: aucune perte, des données à cardinalité élevée, toutes transformées, enrichies, indexées, compressées et inscrites en object storage
- 5 à 10 secondes nécessaires pour l’ingestion (entre l’événement loggé et la mise à disposition pour requêtage), conformément à l’objectif visé
- Taux de compression des données brutes de 16x, soit une réduction de 94 %
- 98,4 % d’élimination de Gauss-Jordan pour les tableaux récapitulatifs synchronisés avec les données brutes en temps réel sans ETL
- 55 000 de requêtes faites lors de l’évènement
- Temps de réponse des requêtes: 0,481 seconde (50e percentile)
À ce stade, ce ne sont plus seulement des données conséquentes, ce sont des données GIGANTESQUES, avec des volumes et des vitesses d’ingestion extrêmes, ainsi que des requêtes et des analyses en temps réel. Là où de nombreuses plateformes d’observabilité et de logging échoueraient à cette échelle, Hydrolix a permis d’obtenir un temps d’ingestion de 5 à 10 secondes, comprenant tout le processus pour recevoir, standardiser, enrichir, indexer, partitionner puis inscrire les données dans des object stores abordables. Aucune solution de stockage SSD (et coûteuse) n’a été nécessaire pour atteindre ce niveau de performance.
Pour cet évènement spécifique, Hydrolix avait pour mission d’ingérer, de stocker et d’analyser les logs des différents Content Delivery Networks (CDN) utilisés par Fox. Nous avons déjà beaucoup parlé de la surveillance de plusieurs CDN par le passé. Elle constitue un défi de taille pour la plupart des plateformes d’observabilité en raison de l’étendue des données et de la complexité de fusionner des logs très divers dans une table unique et logique.
Le fournisseur de médias a utilisé quatre CDN différents pour assurer une diffusion fluide pendant l’évènement. Deux d’entre eux ont fourni des logs en temps réel directement à notre API d’ingestion en streaming basée sur le protocole HTTP. Un autre a utilisé une combinaison de fonctions Kinesis et AWS Lambda pour nous fournir des données, et le dernier nécessitait que notre fonctionnalité d’auto-ingestion par micro-batchs lise les fichiers lors de leur inscription dans un bucket S3.
L’infrastructure de données d’Hydrolix pour cet évènement était hébergée sur la plateforme EKS (Kubernetes géré) d’AWS (Hydrolix étant compatible avec tous les grands fournisseurs de cloud). Pour préparer ce dimanche, nous avons déployé deux clusters Kaiju adaptés à cette masse de données. « Kaiju » est le surnom affectueux que nous avons donné aux énormes clusters à plusieurs bras d’Hydrolix, qui peuvent changer de taille, comme les monstres géants des films de Kaiju japonais.
La plateforme Hydrolix permet de séparer les workflows. Il est donc possible d’affecter chaque bras d’un cluster Kaiju à un workflow spécifique. Cela nous permet d’ajuster les workflows un par un pour maximiser les performances. Pour cet évènement, chaque cluster Kaiju disposait de bras différents pour la partie “core”, pour l’ingestion et le stockage, la compression et l’optimisation, et pour les requêtes et l’analyse des données. L’infrastructure comprenait aussi un cluster classique pour les logs de l’encodeur vidéo, mais il était plus petit et traitait seulement des millions d’enregistrements (au lieu de milliards).
Au total, les clusters Kaiju ont fait tourner 2 400 intake head pods, et un nombre équivalent de pods pour la compression (merge peers). L’architecture de requête a été déployée sur plusieurs groupes de ressources de requêtes (query pools). Cela permettait de s’assurer qu’aucun utilisateur ou tableau de bord ne rencontrait de problème de conflit de ressources (aussi appelés problèmes de « noisy neighbour » (“voisin bruyant”)). Par exemple, les utilisateurs qui menaient des investigations ad hoc avaient accès à des ressources de requêtage dédiées.
Hydrolix utilise les pods intake heads pour recevoir les données et les transformer, les personnaliser, les enrichir, les indexer ou les agréger en partie à des données entrantes. Ces pods inscrivent aussi les données dans de petites partitions dans les objets de stockage afin qu’elles soient ingérées et disponibles pour les requêtes le plus rapidement possible. De son côté, la partie merge (fusion/compression) sert à optimiser les partitions dans le stockage, afin d’augmenter les taux de compression et d’améliorer la performance des requêtes.
Chaque tableau de bord interrogeait les 30 minutes précédentes par défaut. Dans cette fenêtre de 30 minutes, nous avons engrangé en moyenne 19 milliards de lignes de données brutes. Nous avons traité ce volume efficacement avec des tableaux récapitulatifs, qui agrégeaient les indicateurs nécessaires pour les tableaux de bord et réduisaient le nombre de lignes entre 98 et 99,99 % en effectuant des agrégations répétées (voir ci-dessous). Dans le même temps, les données brutes sous-jacentes restent pleinement accessibles pour les requêtes ad hoc sur l’objet store optimisé d’Hydrolix. Grâce au nettoyage préalable des données et à ces agrégations, nos tableaux de bord sont restés rapides et économes en ressources, un enjeu crucial pendant un événement générant beaucoup de trafic.
En ce qui concerne la capacité de requête, l’un des Kaiju comprenait 15 query-heads (60 CPU/170 Gi) et 85 query-peers (60 CPU/170 Gi), et l’autre Kaiju comprenait 15 query-heads (60 CPU/170 Gi) et 200 query-peers (28 CPU/60 Gi). Ils tournaient sur des instances c5n.18xlarge et c6in.16xlarge optimisées pour le calcul. Étant donné que le client utilisait principalement des tableaux récapitulatifs, le calcul des requêtes était très efficace, allant jusqu’à 8,6 cores par téraoctet de données ingérées, ce qui a permis d’obtenir une latence de requête p50 de 0,481 seconde sur l’ensemble des tableaux de bord.
Et comme Hydrolix étant stateless, nous avons pu revenir entièrement à notre échelle d’origine une fois l’évènement terminé, ce qui a permis de réaliser des économies supplémentaires et de réduire l’utilisation globale en compute. De leur côté, toutes les données brutes et résumées sont restées en sécurité dans l’object store pour une analyse ultérieure.
Ce match a représenté une importante charge de travail, mais aussi une grande réussite pour nos équipes. Et nous avons même réussi à nous amuser un peu ! Nous avons utilisé un outil d’IA pour nous aider à résumer nos discussions alors que nous surveillions nos systèmes pendant environ 15 heures, et elle a défini un outil de facturation et de planification des capacités dont nous n’aurions jamais eu l’idée : le LpCW (lignes par chicken wing). Il repose sur le nombre de chicken wings mangés pendant le match. Skynet, on a trouvé meilleur que toi !
Non seulement nous sommes capables de fournir une performance de très haut niveau, mais en plus, nous sommes capables de le faire de manière économique en nous appuyant sur l’object storage. Nous pouvons faire du logging à grande échelle (on parle de pétaoctets par jour) sans que ça ne coûte les yeux de la tête…
Dans les prochaines semaines, nous aborderons plus en détail la manière dont nous avons préparé, mis en œuvre et fourni nos services à très grande échelle. Alors, si vous voulez tout savoir, restez à l’affût ! Nous parlerons de :
- La manière dont nous avons préparé ce niveau d’échelle, y compris en partenariat avec AWS ;
- La manière dont nous avons ajusté Hydrolix pour cet évènement, notamment avec les tableaux de bord et les summary tables ;
- Ce que nous avons appris dans le feu de l’action (pendant l’événement) et comment nous avons réussi à travailler de manière fluide.
Prochaines étapes
Si vous n’utilisez pas encore Hydrolix et que vous aimeriez en savoir plus, contactez Hydrolix pour faire un essai ou avoir une démo.
