Wie RTL Deutschland die Kundenbindung mit dem Frozen Tier von Elastic Observability verdreifachte – und das ohne Ausfallzeiten beim Umstieg

RTL Deutschland konzipierte seinen zentralen Data Lake neu, stellte von einer 30-tägigen auf eine 90-tägige Standardspeicherung um, verringerte die Anzahl der Knoten um fast die Hälfte und schloss die Migration ohne Datenverlust ab.

RTL Deutschland unterhält einen unternehmensweiten Elastic Data Lake, der sich in knapp einem Jahrzehnt zur abteilungsübergreifenden Standardplattform für Protokollierung, Anwendungsdaten und Business Intelligence entwickelt hat. Ein On-Prem-Speicher von 100 TB hatte die Standardaufbewahrungszeit auf etwa 30 Tage beschränkt, was Teams, die untersuchen wollten, wie sich KPIs über Monate entwickeln, blockierte und sie zwang, Compliance-Daten in separaten S3-Buckets außerhalb des durchsuchbaren Data Lakes zu speichern. Nach einem Upgrade von Platinum auf Enterprise und der Neugestaltung mit durchsuchbaren Snapshots und dem Frozen Tier verdreifachte sich die Standardaufbewahrungsdauer auf 90 Tage, die kombinierte Kapazität wuchs bei gleichem Lizenzumfang auf 235 TB, der Hypervisor-Footprint sank von 18 auf 10 physische Knoten, und die gesamte Umstellung verlief ohne Ausfallzeiten und Datenverlust.

Der Elastic Data Lake von RTL Deutschland deckt fast ein Jahrzehnt unternehmensweites Logging, Anwendungsdaten und Business Intelligence im gesamten Rundfunk- und Medienbereich ab. 2024 jedoch stieß er an seine Grenzen. Die rund 100 TB an On-Prem-Speicher begrenzten die Standardspeicherdauer auf etwa 30 Tage. Mehrere Abteilungen benötigten jedoch monatelange Aufzeichnungen, um die Entwicklung der KPIs im Laufe der Zeit nachverfolgen zu können. Compliance-Daten, die gemäß interner Richtlinien einer Aufbewahrungspflicht von sechs Monaten unterlagen, befanden sich außerhalb der durchsuchbaren Plattform in separaten S3-Buckets. Nach einem Upgrade von Platinum auf Enterprise und der Neugestaltung mit durchsuchbaren Snapshots und einem Frozen Tier verdreifachte RTL Deutschland die Standardaufbewahrungsdauer auf 90 Tage, die Gesamtkapazität wuchs bei gleichem Lizenzumfang auf 235 TB, der Hypervisor-Footprint sank von 18 auf 10 physische Knoten und die gesamte Umstellung verlief ohne Ausfallzeiten und ohne Datenverlust.

30 Tage verhindern nicht nur eine längere Historie, sondern auch viele Abfragen: Quartalsvergleiche, saisonale Zyklen im Jahresvergleich, Werte, deren Bezugsdauer lang genug ist, um Trenddiagramme glaubwürdig zu machen. Für die BI-Nutzer von RTL Deutschland enthielt der Data Lake die operativen Daten, erreichte aber bei Weitem nicht den Punkt, ab dem Analysen möglich gewesen wären. Mit 90 Tagen Historie als Standard und einem vollen Jahr bei einigen Indizes können solche Fragen nun innerhalb desselben Data Lake beantwortet werden, den die operativen Teams live beobachten, mit denselben Daten, ohne sie woandershin exportieren zu müssen.

Dieses Ergebnis beruht auf zwei unterschiedlichen Übergängen während der Laufzeit der Plattform: einer Konsolidierung auf Elastic im Jahr 2023, nachdem eine Unternehmensfusion eine zweite Logging-Plattform eingeführt hatte, und dem späteren Lizenz-Upgrade, das die Speicherarchitektur so umgestaltete, dass sich die Speicherkapazität verdreifacht, ohne den lizenzierten Umfang zu vergrößern.

Die Elastic-Umgebung von RTL Deutschland begann vor knapp einem Jahrzehnt als gemeinsames Infrastrukturtool und entwickelte sich Team für Team zum unternehmensweiten Data Lake. Zwei Ereignisse haben die Plattform in ihrer heutigen Form geprägt.

