Eine Microservice-Welt

Netflix: Microservice Orchestration Engine Conductor jetzt Open Source

Gabriela Motroc

© Shutterstock /Stebenkov Roman

Netflix hat seine Orchestrierungs-Engine Conductor Open Source gestellt. Die Engine hat bei Netflix dabei geholfen, 2,6 Millionen Prozessabläufe von einfachen linearen bis zu sehr dynamischen, komplexen Workflows zu orchestrieren, die über mehrere Tage liefen. Wir werfen einen Blick unter die Haube.

Viren Baraiya, Architekt bei Netflix, erklärt in einem Blogpost, dass „das Netflix Content-Platform-Engineering-Team einige Geschäftsprozesse betreibt, die auf der asynchronen Orchestrierung von Task basieren, die auf Microservices laufen“. Er zeigt auf, das sich einige dieser langlaufenden Prozesse über mehrere Tage erstrecken und hob hervor, dass es ihre Rolle ist, Videos für die Zuschauer auf der ganzen Welt für das Streaming vorzubereiten.

Klassischer Weise wurden diese Prozesse ad-hoc orchestriert, indem man auf eine Kombination von pub/sub, direkten REST Calls und einer Datenbank für die Zustände zurückgriff. Zu den Prozessen zählen unter anderem die Aufnahme von Content, das Encoding und das Deployment in das Content Delivery Network. Da die Anzahl der Microservices weiter ansteigt und die Komplexität der Prozesse weiter wächst, wurde es immer schwieriger die Übersicht über die verteilten Workflows zu behalten ohne eine zentrale Orchestrierung einzusetzen.

Warum Conductor nötig war

Hier kommt Conductor ins Spiel: Es adressiert Anforderungen wie die Fähigkeit synchron Tasks abzuarbeiten, es skaliert auf mehrere Millionen an gleichzeitig laufenden Prozessabläufen und es kann Prozesse pausieren, wieder aufnehmen und neu starten. Damit ist keiner Boilerplate-Code in den Anwendungen mehr nötig. Conductor bietet zusätzlich folgende Features:

  • Es erlaubt komplexe Prozess- und Geschäftsabläufe zu bauen, bei denen jeder indiviudelle Task in einem Microservice implementiert ist
  • JSON-DSL-Blaupause definiert das Ausführen des Ablaufs
  • Sichtbarkeit und Nachverfolgbarkeit für diese Prozessabläufe
  • User Interface für die Visualisierung der Prozessabläufe
  • Wird von einem Queuing-Service abgesichert, der vom Client abstrahiert ist
  • Ist in der Lage auf HTTP zu arbeiten oder anderen Kommunikationsmöglichkeiten wie gRPC

So ist Conductor aufgebaut

netflix_conductor

Architektur-Überblick über Conductor (Quelle: https://netflix.github.io/conductor/intro/)

Im Kern von Conductor liegt ein State-Machine-Service, der sogenannte Decider Service, der die Blaupause des Workflows mit dem aktuellen Zustand des Workflows kombiniert. Er identifiziert den nächsten Zustand und plant dementsprechend Tasks oder aktualisiert den Zustand des Workflows. Das Netflix-Team hat dyno-queues zusätzlich zu Dynomite genutzt, um verteilte, verzögerte Queues zu managen.

Die Orchestrierungs-Engine folgt einem RPC-basierten Kommunikationsmodell, bei dem Worker auf einer separate Maschine laufen. Die Worker kommunizieren mit den Servern über HTTP-basierte Endpunkte und verwenden ein Polling-Modell, um die Queues zu managen.

Die Tasks (implementiert von den Worker-Anwendungen) kommunizieren über ein API Layer. Die Orchestrierungs-Engine liefert die APIs, um die Größe des Workloads für jeden Worker zu inspizieren und um die Worker-Instanzen automatisch zu skalieren. Die APIs werden per HTTP exponiert. Das sorgt dafür, dass sich verschiedene Clients einfach integrieren lassen.

Netflix nutzt Dynomite als eine Speicher-Engine zusammen mit Elasticsearch für das Indexieren der ausgeführten Abläufe.

netflix_conductor_overview

Runtime-Modell von Conductor (Quelle: https://netflix.github.io/conductor/intro/)

Darum ein eigenes Tool

Baraiya erklärt, dass sie damit angefangen haben eine frühe Version eines einfachen Workflows mit Amazon SWF umzusetzen. Aber sie haben sich dazu entschlossen Conductor zu entwickeln, weil sie mit Einschränkungen von SWF nicht zurechtkamen. Netflix brauchte einen Blaupausen-basierte Orchestrierung, während SWF auf programmatische Entscheider setzt. Außerdem brauchten sie die synchrone Natur von APIs anstatt lediglich Nachrichten-basierte Kommunikation, um die In- und Outputs für die Workflows und Tasks zu indexieren sowie die Workflows auch durchsuchen zu können. Sie benötigen auch einen separaten Datenspeicher, um Workflow Events zu speichern und im Fehlerfall wieder herstellen zu können. AWS Step Functions hat einige der Funktionen nachgelegt, die Netflix gebraucht hätte. So wird Conductor eventuell die States Language für das Definieren von Workflows übernehmen.

Verwandte Themen:

Geschrieben von
Gabriela Motroc
Gabriela Motroc
Gabriela Motroc ist Online-Redakteurin für JAXenter.com. Vor S&S Media studierte Sie International Communication Management an der The Hague University of Applied Sciences.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: