I pro ei contro del passaggio di Prime Video all'architettura monolitica: vale la pena rischiare?

Tagliare i costi o sacrificare la flessibilità?

Amazon Prime Video ha recentemente spostato il suo servizio di monitoraggio video in diretta da un microservizio a un monolite, con una riduzione dei costi del 90%.

Facciamo un tuffo nell'architettura e proviamo a capire le motivazioni alla base del passaggio oltre il semplice risparmio sui costi e determiniamo se si tratta davvero di un'architettura di microservizi o macroservizi.

Terminologia comunemente usata:

VMS (servizio di monitoraggio video) : questo strumento consente ad Amazon di identificare automaticamente i problemi di qualità percettiva (ad esempio, danneggiamento dei blocchi o problemi di sincronizzazione audio/video) e attivare un processo per risolverli

MCS (servizio di conversione multimediale) : converte i flussi audio/video in ingresso in frame o buffer audio decrittografati che vengono inviati ai rilevatori

Rilevatori di difetti : esegue algoritmi che analizzano frame e buffer audio in tempo reale alla ricerca di difetti (come blocco video, danneggiamento di blocchi o problemi di sincronizzazione audio/video) e invia notifiche in tempo reale ogni volta che viene rilevato un difetto

Architettura distribuita iniziale senza server

Il diagramma sopra è l'architettura iniziale senza server per il servizio di monitoraggio video in diretta creato utilizzando le funzioni step di AWS con AWS Lambda che svolge il ruolo di orchestratore.

Analizziamolo passo dopo passo per una migliore comprensione. (a proposito: alcune ipotesi sono prese in considerazione per mancanza di informazioni/chiarezza fornite nell'articolo originale)

• Il primo passaggio prevede che l'applicazione client carichi un flusso audio o video in un servizio di conversione multimediale e attivi una funzione di passaggio per avviare la conversione in modo sincrono.
• Per raggiungere questo obiettivo, sul lato consumer deve essere in esecuzione uno strumento per decodificare i flussi audio/video crittografati in entrata (presupposto poiché non è menzionato nel blog) prima di inviarli al servizio di conversione multimediale.

• Una volta completata la conversione, MCS memorizza i flussi audio/video nel bucket s3 e attiva una chiamata al servizio di rilevamento dei difetti che viene eseguito in parallelo e i risultati aggregati vengono archiviati nuovamente nel bucket S3 e inseriti anche nell'argomento SNS affinché i consumatori mirati agiscano di conseguenza.
• L'intero sistema è realizzato utilizzando un'architettura senza server (AWS Step Functions e Lambda) e un'architettura a microservizi (MCS e rilevatori di difetti), in cui il costo principale deriva dal flusso di lavoro di orchestrazione e dal trasferimento dei dati tra i componenti distribuiti. Per non parlare del fatto che ci sono colli di bottiglia di ridimensionamento associati per i flussi live caldi con il design attuale

Architettura monolitica

Nell'architettura aggiornata, la maggior parte dei componenti rimane la stessa (MCS, Detectors, Orchestrator), l'unico cambiamento significativo è che i componenti sono stati consolidati in un'unica istanza ECS. Ma cosa significa questo e come influisce sul sistema? Analizziamolo.

• L'orchestrazione, che in precedenza era costosa e utilizzava le funzioni step di AWS e Lambda, è stata sostituita con un nuovo livello di orchestrazione. Ciò consente un migliore controllo dei componenti all'interno di una singola istanza, con conseguenti risparmi significativi sui costi.
• Il media converter (MCS) era in precedenza eseguito come microservizio, ma ora è stato spostato in una singola istanza ECS. Questa modifica consente la conversione e l'archiviazione dei dati in locale in un heap attivo, con conseguente elaborazione più rapida e prestazioni migliori.
• Infine, anche il rilevatore, che utilizza modelli ML per rilevare i difetti nei flussi audio/video, è stato spostato in una singola istanza ECS. Anche se questo significa perdere la capacità di scalabilità orizzontale, i risparmi sui costi lo rendono un compromesso utile. Tuttavia, vale la pena notare che il rilevatore potrebbe rompersi sotto carico elevato, quindi ci sono ancora alcune potenziali sfide da superare

• Pro: la riduzione dei costi in quanto non sono più necessarie chiamate extra di livello 1 in lettura e scrittura del bucket S3, così come le funzioni AWS Step e le costose operazioni di Lambda per le orchestrazioni sono state sostituite con un singolo componente.
• Contro: Perdita di scalabilità orizzontale (ad esempio, i rilevatori funzionano anche in una singola istanza ECS). Perdita di flessibilità poiché in futuro potrebbero esserci più consumatori per i flussi audio/video che attualmente sono strettamente accoppiati a un rilevatore.

La precedente architettura monolitica presentava un grave problema di perdita di scalabilità orizzontale, in particolare per i rilevatori, all'interno di una singola istanza ECS. Ma il nuovo design macro + monolite ha affrontato questo problema. Approfondiamo per vedere come.

• I rilevatori possono essere ridimensionati solo verticalmente in una singola istanza ECS per superare questo monolite l'istanza del servizio verrà duplicata con un sottoinsieme parametrizzato di rilevatori in diversi cluster ECS e un livello di orchestrazione leggero che utilizza AWS lambda per la distribuzione delle richieste.
• Nel progetto di cui sopra stiamo ancora perdendo un po' di flessibilità. Attualmente c'è solo un consumatore di flusso audio/video il rivelatore che in futuro arriva più consumatori che potrebbero richiedere un cambiamento nell'approccio progettuale.

Nel mondo dello sviluppo software, non esiste una soluzione valida per tutti o una supremazia progettuale tra microservizi e architettura monolitica. Nel caso del passaggio di Prime Video a un design monolitico, ha comportato una significativa riduzione dei costi fino al 90% e si è adattato bene al loro caso d'uso.

Tuttavia, è importante notare che se si verificano più consumer per flussi audio/video o se il servizio MCS stesso non può essere mantenuto all'interno di una singola istanza ECS a causa delle dimensioni del buffer, potrebbe essere necessario rivalutare la progettazione corrente. In qualità di ingegneri del software, è importante valutare e adattare continuamente i nostri progetti per soddisfare i requisiti in continua evoluzione e ottimizzare i costi e le prestazioni.

Riferimenti

• Amazon Prime Video Blog ( Aumentare il servizio di monitoraggio audio/video di Prime Video e ridurre i costi del 90% — Prime Video Tech )

• Computing Gli spettatori del live streaming contano in tempo reale su scala elevata !! | di Aashirwad Kashyap | Sguardo ()
• Distribuisci l'applicazione Node.js su Google Cloud con CI/CD | di Aashirwad Kashyap | Bit e pezzi ()
• Creazione di pipeline di dati resilienti con un'analisi approfondita dell'architettura AirFlow | di Aashirwad Kashyap | Cultura geek | medio

Grazie per far parte della nostra comunità! Prima che tu vada:

• Batti le mani per la storia e segui l'autore
• Visualizza altri contenuti nella pubblicazione Level Up Coding
• Corso di colloquio di codifica gratuito ⇒ Visualizza il corso
• Seguici: Twitter | Linkedin | Notiziario