Die erste war eine Konsolidierung nach einer Fusion im Jahr 2023. Die neu hinzugekommene Unternehmenseinheit betrieb eine andere Protokollierungsplattform. Die Elastic-Umgebung von RTL Deutschland war bereits On-Prem und verfügte über freie Kapazitäten, und der parallele Betrieb von zwei Plattformen war weder finanziell noch betrieblich sinnvoll. Die Migration vom alten Logging-Tool dauerte etwa fünf Monate, wobei die größte Herausforderung die Kommunikation der Wiederaufbau der Dashboards und Benachrichtigungsworkflows war, die das Team über Jahre aufgebaut hatte, sowie die Überarbeitung der Ingest-Pipelines.

Die zweite war die Speicherbegrenzung und der Weg aus ihr heraus. Nach der Entdeckung durchsuchbarer Snapshots und des Frozen Tiers bei Elastic{ON} München fand das Team ein Design, das direkt zum Speicherproblem passte: Den lizenzierten Fußabdruck behalten, Long-Tail-Daten auf S3-gestützte Kaltlagerung übertragen und den freigewordenen Hot-Tier-Freiraum nutzen, um die Aufbewahrungsdauer zu verlängern. Bevor sich das Team festlegte, erstellte es eine Machbarkeitsstudie, die sich auf die einzig wichtige Frage konzentrierte: Wie schnell ließen sich Abfragen älterer Daten auf dem Frozen Tier ausführen? Das Ergebnis war so schnell, dass die Entscheidung, den gesamten Cluster von Hot-and-Cold auf Hot-and-Frozen umzustellen, keine Frage mehr war.

Vor dem Redesign war die Standardaufbewahrung von RTL Deutschland durch 100 TB On-Prem-Speicher auf etwa 30 Tage begrenzt. Der Data Lake war stabil, aber drei betriebliche Herausforderungen stießen gleichzeitig an ihre Grenzen.

Business Intelligence benötigte mehr als 30 Tage. Einige Abteilungen wollten verfolgen, wie sich KPIs im Laufe der Zeit entwickelten. Dreißig Tage an historischen Daten reichten nicht aus, um diese Arbeit im Data Lake durchzuführen. Die Teams verfügten zwar über die für den operativen Betrieb notwendigen Daten, aber nicht über das nötige Zeitfenster für deren Analyse.

Die Compliance-Daten befanden sich außerhalb des Datensees. Firewall-Daten, für die die interne Richtlinie eine Aufbewahrungsfrist von sechs Monaten vorsah, wurden in separaten S3-Buckets gespeichert, nicht auf der durchsuchbaren Plattform. Die Daten wurden erhalten, aber der Zugriff darauf während einer Untersuchung erforderte, sie aus dem Objektspeicher zu ziehen und in ein durchsuchbares Format zu laden, was das Team im Realfall als ziemlich lästig beschrieb.

Die Hardware wurde älter. Der Cluster lief auf Servern, die etwa fünf oder sechs Jahre alt waren, mit Standard-SSDs statt NVMe. Das Team wusste, dass eine Hardware-Aktualisierung irgendwann kommen würde, egal, ob sich die Architektur änderte oder nicht.

Es wurde Zeit dafür verwendet, die bestehende Plattform auf dem aktuellen Stand zu halten, nicht dafür, ihre Funktionalitäten für den Rest des Unternehmens zu erweitern.

Das Team führte ein Upgrade von Platinum auf Enterprise durch, um durchsuchbare Snapshots und den Frozen Tier freizuschalten, und stellte anschließend das Speicherlayout von Hot-and-Cold auf ein Hot-and-Frozen-Modell um, das auf S3 basiert.

Der End-to-End-Datenfluss blieb der gleiche. Logstash-Nodes ingestieren aus Datenquellen in der gesamten Organisation und schreiben in Elastic ein. Die Hot-Indizes befinden sich auf lokalen NVMe-SSDs im neuen Cluster. Ältere Indizes wechseln in die gefrorene Speicherebene, wo sie in S3 gespeichert und bei Abfrage in einen lokalen Cache gezogen werden. Cross-Cluster-Suchen verbanden während der Umstellung die alten und neuen Cluster, sodass Nutzer historische Daten erreichen konnten, ohne die Umgebung zu wechseln.

