Plusy i minusy przejścia Prime Video na architekturę monolityczną: czy warto ryzykować?

Cięcie kosztów czy rezygnacja z elastyczności?

Amazon Prime Video niedawno zmienił swoją usługę monitorowania wideo na żywo z mikrousługi na monolit, co przyniosło 90% redukcję kosztów.

Przyjrzyjmy się dokładnie architekturze i spróbujmy zrozumieć motywy stojące za przejściem wykraczającym poza zwykłe oszczędności kosztów i ustalmy, czy jest to naprawdę architektura mikrousług, czy makrousług.

Powszechnie stosowana terminologia:

VMS (usługa monitoringu wideo) : to narzędzie pozwala firmie Amazon automatycznie identyfikować problemy z jakością percepcyjną (na przykład uszkodzenie bloku lub problemy z synchronizacją audio/wideo) i uruchamiać proces ich naprawy

MCS (usługa konwertera mediów) : Konwertuje wejściowe strumienie audio/wideo na ramki lub odszyfrowane bufory audio, które są wysyłane do detektorów

Wykrywacze defektów : wykonują algorytmy, które analizują ramki i bufory audio w czasie rzeczywistym, szukając defektów (takich jak zamrożenie obrazu, uszkodzenie bloku lub problemy z synchronizacją audio/wideo) i wysyłają powiadomienia w czasie rzeczywistym, gdy wykryty zostanie defekt

Początkowa rozproszona architektura bezserwerowa

Powyższy diagram przedstawia początkową bezserwerową architekturę usługi monitoringu wideo na żywo zbudowaną z wykorzystaniem funkcji krokowych AWS z AWS Lambda pełniącą rolę orkiestratora.

Podzielmy to krok po kroku dla lepszego zrozumienia. (do wiadomości: niektóre hipotezy są rozważane z powodu braku informacji/jasności podanych w oryginalnym artykule)

• Pierwszy krok polega na przesłaniu przez aplikację kliencką strumienia audio lub wideo do usługi konwersji multimediów i uruchomieniu funkcji kroku w celu synchronicznego rozpoczęcia konwersji.
• Aby to osiągnąć, po stronie konsumenta musi działać narzędzie do dekodowania przychodzących zaszyfrowanych strumieni audio/wideo (założenie, ponieważ nie jest to wspomniane na blogu) przed wysłaniem ich do usługi konwersji multimediów.

• Po zakończeniu konwersji MCS przechowuje strumienie audio/wideo w zasobniku s3 i uruchamia połączenie z usługą wykrywania defektów, która działa równolegle, a zagregowane wyniki są ponownie zapisywane w zasobniku S3, a także przesyłane w temacie SNS, aby konsumenci mogli podjąć odpowiednie działania.
• Cały system jest zbudowany w oparciu o architekturę bezserwerową (AWS Step Functions i Lambda) oraz architekturę mikroserwisową (MCS i detektory defektów), gdzie główny koszt wynika z orkiestracji przepływu pracy i transferu danych pomiędzy rozproszonymi komponentami. Nie wspominając o tym, że obecny projekt wiąże się ze skalowaniem wąskich gardeł dla gorących transmisji na żywo

Architektura monolitu

W zaktualizowanej architekturze większość komponentów pozostaje taka sama (MCS, Detectors, Orchestrator), jedyną istotną zmianą jest skonsolidowanie komponentów w jedną instancję ECS. Ale co to oznacza i jaki ma to wpływ na system? Rozbijmy to.

