Comment RTL Deutschland a multiplié par trois sa durée de conservation des données grâce au niveau "frozen" d'Elastic Observability, sans aucune interruption de service lors de la transition

RTL Deutschland a repensé son lac de données centralisé : la durée standard de conservation des données est passée de 30 à 90 jours, le nombre de nœuds a été réduit de près de moitié et la migration s'est achevée sans aucune perte de données.

RTL Deutschland exploite un lac de données Elastic à l'échelle de l'entreprise qui, en près de dix ans, est devenu la plateforme de référence pour le logging, les données d'applications et la business intelligence entre les différents services. Une limite de stockage sur site de 100 To plafonnait la durée standard de conservation des données à environ 30 jours, empêchant les équipes d'analyser l'évolution des KPI sur plusieurs mois et obligeant à stocker les données de conformité dans des buckets S3 distincts, en dehors du lac de données interrogeable. Après être passée de l'édition Platinum à l'édition Entreprise et avoir restructuré son architecture autour des snapshots interrogeables et du niveau frozen, l'entreprise a vu sa durée de conservation standard tripler pour atteindre 90 jours et sa capacité totale passer à 235 To pour une même empreinte sous licence. Par ailleurs, l'empreinte de l'hyperviseur a été réduite de 18 à 10 nœuds physiques, et la migration complète s'est effectuée sans aucune interruption de service ni perte de données.

Le lac de données Elastic de RTL Deutschland couvre près d'une décennie de logging, de données d'applications et de business intelligence provenant de l'ensemble des activités de l'entreprise dans le domaine de l'audiovisuel et des médias. En 2024, ce lac de données a atteint ses limites. Avec une capacité de stockage sur site d'environ 100 To, la durée de conservation standard était limitée à environ 30 jours. Or, plusieurs services avaient besoin d'un historique de plusieurs mois pour suivre l'évolution des KPI, tandis que les données de conformité (soumises à une politique interne exigeant une conservation de six mois) étaient stockées en dehors de la plateforme interrogeable, dans des buckets S3 distincts. Après être passée de l'édition Platinum à l'édition Entreprise et avoir restructuré son architecture autour des snapshots interrogeables et du niveau de stockage frozen, RTL Deutschland a triplé sa durée de conservation standard pour atteindre 90 jours, porté sa capacité totale à 235 To (avec empreinte sous licence inchangée) et réduit l'empreinte de son hyperviseur de 18 à 10 nœuds physiques ; la transition complète s'est opérée sans aucune interruption de service ni perte de données.

Les périodes de 30 jours ne permettent pas seulement d'accéder à un historique plus long, mais aussi à toute une catégorie de questions : comparaisons d'un trimestre à l'autre, cycles saisonniers d'une année sur l'autre et périodes de référence suffisamment étendues pour rendre une courbe de tendance crédible. Pour les utilisateurs BI de RTL Deutschland, le lac de données contenait certes les données opérationnelles, mais s'arrêtait bien en amont des besoins analytiques. Grâce à un historique standard de 90 jours et une année complète pour certains index, il est désormais possible de répondre à ces questions au sein même du lac de données que les équipes opérationnelles surveillent en temps réel, à partir des mêmes données, sans avoir à les exporter ailleurs.

Ce résultat repose sur deux transitions distinctes intervenues au cours du cycle de vie de la plateforme : d'une part, une consolidation vers Elastic en 2023 à la suite d'une fusion d'entreprises ayant entraîné l'intégration d'une deuxième plateforme de logging ; d'autre part, la mise à niveau ultérieure des licences, qui a permis de redéfinir l'architecture de stockage afin que la durée de conservation puisse tripler sans augmenter l'empreinte sous licence.

L'environnement Elastic de RTL Deutschland a vu le jour il y a près d'une décennie en tant qu'outil d'infrastructure partagée, avant de se développer, équipe après équipe, pour devenir le lac de données à l'échelle de l'entreprise. Deux événements ont façonné la plateforme telle qu'elle existe aujourd'hui.

Le premier a été une consolidation post-fusion en 2023. La nouvelle entité qui venait de rejoindre le groupe utilisait une plateforme de logging différente. L'environnement Elastic de RTL Deutschland était déjà déployé sur site et disposait d'une capacité excédentaire ; dès lors, l'exploitation simultanée de deux plateformes ne se justifiait ni sur le plan financier ni sur le plan opérationnel. La migration depuis l'ancien outil de logging a duré environ cinq mois. Les tâches les plus lourdes ont consisté à assurer la communication, à reconstruire les tableaux de bord et les workflows de notification que l'équipe avait mis en place au fil des ans, ainsi qu'à remanier les pipelines d'ingestion.

Le deuxième concernait la limite de stockage, et la stratégie pour s'en défaire. Après avoir découvert les snapshots interrogeables et le niveau de stockage frozen lors de la conférence Elastic{ON} à Munich, l'équipe a identifié une solution qui répondait directement à la problématique du stockage : conserver la même empreinte sous licence, déplacer les données de longue traîne vers un stockage de type frozen basé sur S3 et utiliser la capacité ainsi libérée dans le niveau hot pour prolonger la durée de conservation. Avant de s'engager, l'équipe a élaboré une preuve de concept axée sur une question essentielle : quelle serait la vitesse d'exécution des requêtes sur les données anciennes stockées dans le niveau frozen ? Le résultat étant suffisamment rapide, la décision de repenser l'ensemble du cluster en passant d'un modèle hot-and-cold à un modèle hot-and-frozen s'est imposée d'elle-même.

