Design do Sistema de um Serviço de Streaming de Áudio

O design do sistema de um aplicativo de streaming de áudio é único na forma como lida com necessidades empresariais 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 localizações 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 características 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 falha do áudio enviado. O ouvinte ou usuário de áudio recebe notificações sobre o envio 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 ser capazes de se inscrever no áudio de sua escolha para receber notificações sobre novos conteúdos ou conteúdos atualizados.
• 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.
• Pesquisar. Os usuários devem ser capazes de pesquisar áudio com base em certos atributos ou metadados.

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

Diagrama de sequência do caso de uso funcional

Design arquitetônico

Vamos definir os componentes de serviço para suportar os requisitos funcionais.

O primeiro requisito funcional é fazer upload de á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 na armazenagem, transmissão e reprodução eficiente 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 pode comprometer a qualidade do som.

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

Uma vez que o áudio final foi masterizado, ele é convertido para um formato com perda para distribuição geral. Com um formato com perda, o tamanho é reduzido em maior medida, facilitando e acelerando o streaming e o download.

O áudio comprimido precisa ser transmitido para o dispositivo do ouvinte com a largura de banda de 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 ouve o áudio.

Para suportar essa largura de banda de rede variável, o codec pode utilizar o mecanismo de “taxa de bits adaptativa”. O streaming com taxa de bits adaptativa detecta a largura de banda dos usuários em tempo real, ajustando o stream de acordo. Ele pode alternar dinamicamente a taxa de bits do streaming com base na largura de banda atual do usuário. Isso resulta em pouco buffering, 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 várias taxas de bits. Esses fluxos de bytes são empacotados e armazenados no armazenamento de objetos para estar disponível ao ouvinte. Uma vez que o áudio é enviado com sucesso, o serviço de Notificação envia uma notificação ao provedor de conteúdo.

 

O criador de conteúdo fornece adicionalmente metadados ao solicitar o envio do áudio, que pode ser salvo 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 precisa de um serviço de autenticação e autorização para gerenciar o registro de novos usuários, login utilizando 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 requisições e orquestrar o fluxo de processo do front-end para o serviço de back-end.

O usuário de áudio (ouvinte) pode buscar por á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 embalados e armazenados pelo serviço de Pacote.

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

O diagrama acima retrata o fluxo básico do processo “enviar á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 serviços, escalando 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

• Escalabilidade. O sistema deve suportar milhares de usuários simultâneos e ser capaz de crescer e encolher.
• Tolerância a falhas. O sistema deve ser tolerante a falhas, geralmente com dados redundantes, com baixa indisponibilidade.
• 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.

Escalabilidade

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 API Gateway, serviço App Web e serviço de Dados de Áudio, com balanceadores de carga à frente.

No entanto, isso não será escalável com o aumento no número de criadores de conteúdo. Os arquivos de áudio costumam ser grandes, o que utilizará alta rede e poder computacional ao atravessar vários componentes de serviço. Para otimizar o uso dos recursos do sistema, uma URL assinada (também conhecida como URL pré-assinada) pode ser usada para fornecer acesso temporário ao armazenamento de objetos para carregar arquivos de áudio diretamente. Isso elimina a necessidade de direcionar o tráfego via API Gateway e serviço API Web. As URLs assinadas podem ser configuradas com permissões granulares e regras de expiração para 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 atingir o sistema, causando sobrecarga no serviço de Dados de Áudio. 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 datastore 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 para o 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 do fluxo de dados
• Separação do serviço de transcodificação e do serviço de empacotamento
• Múltiplas instâncias de DB com réplica
• Zonas de Disponibilidade alinhadas a regiões geográficas, como EUA Leste, EUA Oeste e Pacífico Asiático, para a implementação de todo o sistema que suporta uma região e base de usuários específica.

Desempenho

Uma rede de entrega de conteúdo (CDN) é uma rede distribuída de servidores que estã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 oferecer melhor desempenho com baixa latência.

Segurança

A CDN também melhora a segurança ao fornecer mitigação de 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 Busca para consulta pelos usuários.

 

O diagrama acima retrata 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 a escalabilidade, o desempenho e a tolerância a falhas para proporcionar uma boa experiência ao usuário com distorção mínima, baixa latência e confiabilidade.