• Orkiestracja, która wcześniej była kosztowna i wykorzystywała funkcje krokowe AWS oraz Lambdę, została zastąpiona nową warstwą orkiestracyjną. Pozwala to na lepszą kontrolę komponentów w ramach jednej instancji, co skutkuje znacznymi oszczędnościami kosztów.
• Konwerter mediów (MCS) działał wcześniej jako mikrousługa, ale został teraz przeniesiony do pojedynczej instancji ECS. Ta zmiana umożliwia konwersję i przechowywanie danych lokalnie w aktywnym stosie, co skutkuje szybszym przetwarzaniem i lepszą wydajnością.
• Wreszcie detektor, który wykorzystuje modele ML do wykrywania defektów w strumieniach audio/wideo, również został przeniesiony do pojedynczej instancji ECS. Chociaż oznacza to utratę możliwości skalowalności poziomej, oszczędności kosztów sprawiają, że jest to opłacalny kompromis. Warto jednak zauważyć, że detektor może się zepsuć pod dużym obciążeniem, więc nadal istnieje kilka potencjalnych wyzwań do pokonania

• Zalety: redukcja kosztów, ponieważ dodatkowe wywołania poziomu 1 odczytu i zapisu wiadra S3 nie są już wymagane, a funkcje AWS Step i kosztowna operacja Lambda dla orkiestracji zostały zastąpione indywidualnym komponentem.
• Wady: Utrata skalowalności poziomej (np. Detektory działające również w pojedynczej instancji ECS). Utrata elastyczności, ponieważ w przyszłości może być wielu odbiorców strumieni audio/wideo, które obecnie są ściśle powiązane z detektorem.

Poprzednia architektura monolityczna miała poważny problem z utratą skalowalności poziomej, szczególnie w przypadku detektorów, w ramach pojedynczej instancji ECS. Ale nowy projekt makro + monolitu rozwiązał ten problem. Zanurzmy się głębiej, aby zobaczyć, jak to zrobić.

• Detektory można skalować w pionie tylko w pojedynczej instancji ECS, aby przezwyciężyć tę instancję usługi monolitu, która zostanie zduplikowana ze sparametryzowanym podzbiorem detektorów w różnych klastrach ECS i lekką warstwą orkiestratora wykorzystującą lambda AWS do dystrybucji żądań.
• W powyższym projekcie nadal tracimy trochę elastyczności. Obecnie istnieje tylko jeden odbiorca strumienia audio/wideo detektor, co w przyszłości nadejdzie wielu odbiorców, co może wymagać zmiany podejścia projektowego.

W świecie tworzenia oprogramowania nie ma jednego uniwersalnego rozwiązania ani przewagi projektowej między mikrousługami a architekturą monolityczną. W przypadku przejścia Prime Video na projekt monolityczny spowodowało to znaczną redukcję kosztów, sięgającą nawet 90%, i dobrze współgrało z ich przypadkiem użycia.

Należy jednak pamiętać, że jeśli pojawi się wielu odbiorców strumieni audio/wideo lub sama usługa MCS nie może być przechowywana w pojedynczej instancji ECS ze względu na rozmiar bufora, może być konieczna ponowna ocena obecnego projektu. Jako inżynierowie oprogramowania ważne jest, aby stale oceniać i dostosowywać nasze projekty, aby spełniały zmieniające się wymagania oraz optymalizować koszty i wydajność.

Bibliografia

• Amazon prime video blog ( Zwiększanie skali usługi monitorowania audio/wideo Prime Video i redukcja kosztów o 90% — Prime Video Tech )

• Computing Widzowie transmisji na żywo liczą się w czasie rzeczywistym na dużą skalę !! | autorstwa Aashirwada Kashyapa | Rzut oka ()
• Wdróż aplikację Node.js przez Google Cloud z CI/CD | autorstwa Aashirwada Kashyapa | Bity i kawałki ()
• Budowanie odpornych potoków danych z głębokim zanurzeniem w architekturze AirFlow | autorstwa Aashirwada Kashyapa | Kultura maniaków | Średni

Dziękujemy za bycie częścią naszej społeczności! Zanim pójdziesz:

• Klaskajcie za relację i śledźcie autora
• Zobacz więcej treści w publikacji Level Up Coding
• Bezpłatny kurs rozmowy o kodowaniu ⇒ Zobacz kurs
• Śledź nas: Twitter | LinkedIn | Biuletyn