Avant la refonte, la durée de conservation standard de RTL Deutschland était limitée à environ 30 jours par 100 To de stockage sur site. Le lac de données était sain, mais trois réalités opérationnelles justifiaient de dépasser ce plafond.

Les besoins en matière de business intelligence exigeaient davantage qu'une période de 30 jours. Certains services souhaitaient suivre l'évolution des KPI au fil du temps. Un historique de trente jours ne suffisait pas pour effectuer ce travail au sein du lac de données. Les équipes disposaient des données nécessaires à leurs opérations, mais pas de la profondeur historique requise pour l'analyse.

Les données de conformité se trouvaient en dehors du lac de données. Les données de pare-feu, soumises à une durée de conservation de six mois selon la politique interne, étaient stockées dans des buckets S3 distincts et non sur la plateforme permettant d'effectuer des recherches. Ces données étaient bien conservées, mais y accéder dans le cadre d'une enquête impliquait de les extraire du stockage d'objets pour les charger dans un système interrogeable, une opération que l'équipe qualifiait de très fastidieuse en situation réelle.

Le matériel vieillissait. Le cluster fonctionnait sur des serveurs datant d'environ cinq ou six ans, équipés de SSD standard plutôt que de disques NVMe. L'équipe savait qu'un renouvellement du matériel s'imposait, que l'architecture soit modifiée ou non.

L'équipe consacrait son temps à maintenir la plateforme existante en bon état de fonctionnement dans la limite des contraintes imposées au lieu de chercher à étendre ses capacités au profit du reste de l'entreprise.

L'équipe est passée de l'édition Platinum à l'édition Entreprise pour bénéficier des snapshots interrogeables et du niveau frozen, puis a repensé la configuration du stockage en remplaçant le modèle hot-and-cold par un modèle hot-and-frozen basé sur S3.

Le flux de données de bout en bout est resté inchangé. Les nœuds Logstash ingèrent les données provenant de sources réparties sur l'ensemble de l'organisation et les écrivent dans Elastic. Les index plus anciens ont été transférés vers le niveau frozen où ils sont stockés sur S3 et chargés dans un cache local à la demande, lors de l'exécution de requêtes. La fonctionnalité de recherche intercluster a assuré la liaison entre les anciens et les nouveaux clusters pendant la transition, afin que les utilisateurs puissent accéder aux données historiques sans changer d'environnement.

Le compromis en matière de performances s'est avéré gérable. La première requête ciblant un index du niveau frozen prend environ 30 secondes, le temps que les données concernées soient chargées dans le cache des nœuds de ce niveau. Par la suite, les requêtes portant sur ces mêmes données s'exécutent à la vitesse du niveau hot.

• Vitesse de requête du niveau hot pour les données actuelles : 35 To de SSD NVMe sur des serveurs récents, fonctionnant sous KVM.
• Conservation de quelques mois à plusieurs années à faible coût : 200 To de stockage frozen sur S3, accessibles via des snapshots interrogeables.
• Capacité triplée pour une même empreinte sous licence : 235 To au total (35 To à chaud et 200 To à froid) sans augmentation du nombre d'unités de ressources sous licence.
• Cluster plus compact et plus performant : l'empreinte de l'hyperviseur a été réduite de 18 à 10 nœuds physiques, sur du matériel plus récent doté d'un plus grand nombre de cœurs par nœud.
• Basculement progressif des charges de travail sans réarchitecture du pipeline : Logstash a continué d'assurer l'ingestion ; les destinations ont été redirigées par source de données pendant la migration.
• Aucune perte d'accès aux données historiques en cours de migration : la recherche intercluster est restée active tout au long du processus, les utilisateurs pouvant ainsi continuer à lire les anciens index sur le cluster existant pendant que les nouvelles données étaient acheminées vers le nouveau cluster.
• Vitesse du niveau hot pour les données anciennes après la première requête : environ 30 secondes pour l'hydratation du cache depuis le niveau frozen lors de la requête initiale ; les requêtes suivantes s'exécutent à la vitesse du niveau hot.

Plutôt qu'un basculement massif, l'équipe a mis en place le nouveau cluster parallèlement à l'ancien et a migré les charges de travail une par une, en commençant par les sources de données les plus volumineuses. Comme l'ingestion s'effectuait via Logstash, le transfert d'une charge de travail s'est souvent résumée à modifier la destination sur le nœud Logstash, en remplaçant le nœud maître de l'ancien cluster par celui du nouveau. La recherche intercluster a permis aux utilisateurs du nouvel environnement de conserver un accès en lecture aux données encore présentes sur l'ancien cluster, assurant ainsi la disponibilité des données historiques tout au long du processus.

