Phase 3: Skalierung von Tausenden von Anwendungsfällen

Ein Jahr nach der ersten Einführung des Keystone-Produkts stieg die Anzahl der Anwendungsfälle im gesamten Unternehmen schnell von weniger als einem Duzend 2015 auf einige Hundert 2017. Wir hatten zu diesem Zeitpunkt eine solide operative Grundlage geschaffen: Kunden wurden selten während der Bereitschaft benachrichtigt, und alle Infrastrukturprobleme wurden vom Plattformteam engmaschig überwacht und behoben.

Wir hatten eine stabile Plattform für die Bereitstellung aufgebaut, über die unsere Kunden Änderungen binnen weniger Minuten produktiv stellen konnten.

Das Keystone-Produkt erfüllte den Zweck, für den es ursprünglich entwickelt wurde, hervorragend: eine Routing-Plattform für Streamingdaten, die benutzerfreundlich und fast unendlich skalierbar ist. Bald wurde jedoch deutlich, dass wir weit unter den vollen Möglichkeiten bei der Streamverarbeitung blieben.

Bei unseren Bemühungen, benutzerdefinierte Anwendungsfälle zu erfüllen, stießen wir immer wieder auf neue Anforderungen nach detaillierterer Steuerung komplexer Verarbeitungsfunktionen wie Streamingverbindungen, Fenstererstellung und anderes.

Inzwischen besitzt Netflix eine einzigartige Kultur der Freiheit und des Verantwortungsbewusstseins, in der jedes Team eigene technische Entscheidungen treffen kann. Diese Kultur bietet jedem Team die Möglichkeit, sogar in maßgeschneiderte Lösungen zu investieren. Als zentrales Plattformteam haben wir enormes Wachstum erfahren. Wenn wir keine Möglichkeit fänden, alles abzudecken, kämen langfristig hohe Kosten auf das Unternehmen zu.

Es war also an der Zeit, dass das Team seine Reichweite vergrößerte. Und wieder standen wir vor neuen Herausforderungen.

Herausforderungen in Phase 3

Herausforderung 1: Benutzerdefinierte Anwendungsfälle erfordern eine andere Erfahrung für Entwickler und operativen Betrieb. Zunächst stelle ich zwei Beispiele für benutzerdefinierte Anwendungsfälle bei der Streamverarbeitung vor.

Erstens: Berechnen der Streaminggrundlagen für Empfehlungen. Damit der Empfehlungsalgorithmus von Netflix eine möglichst gute Erfahrung bietet, muss das Modell mit den neuesten Daten trainiert werden. Eine Variante des Inputs zum Trainieren des Modells ist der Datensatz für Label. Die Label liefern die direkten, zugrundeliegenden Anzeichen dafür, ob die vorherigen personalisierten Prognosen passten oder nicht.

Wenn sich der Benutzer einen empfohlenen Film ansieht, wird ein positives Label vergeben. Wie sich schon vermuten lässt, ist Geschwindigkeit wichtig: Je schneller wir einen solchen Datensatz erstellen, umso schneller erhalten wir die Feedbackschleife für das maschinelle Lernen.

Um die Label zu berechnen, müssen wir den Wirkungsstream und den Stream mit Benutzerklicks zusammenführen. Die Benutzerklicks kommen allerdings häufig erst später an. So lassen sich manche Benutzer einige Minuten Zeit für die Entscheidung oder lassen ihre Geräte stundenlang eingeschaltet, ohne etwas anzusehen. Für den Anwendungsfall muss die Streaming-Pipeline die Label ausgeben, sobald alle relevanten Informationen eingegangen sind. Dabei gilt jedoch auch Toleranz gegenüber später eingehenden Informationen.

Zweitens: Berechnen des Übernahmeanteils bei Empfehlungen. Netflix gibt personalisierte Empfehlungen, um die Benutzererfahrung zu optimieren. Eine Variante ist ein Algorithmus zur Auswahl der am besten personalisierten künstlerischen Darstellung (und der besten Positionierung dafür), um den Übernahmeanteil beim Benutzer zu optimieren.

Intern berechnet eine Pipeline für die Streamverarbeitung diese Metrik für den Übernahmeanteil annähernd in Echtzeit, indem der Datenstream für die Wiedergabe mit dem Wirkungsstream über ein benutzerdefiniertes Fenster zusammengeführt wird. Aufgrund des Umfangs von Hunderten von Millionen Netflix-Nutzern muss der Streaming-Job konstant den internen Status überprüfen, was Checkpoints zwischen ein und zehn Terabyte umfasst.

