Phase 2: Skalierung für Hunderte von Anwendungsfällen

Nach der Bereitstellung des ersten Keystone-MVP und der Migration einiger interner Kunden haben wir nach und nach an Zutrauen gewonnen. Außerdem verbreiteten sich die Neuigkeiten an andere Entwicklerteams. Das Streaming bei Netflix gewann an Dynamik, da es inzwischen ganz leicht ist, Protokolle für die analytische Verarbeitung zu verschieben und operative Informationen nach Bedarf abzurufen.

Jetzt war die Zeit für eine Skalierung auf die allgemeinen Kunden gekommen.

• 

Diagramm zur sich entwickelnden Keystone-Architektur, circa 2016. Keystone enthält Kafka- und Flink-Engines als Kernkomponenten. Weitere Details zum technischen Design finden sich in Blogposts mit dem Schwerpunkt Kafka und Flink. (Bild: Zhenzhong Xu)

Herausforderungen in Phase 2

Herausforderung 1: Erhöhte operative Last. Anfangs boten wir unseren Neukunden einen umfassenden Einführungsservice. Das ließ sich mit wachsender Nachfrage allerdings nicht lange durchhalten. Wir mussten anfangen, das MVP weiterzuentwickeln, um mehr als nur ein Dutzend Kunden zu unterstützen.

In der Folge mussten wir einige Komponenten umbauen. Beispielsweise war die Zeit gekommen, uns von reinen Tabellen zu einer ordentlichen Steuerungsplattform mit Datenbank im Hintergrund zu entwickeln.

Herausforderung 2: Unterschiedliche Bedürfnisse. Als die Kundenanfragen zunahmen, standen wir vor immer vielfältigeren Bedürfnissen. Diese lassen sich in zwei wichtige Kategorien unterteilen: Eine Gruppe bevorzugte einen voll verwalteten Service mit einfacher Nutzung. Die andere Gruppe bevorzugte Flexibilität und benötigte komplexe Rechenfähigkeiten, um umfangreichere geschäftliche Probleme zu lösen. Für sie war es völlig in Ordnung, Pager zu nutzen und Teile der Infrastruktur selbst zu verwalten. Aber wir können nicht beides gleichzeitig gut machen.

Herausforderung 3: Alles, was wir anfassten, ging kaputt. Ganz im Ernst: Aufgrund der Skalierung haben wir alle unsere abhängigen Services irgendwann kaputt gemacht. Wir haben einmal AWS S3 kaputt gemacht. Wie haben viele Bugs in Kafka und Flink gefunden. Wir haben Titus (die verwaltete Containerinfrastruktur) mehrmals kaputt gemacht und sind auf merkwürdige Probleme mit der CPU-Isolierung und Netzwerken gestoßen. Wir haben Spinnaker (die Plattform für das kontinuierliche Deployment) kaputt gemacht, als wir Hunderte von Kunden-Deployments automatisch gestartet haben.

Zum Glück waren diese Teams hervorragend. Sie haben mit uns gemeinsam diese Probleme nach und nach behoben. Diese Anstrengungen tragen entscheidend zur Reifung der gesamten Streaminglandschaft bei.

Zusammenfassung zu Streamverarbeitungsmustern in Phase 2

Muster	Produkt	Anwendungsfälle
Datenrouting	Keystone	Protokollierung, Datenbewegung (+ skaliert)
Echtzeit-Datenstichproben / Entdeckung	Mantis	Kostengünstige Echtzeitinformationen
Echtzeitwarnungen / Dashboard	Mantis, Kafka	SPS-Warnung, + Infrastrukturzustand-Überwachung (Cassandra & Elasticsearch), + Echtzeit-QoE-Überwachung

Streamverarbeitungsmuster in Phase 2