Projeto de Sistema de um Serviço de Streaming de Áudio

O design do sistema de um aplicativo de streaming de áudio é único em como lida com necessidades de negócios idiossincráticas. Normalmente, o streaming de áudio requer uma grande quantidade de dados a serem transferidos dentro da largura de banda limitada do canal de comunicação da rede.

Um serviço de streaming de áudio bem-sucedido deve lidar com milhões de usuários ativos e milhares de provedores de conteúdo de várias localidades geográficas. Diferentes dispositivos e plataformas (smartphone, desktop, alto-falante inteligente) podem suportar diferentes formatos de áudio como MP3, FLAC, ALAC, e assim por diante.

Neste post do blog, exploraremos as nuances do design de um sistema tão complexo, cobrindo requisitos funcionais e não funcionais.

Requisitos Funcionais

Os requisitos funcionais cobrirão as funcionalidades necessárias para os criadores de conteúdo e os usuários ou ouvintes de áudio.

• Gerenciamento de conteúdo. O criador de conteúdo pode enviar, excluir ou atualizar áudio em qualquer formato. Cada áudio deve ter metadados como título, autor, descrição, categoria e tags de metadados.
• Notificação. O criador de conteúdo recebe notificações sobre o sucesso ou a falha do áudio enviado. O ouvinte ou usuário de áudio recebe notificações sobre o upload bem-sucedido do áudio.
• Streaming sem interrupções. Os usuários podem reproduzir, pausar, retroceder e baixar áudio no formato de sua escolha.
• Inscrever-se. Os usuários devem poder se inscrever no áudio de sua escolha para receber notificações sobre conteúdo novo ou atualizado.
• Login do usuário. Os criadores de conteúdo devem ser autenticados e autorizados a acessar o sistema. Os usuários podem se registrar no sistema para configurar seus perfis.
• Buscar. Os usuários devem poder buscar áudio com base em determinados atributos ou metadados.

Nota: Serviços de transmissão ao vivo e pagamento estão fora do escopo deste artigo.

Diagrama de Sequência do Caso de Uso Funcional

Design Arquitetônico

Vamos definir componentes de serviço para dar suporte aos requisitos funcionais.

O primeiro requisito funcional é enviar áudio usando qualquer formato como MP3, FLAC, ALAC, etc. Esses arquivos de áudio podem conter uma quantidade impressionante de dados. O codec de áudio desempenha um papel crucial no armazenamento, transmissão e reprodução eficientes desses dados. Existem principalmente dois tipos de codecs:

1. Codec sem perdas – comprime áudio sem perder dados e pode ser totalmente restaurado sem perder qualidade.
2. Codec com perdas – remove alguns dados, o que ajuda a reduzir significativamente o tamanho. Isso poderia comprometer a qualidade do som.

O provedor de conteúdo normalmente trabalha com formatos sem perdas para gravação e edição. Isso garante que não haja perda de qualidade enquanto eles operam o áudio, aplicam efeitos e finalizam o produto. Em termos simples, a masterização de áudio é a etapa final no processo de produção de áudio.

Uma vez que o áudio final foi masterizado, ele é convertido para um formato com perdas para distribuição geral. Com um formato com perdas, o tamanho é reduzido em maior extensão, tornando mais fácil e rápido o streaming e o download.

O áudio comprimido precisa ser transmitido para o dispositivo do ouvinte com a largura de banda da rede suportada. A largura de banda pode variar dinamicamente, com a carga da rede mudando com base no número de usuários conectados ou no usuário se movendo de uma zona de rede para outra enquanto escuta o áudio.

Para suportar essa largura de banda de rede variável, o codec pode usar o mecanismo de “taxa de bits adaptativa”. O streaming de taxa de bits adaptativa detecta a largura de banda dos usuários em tempo real, ajustando o stream de acordo. Ele pode trocar dinamicamente a taxa de bits do streaming com base na largura de banda atual do usuário. Isso resulta em pouco buffer, tempos de início mais rápidos e uma boa experiência tanto para conexões de alta quanto de baixa qualidade.

O codificador codifica a única fonte do arquivo de áudio em múltiplas taxas de bits. Esses fluxos de bytes são empacotados e armazenados no armazenamento de objetos para estarem disponíveis ao ouvinte. Uma vez que o áudio é carregado com sucesso, o serviço de Notificações envia uma notificação ao provedor de conteúdo.

 

O criador de conteúdo também fornece metadados ao solicitar o upload do áudio, que podem ser salvos diretamente em um banco de dados NoSQL via serviço de Dados de Áudio. Esses dados serão indexados para oferecer uma melhor capacidade de busca para o ouvinte de áudio.

