Conception du système d’un service de streaming audio

La conception du système d’une application de streaming audio est unique dans sa façon de traiter les besoins commerciaux idiosyncratiques. En général, le streaming audio nécessite un grand volume de données à transférer dans la bande passante limitée du canal de communication réseau.

Un service de streaming audio réussi doit gérer des millions d’utilisateurs actifs et des milliers de fournisseurs de contenu provenant de divers emplacements géographiques. Différents appareils et plates-formes (smartphone, ordinateur de bureau, enceinte intelligente) peuvent prendre en charge différents formats audio tels que MP3, FLAC, ALAC, etc.

Dans cet article de blog, nous explorerons les nuances de la conception d’un tel système complexe en abordant les exigences fonctionnelles et non fonctionnelles.

Exigences fonctionnelles

Les exigences fonctionnelles couvriront les fonctionnalités requises pour les créateurs de contenu et les utilisateurs ou auditeurs audio.

• Gestion de contenu. Le créateur de contenu peut télécharger, supprimer ou mettre à jour des fichiers audio dans n’importe quel format. Chaque audio doit avoir des métadonnées telles que le titre, l’auteur, la description, la catégorie et des balises de métadonnées.
• Notification. Le créateur de contenu reçoit des notifications sur le succès ou l’échec de l’audio téléchargé. L’auditeur ou utilisateur audio reçoit des notifications sur le téléchargement réussi de l’audio.
• Streaming sans interruption. Les utilisateurs peuvent lire, mettre en pause, rembobiner et télécharger de l’audio dans le format de leur choix.
• Abonnez-vous. Les utilisateurs devraient pouvoir s’abonner à l’audio de leur choix pour recevoir des notifications sur le contenu nouveau ou mis à jour.
• Connexion des utilisateurs. Les créateurs de contenu doivent être authentifiés et autorisés à accéder au système. Les utilisateurs peuvent s’inscrire dans le système pour configurer leurs profils. 
• Recherche. Les utilisateurs devraient pouvoir rechercher de l’audio en fonction de certains attributs ou métadonnées.

Remarque : La diffusion en direct et les services de paiement ne relèvent pas du champ de cet article.

Diagramme de séquence du cas d’utilisation fonctionnel

Conception architecturale

Définissons les composants de service pour soutenir les exigences fonctionnelles.

La première exigence fonctionnelle est de télécharger de l’audio au format de votre choix tel que MP3, FLAC, ALAC, etc. Ces fichiers audio peuvent contenir une quantité impressionnante de données. Le codec audio joue un rôle crucial dans le stockage, la transmission et la lecture efficaces de ces données. Il existe principalement deux types de codecs :

1. Codec sans perte – compresse l’audio sans perdre de données et peut être entièrement restauré sans perte de qualité.
2. Codec avec perte – supprime certaines données, ce qui aide à réduire la taille de manière significative. Cela pourrait compromettre la qualité sonore.

Le fournisseur de contenu travaille généralement avec des formats sans perte pour l’enregistrement et l’édition. Cela garantit qu’aucune perte de qualité n’intervient lorsqu’ils manipulent l’audio, appliquent des effets et finalisent le produit. En termes simples, le mastering audio est l’étape finale du processus de production audio.

Une fois l’audio finalisé, il est converti en un format avec perte pour une distribution générale. Avec un format avec perte, la taille est réduite de manière significative, ce qui facilite et accélère le streaming et le téléchargement.

L’audio compressé doit être transmis à l’appareil de l’auditeur avec la bande passante réseau prise en charge. La bande passante peut varier dynamiquement, avec la charge réseau changeant en fonction du nombre d’utilisateurs connectés ou de l’utilisateur se déplaçant d’une zone réseau à une autre tout en écoutant l’audio.

Pour prendre en charge cette variation de bande passante réseau, le codec peut utiliser le mécanisme de « taux d’adaptation ». Le streaming à débit adaptatif détecte la bande passante des utilisateurs en temps réel, ajustant le flux en conséquence. Il peut changer dynamiquement le débit en fonction de la bande passante actuelle de l’utilisateur. Cela permet d’avoir peu de mise en mémoire tampon, des temps de démarrage plus rapides et une bonne expérience pour les connexions haut de gamme et bas de gamme.

L’encodeur code la source unique du fichier audio à plusieurs débits. Ces flux d’octets sont emballés et stockés dans le magasin d’objets pour être disponibles à l’auditeur. Une fois l’audio téléversé avec succès, le service de Notification envoie une notification au fournisseur de contenu.

 

Le créateur de contenu fournit en outre des métadonnées lorsqu’il demande de télécharger l’audio, qui peut être directement enregistré dans une base de données NoSQL via le service Audio Data. Ces données seront indexées pour offrir une meilleure capacité de recherche à l’auditeur audio.

