Progettazione di un servizio di streaming audio

Il design del sistema di un’app di streaming audio è unico nel modo in cui affronta le esigenze aziendali idiosincratiche. Tipicamente, lo streaming audio richiede un grande volume di dati da trasferire all’interno della limitata larghezza di banda del canale di comunicazione di rete.

Un servizio di streaming audio di successo deve gestire milioni di utenti attivi e migliaia di fornitori di contenuti provenienti da varie località geografiche. Dispositivi e piattaforme diverse (smartphone, desktop, altoparlante intelligente) possono supportare diversi formati audio come MP3, FLAC, ALAC, e così via.

In questo post del blog, esploreremo le complessità del design di un sistema così complesso, coprendo i requisiti funzionali e non funzionali.

Requisiti Funzionali

I requisiti funzionali copriranno le caratteristiche richieste per i creatori di contenuti e gli utenti o ascoltatori audio.

• Gestione dei contenuti. Il creatore di contenuti può caricare, eliminare o aggiornare audio in qualsiasi formato. Ogni audio dovrebbe avere metadati come titolo, autore, descrizione, categoria e tag di metadati.
• Notifiche. Il creatore di contenuti riceve notifiche sul successo o il fallimento dell’audio caricato. L’ascoltatore o l’utente audio riceve notifiche sul caricamento riuscito dell’audio.
• Streaming senza interruzioni. Gli utenti possono riprodurre, mettere in pausa, riavvolgere e scaricare audio nel formato di loro scelta.
• Iscriviti. Gli utenti devono poter iscriversi all’audio di loro scelta per ricevere notifiche su nuovi o aggiornati contenuti.
• Accesso utente. Gli autori dei contenuti devono essere autenticati e autorizzati ad accedere al sistema. Gli utenti possono registrarsi nel sistema per configurare i loro profili.
• Ricerca. Gli utenti devono poter cercare audio in base a determinati attributi o metadati.

Nota: I servizi di streaming live e di pagamento sono al di fuori dello scopo di questo articolo.

Diagramma di sequenza del caso d’uso funzionale

Design architetturale

Definiamo i componenti di servizio per supportare i requisiti funzionali.

Il primo requisito funzionale è caricare audio utilizzando qualsiasi formato come MP3, FLAC, ALAC, ecc. Questi file audio possono contenere una notevole quantità di dati. Il codec audio svolge un ruolo cruciale nello stoccaggio, trasmissione e riproduzione efficiente di questi dati. Esistono principalmente due tipi di codec:

1. Codec senza perdita – comprime l’audio senza perdere dati e può essere completamente ripristinato senza perdita di qualità.
2. Codec con perdita – rimuove alcuni dati che aiutano a ridurre significativamente le dimensioni. Ciò potrebbe compromettere la qualità del suono.

Il fornitore di contenuti lavora tipicamente con formati senza perdita per la registrazione e il montaggio. Questo garantisce nessuna perdita di qualità mentre operano sull’audio, applicano effetti e realizzano il prodotto finale. In termini semplici, il mastering audio è l’ultima fase del processo di produzione audio.

Una volta che l’audio finale è stato masterizzato, viene convertito in un formato con perdita per la distribuzione generale. Con un formato lossy, la dimensione viene ridotta in modo significativo, rendendo più facile e veloce lo streaming e il download.

L’audio compresso deve essere trasmesso al dispositivo dell’ascoltatore con la larghezza di banda di rete supportata. La larghezza di banda potrebbe variare dinamicamente, con il carico di rete che cambia in base al numero di utenti connessi o all’utente che si sposta da una zona di rete a un’altra mentre ascolta l’audio.

Per supportare questa larghezza di banda di rete variabile, il codec potrebbe utilizzare il meccanismo di “bit rate adattivo”. Lo streaming a bit rate adattivo rileva la larghezza di banda degli utenti in tempo reale, regolando lo stream di conseguenza. Può passare dinamicamente il bit rate dello streaming in base alla larghezza di banda attuale dell’utente. Questo porta a poca buffering, tempi di avvio più rapidi e una buona esperienza sia per connessioni di alta gamma che di bassa gamma.

L’encoder codifica la singola fonte del file audio a più bit rate. Questi stream di byte vengono impacchettati e memorizzati nell’oggetto di archiviazione per essere disponibili per l’ascoltatore. Una volta che l’audio è stato caricato con successo, il servizio di notifica invia una notifica al fornitore di contenuti.

 

Il creatore di contenuti fornisce inoltre metadati durante la richiesta di caricamento dell’audio, che possono essere direttamente salvati in un DB NoSQL tramite Audio Data service. Questi dati saranno indicizzati per offrire una migliore capacità di ricerca all’ascoltatore audio.