O sistema de áudio necessita de um serviço de autenticação e autorização para gerenciar o registro de novos usuários, login usando as credenciais do usuário e autorização com base em funções associadas aos usuários (ouvintes e provedores de conteúdo). serviço de API Gateway que pode gerenciar centralmente a autenticação e autorização. Este serviço pode ser aproveitado para realizar o roteamento de solicitações e orquestrar o fluxo de processos do front-end para o serviço de back-end.

O usuário de áudio (ouvinte) pode buscar áudios de interesse, que serão encaminhados para o serviço de Dados de Áudio para retornar a localização dos áudios relevantes, puxando informações do armazenamento de metadados de áudio. O usuário clica no link, e ele retornará os bytes de áudio empacotados e armazenados pelo serviço de Pacote.

O serviço de Perfil de Usuário gerencia preferências dos usuários, seguidores e seguidos.

O diagrama acima retrata o fluxo básico do processo “upload de áudio” acionado pelo provedor de conteúdo e o fluxo do processo “ouvir áudio” acionado pelo usuário/ouvinte de áudio.

O padrão de design de pipeline e filtragem com enfileiramento de mensagens está sendo utilizado para suportar o fluxo de dados entre os serviços para escalar o processo de forma eficiente com paralelismo e tolerância a falhas.

Agora, vamos passar para os requisitos não funcionais.

Requisitos Não Funcionais

• Escala. O sistema deve suportar milhares de usuários simultâneos e ser capaz de crescer e diminuir.
• Tolerância a falhas. O sistema deve ser tolerante a falhas, geralmente com dados redundantes, com baixo tempo de inatividade.
• Desempenho. O sistema deve ter baixa latência e alta responsividade durante a reprodução de conteúdo.
• Segurança. O sistema deve estar protegido contra acesso não autorizado ou ataques prejudiciais, como DDoS.

Escala

O sistema de áudio deve ser capaz de suportar milhares de criadores de conteúdo ativos. Para gerenciar a carga, o design inclui a execução de várias instâncias do serviço de API Gateway, serviço da Web do aplicativo e serviço de Dados de Áudio, com balanceadores de carga.

No entanto, isso não será escalável com o aumento do número de criadores de conteúdo. Os arquivos de áudio são geralmente grandes, o que usará alta rede e poder de computação ao passar por vários componentes de serviço. Para otimizar o uso de recursos do sistema, um URL assinado (também conhecido como URL pré-assinada) pode ser usado para fornecer acesso limitado no tempo ao armazenamento de objetos para fazer upload de arquivos de áudio diretamente. Isso elimina a necessidade de rotear o tráfego via API Gateway e serviço da Web da API. Os URLs assinados podem ser configurados com permissões granulares e regras de expiração para uma melhor segurança.

Isso cobre o requisito de escalabilidade para o upload de arquivos de áudio pelos provedores de conteúdo.

Milhões de solicitações de busca dos ouvintes de áudio podem sobrecarregar o sistema, fazendo com que o serviço de Dados de Áudio fique sobrecarregado. Para escalar o sistema que suporta essa operação de busca massiva, pode-se usar o padrão de design de Separação de Responsabilidade de Consulta de Conteúdo (CQRS). As operações de leitura e gravação do/para o armazenamento de dados podem ser gerenciadas de forma independente, apoiando diferentes requisitos de latência, escalabilidade e segurança.

 

Tolerância a Falhas

Existem várias dimensões no design de tolerância a falhas. Algumas delas já estão incluídas no design.

• Uso de múltiplas instâncias de serviço para escalabilidade e tolerância a falhas
• Filas de mensagens com processamento em pipeline para suportar a tolerância a falhas no nível de fluxo de dados
• Separação do serviço de transcodificação e do serviço de empacotamento
• Múltiplas instâncias de banco de dados com réplicas
• Zonas de Disponibilidade alinhadas a regiões geográficas, como EUA Leste, EUA Oeste e Pacífico Asiático, para a implantação de todo o sistema que suporta uma região e base de usuários específica.

Desempenho

Uma rede de distribuição de conteúdo (CDN) é uma rede distribuída de servidores que são agrupados para entregar conteúdo, como arquivos de áudio e vídeo, de forma mais rápida e eficiente. Ela armazena em cache o conteúdo no servidor de borda para proporcionar um melhor desempenho com baixa latência.

Segurança

A CDN também melhora a segurança ao fornecer mitigação contra DDoS e algumas outras medidas de segurança.

O serviço de Pacote distribuirá os arquivos de áudio para CDNs para serem armazenados em cache nos servidores de borda. O serviço de Dados de Áudio atualizará a localização da CDN em seus metadados, que serão encaminhados para o serviço de Pesquisa para consulta pelos usuários.

 

O diagrama acima ilustra a arquitetura de componentes em alto nível de um sistema de áudio típico.

Conclusão

No coração de um bom sistema de áudio estão escalabilidade, desempenho e tolerância a falhas para oferecer uma boa experiência ao usuário com mínima distorção, baixa latência e confiabilidade.