Der Leistungskompromiss erwies sich als handhabbar. Die erste Abfrage gegen einen Index im Frozen Tier dauert etwa 30 Sekunden, während die relevanten Daten in den Cache der eingefrorenen Knoten geladen werden. Danach werden Abfragen für dieselben Daten mit Hot-Tier-Geschwindigkeit ausgeführt.

• Hot-Tier-Abfragegeschwindigkeit für aktuelle Daten: 35 TB NVMe SSD auf neueren Servern, die auf KVM laufen.
• Monate- bis jahrelange Aufbewahrung zu geringen Kosten: 200 TB S3-gesicherte Kaltlagerung, bereitgestellt über durchsuchbare Snapshots.
• Verdreifachte Kapazität bei demselben lizenzierten Umfang: 235 TB insgesamt (35 TB Hot plus 200 TB Frozen), keine Erhöhung der lizenzierten Ressourceneinheiten.
• Kleinerer, schnellerer Cluster: Der Hypervisor-Footprint wurde von 18 auf 10 physische Nodes reduziert, auf neuerer Hardware mit mehr Kernen pro Node.
• Workload-weise Umstellung ohne Neustrukturierung der Pipeline: Logstash übernahm weiterhin die Ingestion; die Ziele wurden während der Migration pro Datenquelle umgeleitet.
• Kein Verlust des Zugriffs auf historische Daten während der Migration: Die Cross-Cluster-Suche war durchgehend aktiv, sodass Nutzer weiterhin ältere Indizes auf dem alten Cluster lesen konnten, während neue Daten zum neuen Cluster flossen.
• Hot-Tier-Geschwindigkeit bei älteren Daten nach der ersten Abfrage: etwa 30 Sekunden für das „Auftauen“ des Frozen-Tier-Caches bei der ersten Abfrage; nachfolgende Abfragen laufen mit Hot-Tier-Geschwindigkeit.

Anstatt eines Wechsels richtete das Team den neuen Cluster neben dem alten ein und migrierte Workload für Workload, beginnend mit den größten Datenquellen. Da die Ingestion über Logstash ausgeführt wird, war das Verschieben einer Workload oft so einfach wie das Ändern des Ziels auf dem Logstash-Node vom Master des alten Clusters zum Master des neuen. Durch das clusterübergreifende Suchen blieben die Nutzer in der neuen Umgebung und hatten weiterhin Lesezugriff auf Daten im alten Cluster, sodass die historischen Daten durchgehend erreichbar blieben.

Das Team nutzte außerdem die Gelegenheit, kundenspezifische Ingest-Pipelines auf die von Elastic verwalteten Integrationen zu migrieren, was sie als den besseren Weg für die Zukunft beschreiben.

Durch Elastic Support konnte der Überlappungszeitraum verlängert werden, als es zu Verzögerungen bei den Hardwarelieferungen kam. Das Team hob dies ausdrücklich als einen der Faktoren hervor, die zum Gelingen des Zeitplans beitrugen.

Der Proof-of-Concept selbst dauerte etwa zwei Wochen. Der größte Teil des sechs- bis achtwöchigen PoC-Zeitplans wurde für die Beschaffung und das Bereitstellen von Hardware verwendet, nicht für das Testen. Der vollständige Cutover dauerte etwa drei Monate und wurde ohne Ausfallzeiten oder Datenverlust abgeschlossen.

Für die Abteilungen, die den Data Lake täglich nutzen, war die Änderung nahezu unsichtbar. Nutzer mussten ihre Lesezeichen während der vorübergehenden Überlappung auf die neue URL ausrichten und nach dem Wechsel wieder zur Standard-Domain wechseln. Durch das clusterübergreifende Suchen blieben die historischen Daten vom neuen Cluster aus jederzeit erreichbar, sodass niemand einen neuen Workflow erlernen oder zwei Systeme abfragen musste, um alte Daten zu finden.

