Bei Prime Video bieten wir unseren Kunden Tausende von Livestreams. Um sicherzustellen, dass Kunden Inhalte reibungslos erhalten, hat Prime Video ein Tool eingerichtet, um jeden von Kunden angesehenen Stream zu überwachen. Mit diesem Tool können wir Probleme mit der Wahrnehmungsqualität automatisch identifizieren (z. B. Blockbeschädigung oder Audio-/Video-Synchronisierungsprobleme) und einen Prozess zur Behebung dieser Probleme auslösen.
Unser Team für Videoqualitätsanalyse (VQA) bei Prime Video verfügte bereits über ein Tool zur Audio-/Videoqualitätsprüfung, aber wir hatten weder die Absicht noch die Entwicklung, dass es in großem Maßstab ausgeführt werden sollte (unser Ziel war es, Tausende von gleichzeitigen Streams zu überwachen und diese Zahl im Laufe der Zeit zu erhöhen). ). Beim Einbinden weiterer Streams in den Dienst stellten wir fest, dass der Betrieb der Infrastruktur in großem Umfang sehr kostspielig war. Außerdem sind uns Skalierungsengpässe aufgefallen, die uns daran hinderten, Tausende von Streams zu überwachen. Deshalb gingen wir einen Schritt zurück und überprüften die Architektur des bestehenden Dienstes, wobei wir uns auf die Kosten und Skalierungsengpässe konzentrierten.
Die ursprüngliche Version unseres Dienstes bestand aus verteilten Komponenten, die von orchestriert wurden AWS-Schrittfunktionen. Die beiden kostenintensivsten Vorgänge waren der Orchestrierungsworkflow und die Datenübertragung zwischen verteilten Komponenten. Um dieses Problem zu lösen, haben wir alle Komponenten in einen einzigen Prozess verschoben, um die Datenübertragung im Prozessspeicher zu halten, was auch die Orchestrierungslogik vereinfacht. Da wir alle Vorgänge in einem einzigen Prozess zusammengefasst haben, konnten wir uns auf Skalierbarkeit verlassen Amazon Elastic Compute Cloud (Amazon EC2) Und Amazon Elastic Container Service (Amazon ECS) Instanzen für die Bereitstellung.
Overhead verteilter Systeme
Unser Service besteht aus drei Hauptkomponenten. Der Medienkonverter wandelt eingegebene Audio-/Videoströme in Frames oder entschlüsselte Audiopuffer um, die an Detektoren gesendet werden. Fehlerdetektoren führen Algorithmen aus, die Frames und Audiopuffer in Echtzeit analysieren und nach Fehlern suchen (z. B. eingefrorenes Video, Blockbeschädigung oder Audio-/Video-Synchronisierungsprobleme) und Echtzeitbenachrichtigungen senden, wenn ein Fehler gefunden wird. Weitere Informationen zu diesem Thema finden Sie in unserem Wie Prime Video maschinelles Lernen nutzt, um die Videoqualität sicherzustellen Artikel. Die dritte Komponente stellt eine Orchestrierung bereit, die den Fluss im Dienst steuert.
Wir haben unsere ursprüngliche Lösung als verteiltes System mit serverlosen Komponenten konzipiert (z. B. AWS Step Functions oder AWS Lambda), was eine gute Wahl für den schnellen Aufbau des Dienstes war. Theoretisch würde uns dies ermöglichen, jede Servicekomponente unabhängig zu skalieren. Die Art und Weise, wie wir einige Komponenten verwendet haben, führte jedoch dazu, dass wir bei etwa 5 % der erwarteten Last an eine harte Skalierungsgrenze stießen. Außerdem waren die Gesamtkosten aller Bausteine zu hoch, um die Lösung im großen Maßstab zu akzeptieren.
Das folgende Diagramm zeigt die serverlose Architektur unseres Dienstes.
Die ursprüngliche Architektur unseres Fehlererkennungssystems.
Der größte Skalierungsengpass in der Architektur war das Orchestrierungsmanagement, das mithilfe von AWS Step Functions implementiert wurde. Unser Dienst führte für jede Sekunde des Streams mehrere Statusübergänge durch, sodass wir schnell die Kontogrenzen erreichten. Darüber hinaus berechnet AWS Step Functions den Benutzern Gebühren pro Statusübergang.
Das zweite Kostenproblem, das wir entdeckten, betraf die Art und Weise, wie wir Videoframes (Bilder) durch verschiedene Komponenten leiten. Um rechenintensive Videokonvertierungsaufgaben zu reduzieren, haben wir einen Microservice entwickelt, der Videos in Frames aufteilt und Bilder vorübergehend in einen hochlädt Amazon Simple Storage Service (Amazon S3) Eimer. Fehlerdetektoren (wobei jeder von ihnen auch als separater Microservice ausgeführt wird) laden dann Bilder herunter und verarbeiten sie gleichzeitig mit AWS Lambda. Allerdings war die hohe Anzahl an Tier-1-Aufrufen an den S3-Bucket teuer.
Von verteilten Microservices bis hin zu einer monolithischen Anwendung
Um die Engpässe zu beheben, haben wir zunächst darüber nachgedacht, Probleme separat zu beheben, um die Kosten zu senken und die Skalierbarkeit zu erhöhen. Wir haben experimentiert und eine mutige Entscheidung getroffen: Wir haben beschlossen, unsere Infrastruktur neu zu gestalten.
Wir erkannten, dass der verteilte Ansatz in unserem spezifischen Anwendungsfall nicht viele Vorteile brachte, und packten daher alle Komponenten in einen einzigen Prozess. Dadurch entfiel die Notwendigkeit des S3-Buckets als Zwischenspeicher für Videobilder, da unsere Datenübertragung nun im Speicher stattfand. Wir haben auch eine Orchestrierung implementiert, die Komponenten innerhalb einer einzelnen Instanz steuert.
Das folgende Diagramm zeigt die Architektur des Systems nach der Migration auf den Monolithen.
Die aktualisierte Architektur zur Überwachung eines Systems, bei dem alle Komponenten in einer einzigen Amazon ECS-Aufgabe ausgeführt werden.
Konzeptionell blieb die High-Level-Architektur gleich. Wir haben immer noch genau die gleichen Komponenten wie im ursprünglichen Design (Medienkonvertierung, Detektoren oder Orchestrierung). Dadurch konnten wir viel Code wiederverwenden und schnell auf eine neue Architektur migrieren.
Im ursprünglichen Entwurf konnten wir mehrere Detektoren horizontal skalieren, da jeder von ihnen als separater Mikrodienst ausgeführt wurde (das Hinzufügen eines neuen Detektors erforderte also die Erstellung eines neuen Mikrodienstes und dessen Einbindung in die Orchestrierung). Bei unserem neuen Ansatz skaliert die Anzahl der Detektoren jedoch nur vertikal, da sie alle in derselben Instanz ausgeführt werden. Unser Team fügt dem Service regelmäßig weitere Detektoren hinzu und wir haben bereits die Kapazität einer einzelnen Instanz überschritten. Um dieses Problem zu lösen, haben wir den Dienst mehrmals geklont und jede Kopie mit einer anderen Teilmenge von Detektoren parametrisiert. Wir haben außerdem eine einfache Orchestrierungsschicht implementiert, um Kundenanfragen zu verteilen.
Das folgende Diagramm zeigt unsere Lösung für den Einsatz von Detektoren, wenn die Kapazität einer einzelnen Instanz überschritten wird.
Unser Ansatz für die Bereitstellung weiterer Detektoren für den Dienst.
Ergebnisse und Erkenntnisse
Microservices und serverlose Komponenten sind Tools, die zwar in großem Maßstab funktionieren, aber ob man sie anstelle von Monolithen verwendet, muss von Fall zu Fall entschieden werden.
Durch die Verlagerung unseres Dienstes auf einen Monolithen konnten unsere Infrastrukturkosten um über 90 % gesenkt werden. Es hat auch unsere Skalierungsmöglichkeiten verbessert. Heute sind wir in der Lage, Tausende von Streams zu verarbeiten und haben immer noch die Kapazität, den Service noch weiter zu skalieren. Durch die Umstellung der Lösung auf Amazon EC2 und Amazon ECS konnten wir auch das nutzen Amazon EC2-Rechensparpläne Das wird dazu beitragen, die Kosten noch weiter zu senken.
Einige Entscheidungen, die wir getroffen haben, sind nicht offensichtlich, aber sie haben zu erheblichen Verbesserungen geführt. Beispielsweise haben wir einen rechenintensiven Medienkonvertierungsprozess nachgebildet und ihn näher an den Detektoren platziert. Während die einmalige Durchführung der Medienkonvertierung und die Zwischenspeicherung des Ergebnisses möglicherweise als günstigere Option angesehen werden, haben wir festgestellt, dass dies kein kosteneffektiver Ansatz ist.
Die von uns vorgenommenen Änderungen ermöglichen es Prime Video, alle von unseren Kunden angesehenen Streams zu überwachen und nicht nur die mit der höchsten Zuschauerzahl. Dieser Ansatz führt zu einer noch höheren Qualität und einem noch besseren Kundenerlebnis.