L'équipe a également profité de l'occasion pour migrer, dans la mesure du possible, les pipelines d'ingestion personnalisés vers les intégrations maintenues par Elastic, une approche qu'elle considère comme la meilleure voie pour l'avenir.

Le support technique Elastic a prolongé la période de chevauchement lorsque les expéditions de matériel ont été retardées, ce que l'équipe a spécifiquement souligné comme l'un des éléments qui ont permis de respecter le calendrier.

La preuve de concept elle-même a nécessité environ deux semaines. La majeure partie du calendrier de six à huit semaines prévu pour le PoC a été consacrée à l'acquisition et au provisionnement du matériel, et non aux tests. La bascule complète a duré environ trois mois et s'est achevée sans interruption de service ni perte de données.

Pour les services qui utilisent le lac de données au quotidien, le changement est passé presque inaperçu. Les utilisateurs ont dû rediriger leurs favoris vers la nouvelle URL durant la période de chevauchement temporaire, puis revenir au domaine standard une fois la bascule effectuée. Grâce à la recherche intercluster, les données historiques sont restées accessibles depuis le nouveau cluster tout au long du processus ; personne n'a donc eu à adopter un nouveau workflow ni à interroger deux systèmes distincts pour retrouver d'anciennes données.

Du côté de la conformité, les données qui se trouvaient auparavant dans des buckets S3 distincts résident désormais dans le lac de données interrogeable. La conservation des données de pare-feu pendant six mois ne pose plus de problème au niveau du workflow. Si un service a besoin de remonter dans le temps sur toute la période de conservation, il interroge de la même manière que pour n'importe quelle autre donnée du lac.

Quelques leçons pratiques se sont dégagées de ce projet.

Utiliser les intégrations gérées lorsque cela est possible. RTL Deutschland disposait depuis des années de pipelines d'ingestion personnalisés et en a migré une grande partie vers les intégrations maintenues par Elastic lors de la transition. Selon l'équipe, il s'agit de la meilleure voie à suivre pour l'avenir, pas seulement pour ce projet.

Traiter une migration comme une rénovation. Le fait de remplacer le matériel vieillissant, de moderniser l'architecture et de revoir les intégrations simultanément a multiplié la valeur du projet par rapport à l'une ou l'autre de ces opérations menée isolément.

Évaluer objectivement le modèle d'hébergement. L'hébergement sur site se justifiait compte tenu des ressources existantes et des impératifs commerciaux de RTL Deutschland. Pour les entreprises plus modestes dépourvues des capacités internes nécessaires pour déployer et gérer un cluster, l'équipe orienterait plutôt le choix vers l'offre SaaS d'Elastic afin d'éviter les contraintes opérationnelles.

Le plus difficile a été le volume, pas la complexité. La redirection des données d'ingestion d'un cluster vers un autre s'est effectuée sans problème. Le véritable défi tenait au nombre considérable de pipelines et au volume de données devant transiter par ce changement pourtant élémentaire.

Deux résultats déterminent la suite des opérations. Le premier consiste à réduire le temps nécessaire aux nouveaux membres de l'équipe pour trouver la data view appropriée, en connectant l'agent Elastic AI aux grands modèles de langage (LLM) internes de RTL Deutschland. Cela facilitera la navigation sur la plateforme et accélérera l'accès à la data view adéquate, une étape qui, par le passé, était l'une des plus ardues du processus d'intégration.

Le deuxième consiste à intégrer un volume encore plus important de logs d'applications dans le lac de données, sans modifier le modèle de licence. Il s'agit d'une initiative interne visant à centraliser dans le lac de données les logs issus de l'ensemble des applications. La nouvelle architecture a été délibérément conçue pour anticiper cette croissance. Grâce à une capacité de 200 To reposant sur le stockage S3 et à la possibilité d'étendre facilement cet espace, l'équipe dispose de la marge nécessaire pour absorber ce volume sans a voir à réviser le modèle de licence.

Votre entreprise n'exploite peut-être pas actuellement un lac de données vieux de dix ans couvrant l'ensemble de ses activités dans le domaine de l'audiovisuel et des médias, mais les mêmes principes s'appliquent, que vous commenciez avec quelques téraoctets de données de log ou que vous passiez à une architecture hot-and-frozen de 235 To : l'empreinte sous licence n'a pas besoin d'augmenter à mesure que la période de conservation s'allonge.

RTL Allemagne fait partie du groupe RTL, la plus grande entreprise de radiodiffusion et de médias en Allemagne, avec des activités couvrant la télévision, le streaming et la production de contenu.

Découvrez comment le niveau frozen d'Elastic Observability prolonge la durée de conservation sans coût supplémentaire, ou commencez dès maintenant avec un essai gratuit.

• Elastic Observability
• Suivi des logs
• Elasticsearch
• Logstash
• Intégrations des données
• Observability Labs
• Documentation Elastic

Thèmes : Elastic Observability, Elasticsearch, Logstash, niveau frozen, snapshots interrogeables, stockage par niveaux, recherche intercluster, analyse de logs, lac de données, conservation des données de conformité, médias et audiovisuel, médias et divertissement