Le système audio nécessite un service d’authentification et d’autorisation pour gérer l’inscription des nouveaux utilisateurs, la connexion en utilisant les informations d’identification de l’utilisateur, et l’autorisation basée sur les rôles associés aux utilisateurs (auditeurs et fournisseurs de contenu). Un service de passerelle API peut gérer de manière centralisée l’authentification et l’autorisation. Ce service peut être utilisé pour effectuer le routage des demandes et orchestrer le flux de processus du front-end au back-end.

L’utilisateur audio (auditeur) peut rechercher des audios d’intérêt, qui seront transmis au service Audio Data pour obtenir l’emplacement des audios pertinents, en extrayant des informations de la base de données de métadonnées audio. L’utilisateur clique sur le lien, et il recevra les octets audio empaquetés et stockés par le service de packaging.

Le service de profil utilisateur gère les préférences des utilisateurs, les abonnés et les abonnements.

Le diagramme ci-dessus illustre le flux de processus de base « télécharger audio » déclenché par le fournisseur de contenu et le flux de processus « écouter audio » déclenché par l’utilisateur/auditeur audio.

Le modèle de pipeline et de filtrage avec mise en file d’attente des messages est utilisé pour soutenir le flux de données entre les services afin d’optimiser le processus de manière efficace avec parallélisme et tolérance aux pannes.

Maintenant, passons aux exigences non fonctionnelles.

Exigences non fonctionnelles

• Scalabilité. Le système doit supporter des milliers d’utilisateurs concurrents et être capable de croître et de se rétrécir.
• Tolérance aux pannes. Le système doit être tolérant aux pannes, généralement avec des données redondantes, avec un temps d’arrêt minimal.
• Performance. Le système doit avoir une faible latence et une haute réactivité lors de la lecture de contenu.
• Sécurité. Le système doit être protégé contre les accès non autorisés ou les attaques nuisibles telles que les DDoS.

Scalabilité 

Le système audio doit être capable de supporter des milliers de créateurs de contenu actifs. Pour gérer la charge, la conception inclut l’exécution de plusieurs instances de service API Gateway, de service Web App et de service Audio Data, précédées par des équilibreurs de charge.

Cependant, cela ne sera pas évolutif avec l’augmentation du nombre de créateurs de contenu. Les fichiers audio sont généralement volumineux, ce qui nécessite une grande puissance réseau et de calcul lors de leur traversée à travers plusieurs composants de service. Pour optimiser l’utilisation des ressources du système, une URL signée (également appelée URL pré-signée) peut être utilisée pour fournir un accès temporaire à l’objet de stockage pour télécharger des fichiers audio directement. Cela élimine la nécessité de router le trafic via API Gateway et le service Web API. Les URLs signées peuvent être configurées avec des permissions granulaires et des règles d’expiration pour une meilleure sécurité.

Cela couvre l’exigence de scalabilité pour le téléchargement des fichiers audio par les fournisseurs de contenu.

Des millions de requêtes de recherche provenant des auditeurs audio pourraient frapper le système, provoquant une surcharge du service de données audio. Pour faire évoluer le système soutenant cette opération de recherche massive, le modèle de conception de la Ségrégation des Responsabilités de Requête de Contenu (CQRS) peut être utilisé. Les opérations de lecture et d’écriture vers/depuis la base de données peuvent être gérées indépendamment, soutenant différentes exigences en matière de latence, de scalabilité et de sécurité.

 

Tolérance aux pannes

Il existe diverses dimensions dans la conception de la tolérance aux pannes. Quelques-unes d’entre elles sont déjà incluses dans la conception.

• Utilisation de plusieurs instances de service pour la scalabilité et la tolérance aux pannes
• Mise en queue de messages avec traitement en pipeline pour soutenir la tolérance aux pannes au niveau du flux de données
• Séparation du service de transcoder et du service d’emballage
• Instances de base de données multiples avec répliques
• Zones de disponibilité alignées sur des régions géographiques telles que l’Est des États-Unis, l’Ouest des États-Unis et la région Asie-Pacifique pour le déploiement de l’ensemble du système soutenant une région et une base d’utilisateurs spécifiques.

Performance

Un réseau de diffusion de contenu (CDN) est un réseau distribué de serveurs regroupés pour livrer du contenu, tel que des fichiers audio et vidéo, plus rapidement et plus efficacement. Il met en cache le contenu sur le serveur de périphérie pour offrir de meilleures performances avec une faible latence.

Sécurité

Les CDN améliorent également la sécurité en fournissant une atténuation des attaques DDoS et quelques autres mesures de sécurité.

Le service Package distribuera les fichiers audio aux CDN pour qu’ils soient mis en cache sur les serveurs de bord. Le service Audio Data mettra à jour l’emplacement du CDN dans ses métadonnées qui seront acheminées vers le service de Recherche pour être interrogées par les utilisateurs.

 

Le diagramme ci-dessus représente l’architecture des composants de haut niveau d’un système audio typique.

Conclusion

Au cœur d’un bon système audio se trouvent la scalabilité, les performances et la tolérance aux pannes pour offrir une bonne expérience utilisateur avec une distorsion minimale, une latence faible et une fiabilité.