Stefan Toth
09.05.2015
Diese Blogserie beleuchtet Netflix' Microservices-Architektur. Die erste Folge stellt mit der umgekehrten Architekturbewertung eine Methode vor, die von Architekturentscheidungen auf passende Anforderungen zurückschließt.
Netflix - das größte Internet-Business in den USA - zeichnet sich zeitweise für ein Drittel des gesamten Downstream-Traffics des Webs verantwortlich. Über 2 Milliarden Stunden Filme und Serien sind für Mitglieder verfügbar (nicht in jedem Land, aber dennoch eine beeindruckende Zahl).
Netflix is the king of online streaming, using more global bandwidth than cat videos and piracy combined.
Die Erfolge der Video-on-Demand Plattform basieren nicht nur auf einer guten Geschäftsidee, sondern auch auf top-modernen und effizienten Technologien, Frameworks und Architekturansätzen. Netflix ist nicht nur groß, sondern auch robust und hochgradig auf Benutzbarkeit ausgerichtet. Der Qualitätsanspruch ist enorm: „Netflix-Mitglieder können Serien und Filme schauen – so viele sie wollen, jederzeit, überall, auf fast jedem Internet-verbundenem Bildschirm”. Eine zentrale Ansage, ein Versprechen und eine Architekturherausforderung. Was können wir nun daraus lernen? Ist es an der Zeit unsere Systeme und Architekturen in Microservices zu refactoren, große Datenbanksysteme aufzubrechen, polyglott zu programmieren und reaktive Ansätze zu verwenden?
In dieser kleinen Blogserie wollen wir uns um die Beantwortung dieser Fragen kümmern. In einer umgekehrten Architekturbewertung haben wir jene Anforderungen und Rahmenbedingungen herausgearbeitet, die man haben müsste, um die Netflix-Architektur als ideal zu bewerten. Welche Qualitätsaussagen müssten Ihnen wichtig sein? Zu welchen Kompromissaussagen müssten Sie ‚ja‘ sagen? Welche Risiken müssten Sie eingehen und welche Rahmenbedingungen bräuchten Sie?
Um herauszufinden in welchen Kontexten und für welche Fragestellungen die Architekturkonzepte von Netflix tauglich sind, haben wir uns bewährten Mitteln bedient. Architekturbewertungsmethoden leisten im Kern das, was wir hier brauchen. Sie gehen jedoch meist davon aus, dass der Kontext gesetzt ist und man ein System für die Eignung in diesem Kontext bewertet. Das folgende Bild zeigt einen konzeptionellen Überblick.
Abb. 1: Wie Architekturbewertung grob funktioniert
Bewertungsmethoden wie die ATAM (Architecture Tradeoff Analysis Method), CBAM (Cost-Benefit-Analysis-Method) oder SACAM (Software-Architecture comparison Analysis Method) verfeinern die an die Architektur gestellten Ziele und Rahmenbedingungen bis zu konkreten Qualitätsaussagen (sogenannten Qualitässzenarien). Hält man diese Aussagen gegen die getroffenen Architekturentscheidungen und –ansätze offenbaren sich potentiell Risiken, Probleme oder Schwächen der Softwarelösung.
In der umgekehrten Architekturbewertung wollen wir nun genau den anderen Weg einschlagen. Wir gehen von der Lösung aus, sehen uns die Entscheidungen, Konzepte und Prinzipien an. Basierend darauf überlegen wir uns welche Ziele und Rahmenbedingungen man haben müsste bzw. Qualitätsaussagen einem wichtig sein müssten um solche Entscheidungen zu treffen. Das folgende Bild illustriert diesen Prozess.
Abb. 2: Umgekehrte Architekturbewertung (Copyright embarc)
Wir werden in diesem Blogpost nun grob in die Welt von Netflix eintauchen und in weiteren Posts die Details der umgekehrten Bewertung zusammenfassen.
Neben diesen Beiträgen habe ich auch einen ausführlichen JavaMagazin-Artikel zu Verfügbarkeit und Resilience bei Netflix geschrieben der mittlerweile online verfügbar ist: Keine Angst vor Chaos
Um zu verstehen wie groß die Herausforderung eigentlich ist, zeigt Abbildung 1 eine topologische Sicht auf Netflix. Die grünen Bereiche zeigen Services von Netflix. Insgesamt sind es über 600 verschiedene Services, die jeweils drei bis mehrere hundert Mal installiert sind. Der Übersicht halber zeigt Abbildung 1 diese Redundanz nicht. Die blauen Linien zeigen Abhängigkeiten bzw. Aufrufwege. Greift man auf die Webseite zu, trifft man etwa 20-30 Prozesse im Front Tier, dahinter wird es komplizierter.
Abb. 3: Netflix: Topologie-Sicht. Screenshot aus AppDynamics (Quelle: A. Tseitlin, Resiliency through failure, QCon NY, 2013)
Insgesamt arbeiten etwa 50-60 Teams an diesem System, das auf zehntausenden Ec2 Instanzen der Amazon Cloud (Amazon Web Services – AWS) betrieben wird. Terabytes an Daten liegen in einem globalen Cassandra-Ring – und das schließt die Video-Dateien, also den eigentlichen Content NICHT ein.
Es ist eine gewisse Hürde ein solches System in einer realistischen Testumgebung nachzubauen, Daten(-verteilungen) und Benutzerverhalten realistisch zu simulieren und dieses System analytisch zu betrachten. Netflix möchte trotz allem äußerst innovativ bleiben, neue Features schnell ausliefern und damit den Vorsprung auf die Konkurrenz zumindest halten. 60 Teams in diesem Umfeld zu koordinieren ist schwierig, Konsistenz in allen Lösungsdetails nicht oder nur nur sehr aufwändig herstellbar. Kein Wunder, dass Netflix hier kreativ wurde und neue Architekturansätze suchte. Wir rollen Sie in den folgenden Posts Stück für Stück auf und zeigen ob sie generell anwendbar sind, ob es sich eher um Sonderlösungen handelt, oder ob um Netflix eher eine inhaltsleere Hype-Blase wächst.
Teil 1: Die umgekehrte Architekturbewertung
Teil 2: Microservices
Teil 3: Netflix Open Source Services (OSS)