GraphQL: Netflix' API-Migration für Hunderte Millionen Nutzer
Für seinen Videostreamingdienst müssen die Entwickler von Netflix "den Eindruck erwecken, dass alle Daten ihrer Anwendung direkt auf dem Gerät des Benutzers liegen und nur darauf warten, angezeigt zu werden. Damit dieses Erlebnis Wirklichkeit wird, müssen die Daten effizient aus dem Netzwerk abgerufen und auf intelligente Weise auf dem Client zwischengespeichert werden." Für die dazu eingesetzte API ist das Unternehmen von der Eigenentwicklung Falcor(öffnet im neuen Fenster) nun auf GraphQL gewechselt(öffnet im neuen Fenster) .
Falcor hatte Netflix erstmals öffentlich im Sommer 2015 vorgestellt und als Open Source veröffentlicht. GraphQL stammt ursprünglich von Facebook und wurde ebenfalls im Jahr 2015 erstmals öffentlich vorgestellt(öffnet im neuen Fenster) . Inzwischen wird GraphQL von einem formal unabhängigen Konsortium und einer Community weiterentwickelt.
Die breite Industrieunterstützung nennt Netflix allerdings nicht explizit als Grund für den Wechsel der API. Vielmehr heißt es, dass mithilfe von GraphQL die Arbeit an den APIs auf unterschiedliche Domain-Teams verteilt werden könne, die bestimmte Teile der API jeweils unabhängig voneinander pflegen können.
Zu dem API-Wechsel selbst schreibt Netflix: "Dies für Hunderte von Millionen von Kunden sicher und ohne Unterbrechungen zu bewerkstelligen, ist eine außerordentliche Herausforderung, insbesondere wenn man die vielen Dimensionen des Wandels bedenkt." In dem Blog-Post dazu beschreibt das Team sein Vorgehen. Die Beteiligten sahen vor allem eine schrittweise Umsetzung sowie sehr viele Testphasen vor.
Ausführliche Teststrategie
Zunächst erstellte das Team dafür eine GraphQL-Zwischenschicht, die noch die alten Falcor-API im Hintergrund nutzte. Die Client-Implementierung konnte so schnell auf GraphQL umgestellt werden, wobei diese Umsetzung wiederum schrittweise per AB-Testing verteilt wurde. Die API-Implementierung wurde dann aufgeteilt und die Bestandteile wiederum einzeln ausgetauscht.
Für den gesamten Umbau verfolgte das Team dabei zwei grundlegenden Strategien: Für Abfragen, die bei den gleichen Eingabedaten immer die gleichen Ergebnisse liefern sollten, wurden Replay-Tests eingesetzt. Wo dies nicht möglich war, wurden AB-Tests sowie sogenannte Sticky Canarys(öffnet im neuen Fenster) genutzt. Letzteres "ist ein Infrastrukturexperiment, bei dem Kunden für die gesamte Dauer eines Experiments entweder einem Canary- oder einem Baseline-Host zugewiesen werden."
Dabei werden zunächst nur wenige Nutzer für einige Stunden dem Canary zugewiesen und der Umfang des Experiments wird dann immer weiter vergrößert. Überprüft hat das Team dabei Metriken wie Fehlerraten, Latenzen, CPU- und Netzwerk-Auslastung oder auch das Streaming selbst.
Das Team von Netflix schließt aus den gesammelten Erfahrungen, dass Migrationen unvermeidlich seien, die wichtigste Frage dabei aber der sichere Übergang sei. Und das habe das Team durch Teststrategien erfolgreich umsetzen können. Zu einem Ausfall des Dienstes sei es dabei nie gekommen.