Wie Netflix die Kosten seiner Dateninfrastruktur effizienter gestaltet

Aufgrund der verteilten Infrastruktur von Netflix und der internen Kultur der „Freiheit und Verantwortung“ ist Effizienzsteigerung keine leichte Aufgabe. Daher wurde ein maßgeschneidertes Dashboard entwickelt, das Kostentransparenz schafft und den für Optimierung relevanten Kontext näher an die Entscheidungsträger bringt.

So wurde dieses „Data Efficiency Dashboard“ aufgebaut – und das sind die wichtigsten Erkenntnisse daraus.

• Die Datenplattform-Umgebung von Netflix lässt sich in zwei Kategorien einteilen

1. Data at Rest: Snowflake, S3, Hive, RDS, ElasticSearch, Cassandra, Druid

2. Data in Motion: Keystone, Flink, Mantis, Spark, Kafka, Presto

** Nutzungs- und Kostentransparenz auf einen Blick **

Die Kosten aller Plattformen werden zusammengeführt, einschließlich Informationen, mit denen sich diese Kosten in sinnvolle Einheiten aufschlüsseln lassen.

→ Einheiten: Tabellen, Indizes, Column Families, Jobs usw.

Die Quelle dieser Kosteninformationen basiert im Wesentlichen auf AWS-Abrechnungsdaten, die nach Services und Tags kategorisiert sind. Damit allein ist jedoch keine Zuordnung nach Ressource oder Team möglich, daher wurden folgende Methoden verwendet:

• EC2-basierte Plattformen

→ Für jede Plattform werden Metriken definiert, die Engpässe verursachen (Bottleneck-Metriken).

→ Kafka ist zum Beispiel netzwerkgebunden, während Spark durch CPU und Speicher gebunden ist.

→ Mithilfe von Atlas sowie Plattform-Logs und REST-APIs werden Metriken pro Ressource unterschieden und Kosten zugeordnet.

• S3-basierte Plattformen

→ Jede Ressource erhält ein eigenes S3-Präfix, und die Kosten pro Ressource werden auf Basis der Storage-Preise berechnet.

• Dashboard-Ansicht

Mit einem benutzerdefinierten Dashboard auf Basis von Apache Druid werden die einzelnen Kosten den Teams zugeordnet.

Die wichtigsten Nutzer dieser Kosteninformationen sind die Engineering- und Datenteams, damit sie auf Basis dieser Informationen Maßnahmen ergreifen können.

Zusätzlich erhalten Engineering-Führungskräfte eine Ansicht auf höherer Ebene.

Je nach Use Case lassen sich die Daten nach Datenressourcen oder Organisationseinheiten gruppieren und sowohl als Snapshot als auch als Zeitreihe betrachten.

** Automatisierte Storage-Empfehlungen – Time to Live (TTL) **

In einigen Szenarien geht das System über reine Transparenz hinaus und liefert auch Optimierungsempfehlungen.

Da Datenspeicher stark genutzt werden und Kosten häufig „Momentum“ entwickeln, also nach dem Ablegen leicht in Vergessenheit geraten,

wurde die Analyse zur Bestimmung der optimalen Speicherdauer (TTL) auf Basis von Datennutzungsmustern automatisiert.

Für Tabellen in Big-Data-Warehouses auf S3 wurden TTL-Empfehlungen eingeführt.

• Kostenberechnung und Business-Logik

Die größten S3-Kosten entstehen bei Transaktionstabellen, die in der Regel nach Datum partitioniert sind.

Mithilfe von S3-Access-Logs und einem Mapping von S3-Präfixen zu Tabellenpartitionen lässt sich bestimmen, auf welche Datums-Partitionen zugegriffen wird.

Dafür werden die Zugriffsaktivitäten (Lesen/Schreiben) der letzten 180 Tage ausgewertet und der maximale Lookback-Zeitraum ermittelt.

Dieser Lookback-Zeitraum bestimmt den TTL-Wert der jeweiligen Tabelle.

Auf Basis dieses berechneten TTL-Werts werden die realisierbaren jährlichen Einsparungen berechnet.

• Dashboard-Ansicht

Datenverantwortliche können detaillierte Datenzugriffsmuster einsehen, den empfohlenen TTL-Wert mit dem aktuellen vergleichen und die möglichen Kosteneinsparungen prüfen.

** Kommunikation und Nutzerbenachrichtigung **

Das Prüfen von Datenkosten sollte nicht zum Tagesgeschäft von Technikteams werden – insbesondere nicht bei irrelevanten Datenkosten.

Daher wurde eine Funktion entwickelt, die nur Teams mit hohem Datenverbrauch per E-Mail-Push benachrichtigt, um das Kostenbewusstsein zu erhöhen.

Außerdem werden automatische TTL-Empfehlungen nur für Tabellen verschickt, bei denen Kosteneinsparungen möglich sind.

Derzeit werden diese E-Mails monatlich versendet.

** Erkenntnisse und Herausforderungen **

1. Das Identifizieren und Pflegen der Metadaten einzelner Assets ist entscheidend für die Kostenzuordnung.

→ Dafür wurde ein Metadaten-Repository namens Netflix Data Catalog (NDC) aufgebaut.

→ Dadurch wurden Datenzugriff und Suche vereinfacht, sodass sich sowohl bestehende als auch neue Daten verwalten lassen.

→ NDC dient als Ausgangspunkt für die Kostenberechnung.

2. Zeitreihendaten sind herausfordernd.

→ Trenddaten verursachen deutlich mehr Verwaltungsaufwand als Snapshots.

→ Aufgrund von Dateninkonsistenzen und Verarbeitungsverzögerungen ist es schwierig, eine konsistente Sicht bereitzustellen.

→ Dabei mussten zwei Probleme gelöst werden.

• Änderungen der Ressourcenverantwortung: Bei Snapshots müssen Eigentümerwechsel automatisch berücksichtigt werden, und in der Zeitreihenansicht müssen selbst diese Änderungen in den Metadaten reflektiert werden.

• Zustandsverlust bei Datenproblemen: Die Metadaten von Ressourcen werden per API aus verschiedenen Quellen extrahiert. Scheitert die Erfassung, geht der Zustand verloren. Da solche Daten flüchtig sind, stößt reine API-Extraktion an Grenzen. Deshalb müssen Alternativen gefunden werden, etwa das Einspeisen der Daten in Richtung Keystone.

** Fazit **

Wenn eine hochgradig verteilte Datenplattform vorhanden ist, kann ein solches Dashboard die Effizienz deutlich steigern, indem es Feedback-Schleifen erzeugt und Nutzungs- sowie Kostenkontext zusammenführt.

Wenn möglich, sollte Effizienz zusätzlich durch automatisierte Empfehlungen erhöht werden.

Bei Netflix zeigte insbesondere die Empfehlung von Datenaufbewahrungsfristen einen hohen ROI.

Mit diesem Dashboard und den TTL-Empfehlungen konnte der Storage-Bedarf des gesamten Data Warehouse um mehr als 10 % reduziert werden.

[kunggom]

Offenbar war die Empfehlungsfunktion nicht nur für die Zuschauer gedacht.

[heycalmdown]

Schön. Ich habe irgendwo einmal eine Studie gesehen, wonach man sogar unwillkürliche Muskeln bewegen kann, wenn man eine Echtzeit-Monitoring-Maschine sehen kann, und daran musste ich plötzlich denken.