El diseño del sistema de una aplicación de streaming de audio es único en cómo aborda las necesidades empresariales idiosincráticas. Típicamente, el streaming de audio requiere una gran cantidad de datos que se transfieren dentro del ancho de banda limitado del canal de comunicación de la red.
Un servicio de streaming de audio exitoso debe manejar millones de usuarios activos y miles de proveedores de contenido de diversas ubicaciones geográficas. Diferentes dispositivos y plataformas (smartphone, escritorio, altavoz inteligente) pueden soportar diferentes formatos de audio como MP3, FLAC, ALAC, etc.
En esta publicación de blog, exploraremos las sutilezas de diseñar un sistema tan complejo cubriendo requisitos funcionales y no funcionales.
Requisitos Funcionales
Los requisitos funcionales abarcarán las características necesarias para los creadores de contenido y los usuarios o oyentes de audio.
- Gestión de contenido. El creador de contenido puede subir, eliminar o actualizar audio en cualquier formato. Cada audio debe tener metadatos como título, autor, descripción, categoría y etiquetas de metadatos.
- Notificación. El creador de contenido recibe notificaciones sobre el éxito o fracaso de la carga de audio. El oyente o usuario de audio recibe notificaciones sobre la carga exitosa de audio.
- Streaming sin interrupciones. Los usuarios pueden reproducir, pausar, rebobinar y descargar audio en el formato de su elección.
- Subscribirse. Los usuarios deberían poder suscribirse al audio de su elección para recibir notificaciones sobre contenido nuevo o actualizado.
- Iniciar sesión de usuario. Los creadores de contenido deben autenticarse y estar autorizados para acceder al sistema. Los usuarios pueden registrarse en el sistema para configurar sus perfiles.
- Buscar. Los usuarios deberían poder buscar audio basado en ciertos atributos o metadatos.
Nota: Los servicios de transmisión en vivo y de pago están fuera del alcance de este artículo.
Diagrama de secuencia del caso de uso funcional
Diseño arquitectónico
Definamos componentes de servicio para respaldar los requisitos funcionales.
El primer requisito funcional es cargar audio utilizando cualquier formato como MP3, FLAC, ALAC, etc. Estos archivos de audio pueden contener una cantidad impresionante de datos. El códec de audio juega un papel crucial en almacenar, transmitir y reproducir eficientemente estos datos. Principalmente existen dos tipos de códecs:
- Códec sin pérdida – comprime audio sin perder ningún dato y puede ser completamente restaurado sin perder calidad.
- Códec con pérdida – elimina algunos datos lo que ayuda a reducir significativamente el tamaño. Esto podría comprometer la calidad del sonido.
El proveedor de contenido generalmente trabaja con formatos sin pérdida para grabar y editar. Esto asegura que no haya pérdida de calidad mientras operan el audio, aplican efectos y masterizan el producto final. En términos simples, la masterización de audio es el último paso en el proceso de producción de audio.
Una vez que el audio final ha sido masterizado, se convierte a un formato con pérdida para distribución general. Con un formato con pérdida, el tamaño se reduce en mayor medida, facilitando y acelerando la transmisión y descarga.
El audio comprimido necesita ser transmitido al dispositivo del oyente con el ancho de banda de red soportado. El ancho de banda podría variar dinámicamente, con la carga de la red cambiando según el número de usuarios conectados o el usuario moviéndose de una zona de red a otra mientras escucha el audio.
Para soportar este ancho de banda de red cambiante, el códec podría utilizar el mecanismo de “tasa de bits adaptativa”. La transmisión de tasa de bits adaptativa detecta el ancho de banda de los usuarios en tiempo real, ajustando la transmisión en consecuencia. Puede cambiar dinámicamente la tasa de bits de transmisión según el ancho de banda actual del usuario. Esto resulta en poco almacenamiento en búfer, tiempos de inicio más rápidos y una buena experiencia tanto para conexiones de alta gama como de gama baja.
El codificador codifica la única fuente del archivo de audio a múltiples tasas de bits. Estos flujos de bytes se empaquetan y almacenan en el almacenamiento de objetos para estar disponibles para el oyente. Una vez que el audio se ha subido con éxito, el servicio de notificación envía una notificación al proveedor de contenido.
El creador de contenido además proporciona metadatos al solicitar la carga del audio, que se pueden guardar directamente en una base de datos NoSQL a través del servicio de datos de audio. Estos datos se indexarán para ofrecer una mejor capacidad de búsqueda al oyente de audio.
El sistema de audio necesita un servicio de autenticación y autorización para manejar el registro de nuevos usuarios, el inicio de sesión utilizando las credenciales del usuario y la autorización basada en los roles asociados con los usuarios (oyentes y proveedores de contenido). El servicio de API Gateway que puede gestionar de forma centralizada la autenticación y autorización. Este servicio se puede aprovechar para realizar el enrutamiento de solicitudes y orquestar el flujo de procesos desde el front-end al servicio de back-end.
El usuario de audio (oyente) podría buscar audio de interés, que se enviará al servicio de datos de audio para devolver la ubicación del audio relevante, extrayendo información de la tienda de metadatos de audio. El usuario hace clic en el enlace, y devolverá los bytes de audio empaquetados y almacenados por el servicio de empaquetado.
El servicio de perfil de usuario gestiona las preferencias de los usuarios, seguidores y seguidos.
El diagrama anterior representa el flujo de proceso básico de “cargar audio” activado por el proveedor de contenido y el flujo de proceso de “escuchar audio” activado por el usuario/oyente de audio.
El patrón de diseño de canalización y filtrado con encolado de mensajes se está utilizando para admitir el flujo de datos entre servicios y escalar el proceso de manera eficiente con paralelismo y tolerancia a fallos.
Ahora, pasemos a los requisitos no funcionales.
Requisitos no funcionales
- Escalabilidad. El sistema debe soportar miles de usuarios concurrentes y poder crecer y disminuir.
- Tolerancia a fallos. El sistema debe ser tolerante a fallos, generalmente con datos redundantes, con poco tiempo de inactividad.
- Rendimiento. El sistema debe tener baja latencia y alta capacidad de respuesta durante la reproducción de contenido.
- Seguridad. El sistema debe estar protegido contra accesos no autorizados o ataques dañinos como DDoS.
Escalabilidad
El sistema de audio debe poder soportar miles de creadores de contenido activos. Para gestionar la carga, el diseño incluye la ejecución de múltiples instancias del servicio de API Gateway, servicio web de la aplicación y servicio de datos de audio a través de balanceadores de carga.
Sin embargo, esto no será escalable con el aumento en el número de creadores de contenido. Los archivos de audio suelen ser grandes, lo que utilizará una alta potencia de red y computación al atravesar múltiples componentes de servicio. Para optimizar el uso de recursos del sistema, se puede utilizar una URL firmada (también conocida como URL prefirmada) para proporcionar acceso limitado en el tiempo al almacén de objetos para cargar archivos de audio directamente. Esto elimina la necesidad de enrutar el tráfico a través de API Gateway y el servicio web de API. Las URL firmadas se pueden configurar con permisos granulares y reglas de vencimiento para una mayor seguridad.
Esto cubre el requisito de escalabilidad para la carga de archivos de audio por parte de los proveedores de contenido.
Millones de solicitudes de búsqueda de los oyentes de audio podrían afectar al sistema, causando una sobrecarga en el servicio de Datos de Audio. Para escalar el sistema que soporta esta operación de búsqueda masiva, se puede utilizar el patrón de diseño de Separación de Responsabilidad de Consulta de Contenido (CQRS). Las operaciones de lectura y escritura desde/hacia el almacén de datos pueden gestionarse de manera independiente, apoyando diferentes requisitos de latencia, escalabilidad y seguridad.
Tolerancia a Fallos
Existen varias dimensiones en el diseño de tolerancia a fallos. Algunas de ellas ya están incluidas en el diseño.
- Uso de múltiples instancias de servicio para escalabilidad y tolerancia a fallos
- Colas de mensajes con procesamiento en pipeline para soportar la tolerancia a fallos a nivel de flujo de datos
- Separación del servicio de transcodificación y del servicio de empaquetado
- Múltiples instancias de base de datos con réplicas
- Zonas de Disponibilidad alineadas a regiones geográficas como la Costa Este de EE.UU., la Costa Oeste de EE.UU. y Asia-Pacífico para el despliegue de todo el sistema que soporta una región específica y base de usuarios.
Rendimiento
Una red de entrega de contenido (CDN) es una red distribuida de servidores que se agrupan para entregar contenido, como archivos de audio y video, de manera más rápida y eficiente. Almacena el contenido en el servidor de borde para proporcionar un mejor rendimiento con baja latencia.
Seguridad
CDN también mejora la seguridad al proporcionar mitigación de DDoS y algunas otras medidas de seguridad.
El servicio de Paquete distribuirá los archivos de audio a los CDN para ser almacenados en caché en los servidores de borde. El servicio de Datos de Audio actualizará la ubicación del CDN en sus metadatos que serán enviados al servicio de Búsqueda para ser consultados por los usuarios.
El diagrama anterior representa la arquitectura de componentes a alto nivel de un sistema de audio típico.
Conclusión
En el corazón de un buen sistema de audio están la escalabilidad, el rendimiento y la tolerancia a fallos para proporcionar una buena experiencia de usuario con mínima distorsión, baja latencia y fiabilidad.
Source:
https://dzone.com/articles/system-design-of-an-audio-streaming-system