• 

A/B-Test zur Auswahl der besten künstlerischen Darstellung für die Personalisierung (Bild: Netflix)

Diese Anwendungsfälle nutzen fortschrittlichere Streamverarbeitungsfunktionen, beispielsweise komplexe Semantiken für Ereignis-/Verarbeitungszeit und Fenster, zulässige Verspätung, umfangreiches Checkpoint-Management. Zudem ist mehr operativer Support in den Bereichen Beobachtbarkeit, Fehlerbehebung und Wiederherstellung erforderlich.

Dafür müssen Entwickler ihr Vorgehen komplett umstellen und flexiblere Programmierschnittstellen und operative Funktionen wie einen benutzerdefinierten Stack für die Beobachtbarkeit, Funktionen zum Hinterfüllen sowie eine geeignete Infrastruktur für die Verwaltung vieler Terabyte lokaler Zustände nutzen. Das alles gab es bei Keystone nicht. Wir mussten also einen neuen Produkteinstiegspunkt schaffen und gleichzeitig redundante Investitionen möglichst gering halten.

Herausforderung 2: Ausgleich zwischen Flexibilität und Einfachheit. Mit all den neuen benutzerdefinierten Anwendungsfällen mussten wir das richtige Maß für die Kontrollexposition finden. Es gab die Möglichkeit, alles bis zur API auf der untersten Ebene zu exponieren, was aber eine deutlich größere operative Herausforderung bedeutete (da wir nie in der Lage sein würden, vollständig vorwegzunehmen, wie die Nutzer die Engine einsetzen). Oder wir konnten einen Mittelweg einschlagen (also nur eingeschränkte Funktionen exponieren) mit dem Risiko, dass die Kundenzufriedenheit litt.

Herausforderung 3: Höhere operative Komplexität. Durch die Unterstützung benutzerdefinierter Anwendungsfälle mussten wir den Freiheitsgrad der Plattform erhöhen. Folglich musste die operative Beobachtbarkeit in vielen komplexen Szenarien ebenfalls erhöht werden. Da zu der Zeit auch die Integration der Plattform mit vielen anderen Datenprodukten erfolgte, erhöhten sich die Berührungspunkte unseres Systems. Dies erforderte eine operative Koordinierung mit anderen Teams, um unsere gemeinsamen Kunden besser zu unterstützen.

Herausforderung 4: Zentrale Plattform oder lokale Plattform. Unser Team war dafür zuständig, eine zentralisierte Plattform für die Streamverarbeitung bereitzustellen. Aufgrund der vorherigen Strategie mit dem Fokus auf Einfachheit hatten allerdings manche Teams schon viel in ihre lokalen Plattformen zur Streamverarbeitung investiert und dabei teilweise nicht unterstützte Technologien wie Spark Streaming eingesetzt. Wir mussten sie nun davon überzeugen, auf einen schon vorhandenen Weg zurückzukehren, um das Risiko zu verringern, dass die Plattform gar nicht genutzt würde und Ressourcen für redundante Investitionen vergeudet würden. Jetzt ist die Zeit gekommen, um benutzerdefinierte Anwendungsfälle zu nutzen.

Zusammenfassung zu Streamverarbeitungsmustern in Phase 3

Muster	Produkt	Anwendungsfälle
Verbindungen zwischen Streams (ETL)	Flink	Berechnung des Übernahmeanteils, Berechnung der Label für Empfehlungsdienst
Verbindungen zwischen Stream und Tabelle (ETL)	Flink	Zusätzlicher Input: Streams verbinden mit langsamer Iceberg-Tabelle
Streamingsitzung (ETL)	Flink	Personalisierungssitzung, Metrikensitzung
Beobachtbarkeit in Echtzeit	Mantis	Verteilte Nachverfolgung, Chaos EXPER-Überwachung, Anwendungsüberwachung
Anomalie-/Betreugserkennung in Echtzeit	Mantis, Flink	Kontextwarnung, PII-Erkennung, Verhindern betrügerischer Anmeldungen
DevOps-Entscheidung in Echtzeit Tool	Mantis	Automatische Skalierung, Streaming ACA und A/B-Tests, Optimierung der CDN-Platzierung
Ereignisquelle Materialansicht	Flink	Content Delivery Network Snapshots

Streamverarbeitungsmuster in Phase 3