Il sistema audio necessita di un servizio di autenticazione e autorizzazione per gestire la registrazione di nuovi utenti, il login utilizzando le credenziali dell’utente e l’autorizzazione basata sui ruoli associati agli utenti (ascoltatori e fornitori di contenuti). API Gateway service che può gestire centralmente l’autenticazione e l’autorizzazione. Questo servizio può essere sfruttato per eseguire il routing delle richieste e orchestrare il flusso di processo dal front-end al servizio back-end.

L’utente audio (ascoltatore) potrebbe cercare audio di interesse, che sarà inoltrato al Audio Data service per restituire la posizione degli audio pertinenti, estraendo informazioni dal deposito di metadati audio. L’utente clicca sul link e restituirà i byte audio impacchettati e memorizzati dal Package service.

Il User Profile service gestisce le preferenze degli utenti, i follower e i seguiti.

Il diagramma sopra rappresenta il flusso di processo di base “carica audio” attivato dal fornitore di contenuti e il flusso di processo “ascolta audio” attivato dall’utente/ascoltatore audio.

Il modello di progettazione a pipeline e filtraggio con messaggistica in coda viene utilizzato per supportare il flusso di dati tra i servizi al fine di scalare il processo in modo efficiente con parallelismo e tolleranza ai guasti.

Adesso, passiamo ai requisiti non funzionali.

Requisiti non funzionali

• Scalabilità. Il sistema dovrebbe supportare migliaia di utenti simultanei e essere in grado di espandersi e restringersi.
• Tolleranza ai guasti. Il sistema dovrebbe essere tollerante ai guasti, di solito con dati ridondanti, con un basso downtime.
• Performance. Il sistema dovrebbe avere bassa latenza e alta reattività durante la riproduzione dei contenuti.
• Sicurezza. Il sistema deve essere protetto da accessi non autorizzati o attacchi dannosi come DDoS.

Scalabilità

Il sistema audio dovrebbe essere in grado di supportare migliaia di creatori di contenuti attivi. Per gestire il carico, il design include l’esecuzione di molteplici istanze del servizio API Gateway, del servizio Web dell’app e del servizio dati audio fronteggiati da bilanciatori di carico.

Tuttavia, ciò non sarà scalabile con l’aumento del numero di creatori di contenuti. I file audio sono generalmente di grandi dimensioni, il che comporterà un alto utilizzo di rete e potenza di calcolo durante il passaggio attraverso i vari componenti del servizio. Per ottimizzare l’utilizzo delle risorse di sistema, può essere utilizzato un URL firmato (anche chiamato URL pre-firmato) per fornire accesso limitato nel tempo all’archivio degli oggetti per caricare direttamente i file audio. Questo elimina la necessità di instradare il traffico tramite API Gateway e il servizio Web API. Gli URL firmati possono essere configurati con autorizzazioni granulari e regole di scadenza per una maggiore sicurezza.

Questo copre il requisito di scalabilità per il caricamento dei file audio da parte dei fornitori di contenuti.

Milioni di richieste di ricerca da parte degli ascoltatori di audio potrebbero colpire il sistema, causando un sovraccarico del servizio Audio Data. Per scalare il sistema a supporto di questa massiccia operazione di ricerca, può essere utilizzato il pattern di design Content Query Responsibility Segregation (CQRS). Le operazioni di lettura e scrittura da/a datastore possono essere gestite in modo indipendente, supportando diversi requisiti di latenza, scalabilità e sicurezza.

 

Tolleranza ai guasti

Ci sono varie dimensioni nel design della tolleranza ai guasti. Alcune di esse sono già incluse nel design.

• Uso di più istanze di servizio per scalabilità e tolleranza ai guasti
• Code di messaggi con elaborazione in pipeline per supportare la tolleranza ai guasti a livello di flusso dati
• Separazione del servizio di transcodifica e del servizio di imballaggio
• Multiple istanze di DB con replica
• Zone di disponibilità allineate a regioni geografiche come l’Est degli Stati Uniti, l’Ovest degli Stati Uniti e l’Asia Pacifico per il dispiegamento dell’intero sistema a supporto di una specifica regione e base utenti.

Performance

Una rete di distribuzione dei contenuti (CDN) è una rete distribuita di server raggruppati per fornire contenuti, come file audio e video, più velocemente e in modo più efficiente. Memorizza nella cache i contenuti sul server di edge per fornire migliori prestazioni con bassa latenza.

Sicurezza

I CDN migliorano anche la sicurezza fornendo mitigazione DDoS e alcune altre misure di sicurezza.

Il servizio Package distribuirà i file audio ai CDN per essere memorizzati nella cache dei server periferici. Il servizio Audio Data aggiornerà la posizione del CDN nei suoi metadati che verranno instradati al servizio di Ricerca per l’interrogazione da parte degli utenti.

 

Il diagramma sopra rappresenta l’architettura a livello di componente di un tipico sistema audio.

Conclusion

Al centro di un buon sistema audio ci sono la scalabilità, le prestazioni e la tolleranza ai guasti per fornire un’esperienza utente di qualità con distorsione minima, bassa latenza e affidabilità.