Für die Compliance befinden sich die Daten, die zuvor in separaten S3-Buckets gespeichert waren, jetzt im durchsuchbaren Data Lake. Eine sechsmonatige Firewall-Aufbewahrung ist kein Workflow-Problem mehr. Wenn eine Abteilung das gesamte Aufbewahrungsfenster abfragen muss, fragt sie auf die gleiche Weise ab, wie bei allem anderen im Data Lake.

Aus dem Projekt ließen sich einige praktische Lehren ziehen.

Nutzen Sie nach Möglichkeit verwaltete Integrationen. RTL Deutschland verfügte über jahrelange kundenspezifische Ingest-Pipelines und migrierte viele davon während des Umstiegs auf die von Elastic gepflegten Integrationen. Das Team bezeichnete dies als einen besseren Weg für die Zukunft, nicht nur für dieses Projekt.

Behandeln Sie eine Migration als Facelift. Das gleichzeitige Ersetzen alter Hardware, Modernisieren der Architektur und Überarbeiten von Integrationen vervielfachte den Wert des Projekts im Vergleich zur Durchführung einer einzelnen Maßnahme.

Bewerten Sie das Hosting-Modell ehrlich. On-Prem war angesichts der vorhandenen Ressourcen und kommerziellen Überlegungen von RTL Deutschland sinnvoll. Für kleinere Unternehmen, die nicht über die internen Kapazitäten verfügen, einen Cluster einzurichten und auszuführen, würde das Team auf die SaaS-Option von Elastic verweisen, um operativen Aufwand zu vermeiden.

Das Schwierige ist das Volumen, nicht die Komplexität. Die Umleitung der Ingestion von einem Cluster zu einem anderen war unkompliziert. Die eigentliche Herausforderung bestand in der schieren Anzahl der Pipelines und dem Skalieren der Daten, die diese einfache Änderung durchlaufen mussten.

Zwei Ergebnisse bestimmen, was als Nächstes kommt. Das erste: Eine Verkürzung der Zeit, die neue Teammitglieder benötigen, um die richtige Datenansicht zu finden, indem der Elastic AI Agent mit den internen Large Language Models (LLMs) von RTL Deutschland verbunden wird. Dies wird neuen Teammitgliedern helfen, sich auf der Plattform zurechtzufinden und richtige Datenansichten schneller zu finden, was historisch gesehen immer einer der schwierigeren Onboarding-Schritte war.

Das zweite: Die Aufnahme weiterer Anwendungsprotokolle in den Data Lake, ohne den Lizenzumfang erneut überprüfen zu müssen. Dabei handelt es sich um ein internes Programm, das noch mehr Anwendungsprotokolle jeder Anwendung in den Data Lake aufnimmt. Die neue Architektur wurde bewusst im Hinblick auf dieses Wachstum entworfen. Mit 200 TB S3-gestützter Kapazität und der Möglichkeit, diesen Speicherplatz problemlos zu erweitern, hat das Team genügend Spielraum, um das Volumen aufzunehmen, ohne den Lizenzumfang zu ändern.

Ihre Organisation betreibt heute vielleicht keinen zehn Jahre alten Data Lake, der ein ganzes Rundfunk- und Mediengeschäft abdeckt, aber egal ob Sie mit ein paar Terabyte an Log-Daten beginnen oder auf eine 235 TB Hot-and-Frozen-Architektur skalieren: Der lizenzierte Footprint muss nicht mit dem Aufbewahrungsfenster wachsen.

RTL Germany ist Teil der RTL Group, dem größten Rundfunk- und Medienunternehmen Deutschlands, dessen Aktivitäten Fernsehen, Streaming und Content-Produktion umfassen.

Erfahren Sie, wie der Frozen Tier von Elastic Observability die Aufbewahrungsdauer verlängert, ohne zusätzliche Kosten zu verursachen, oder starten Sie jetzt mit einer kostenlosen Testversion.

• Elastic Observability
• Log-Monitoring
• Elasticsearch
• Logstash
• Datenintegrationen
• Observability Labs
• Elastic-Dokumentation

Themen: Elastic Observability, Elasticsearch, Logstash, Frozen Tier, durchsuchbare Snapshots, gestufte Speicher, Cross-Cluster-Suche, Log-Analyse, Data Lake, Compliance-Datenaufbewahrung, Medien und Rundfunk, Medien und Unterhaltung