Diagramme d'architecture de streaming vidéo : upload, transcodage, packaging, diffusion

« Concevez YouTube » est une question de conception de système appréciée, parce que les parties intéressantes ne sont pas là où on les attend. Les serveurs web sont ordinaires. Le vrai travail consiste à transférer de manière fiable des gigaoctets d'un téléphone vers le stockage, à transformer un upload en une douzaine de versions lisibles sur tous les appareils et toutes les connexions, et à servir ces octets depuis un CDN pour que vos propres serveurs les voient à peine.

Cet article parcourt ce pipeline dans l'ordre : upload, transcodage, packaging, diffusion. Il se termine par un diagramme d'architecture à adapter, et par les décisions qui méritent d'y figurer.

Deux systèmes, pas un

Une plateforme vidéo, ce sont deux systèmes qui partagent une base de données :

• Ingestion : les créateurs envoient leurs vidéos ; la plateforme les transcode et les package. La latence se compte en minutes et personne ne s'en soucie.
• Lecture : les spectateurs appuient sur lecture ; la première image doit apparaître en quelques secondes et ne doit pas se bloquer.

Dessinez-les comme deux couloirs. Ils évoluent selon des signaux différents (uploads par heure contre spectateurs simultanés) et tombent en panne de façons différentes.

Upload : jamais par vos serveurs d'API

Les fichiers vidéo sont gros et les connexions mobiles se coupent. Deux règles en découlent :

1. Envoyer directement vers le stockage objet. L'API d'upload authentifie le créateur, crée un enregistrement vidéo et renvoie des URL présignées. Le client envoie les octets directement dans le bucket. Votre API ne relaie jamais des gigaoctets.
2. Le rendre reprenable. Utilisez des uploads multipart pour qu'une connexion coupée ne retente que la partie en échec. L'upload multipart d'Amazon S3, par exemple, envoie les parties indépendamment et les assemble quand le client termine l'upload.

Quand l'upload est terminé, l'événement de stockage (ou l'appel de fin du client) place une tâche de transcodage dans une file.

Transcodage : un upload, une échelle de débits adaptatifs

Les lecteurs changent de qualité selon la bande passante, donc vous encodez chaque vidéo plusieurs fois : une échelle de débits adaptatifs (ABR). Une échelle typique va d'environ 240p ou 360p jusqu'à 1080p ou 4K, chaque palier avec son propre débit.

Le transcodage est gourmand en CPU et se parallélise très facilement :

• Découper la source en morceaux de quelques secondes, aux images clés.
• Encoder chaque morceau et chaque rendu comme une tâche indépendante sur une flotte de workers, généralement avec FFmpeg.
• Assembler les résultats, ou les garder sous forme de segments.

Un film de deux heures se transcode alors en quelques minutes au lieu de plusieurs heures, et une tâche en échec ne retente qu'un morceau. Rendez les tâches idempotentes en les indexant par vidéo, rendu et morceau, pour qu'un retry écrase au lieu de dupliquer.

Une seule échelle pour tous les contenus gaspille des bits : une présentation statique demande bien moins de débit qu'un match de football. Netflix a popularisé l'encodage par titre, qui choisit l'échelle de chaque vidéo selon sa complexité. Vous pouvez commencer avec une échelle fixe et passer à l'encodage par titre plus tard.

Packaging : HLS, DASH et CMAF

Les lecteurs ne téléchargent pas un gros fichier. Ils lisent un manifeste qui liste les rendus et les segments, puis récupèrent des segments de quelques secondes en HTTP classique.

CMAF est la raison pour laquelle le packager compte : avec lui, vous stockez un seul jeu de segments et écrivez deux manifestes au lieu de deux copies de chaque vidéo. Des segments courts démarrent plus vite et changent de qualité plus tôt ; des segments plus longs coûtent moins de requêtes. La spécification de création HLS d'Apple donne des recommandations concrètes sur la durée des segments, les images clés et les échelles.

Le contenu payant ajoute du DRM. Le packager chiffre les segments une seule fois avec le chiffrement commun (CENC), et le système DRM de chaque plateforme (Widevine, FairPlay, PlayReady) délivre des licences aux lecteurs via un serveur de licences.

Diffusion : le CDN fait le travail

Les segments sont des fichiers statiques, et c'est tout l'intérêt : un CDN les met en cache près des spectateurs, et une vidéo populaire est servie presque entièrement depuis les caches en périphérie. L'origine est le bucket des rendus, souvent derrière un origin shield, pour qu'un échec de cache dans 50 points de présence devienne une seule requête vers le stockage.

L'API de lecture reste petite : vérifier que le spectateur a le droit de regarder la vidéo, renvoyer une URL de manifeste (signée si le contenu est privé) et enregistrer les événements de lecture pour l'analytique.

Le direct est un autre pipeline

La vidéo en direct réutilise le packaging et le CDN, mais remplace l'ingestion. Un encodeur pousse un flux par un protocole comme RTMP ou SRT vers un serveur d'ingestion, qui transcode l'échelle en temps réel et écrit de nouveaux segments toutes les quelques secondes. La latence vient de la durée des segments plus la mémoire tampon du lecteur ; les modes basse latence de HLS et DASH livrent des parties d'un segment avant qu'il soit complet pour se rapprocher de quelques secondes. Gardez le direct et la vidéo à la demande comme des pipelines séparés qui partagent le CDN, le lecteur et les métadonnées.

Le diagramme d'architecture

Comment le lire :

• Couloir du haut, ingestion : le créateur obtient une URL d'upload auprès de l'API d'upload (1), envoie des parties directement dans le bucket des uploads bruts (2), et l'upload terminé met en file les tâches de transcodage (3). Les workers encodent l'échelle, et le packager écrit les segments dans le bucket des rendus et marque la vidéo prête dans le stockage des métadonnées.
• Couloir du bas, lecture : le spectateur demande une URL de manifeste à l'API de lecture, puis lit les segments depuis le CDN. Un échec de cache lit le bucket des rendus.
• Le DRM est en pointillé, car seul le contenu protégé en a besoin : le lecteur obtient une licence auprès du serveur de licences.
• Le bloc Markdown montre un exemple d'échelle. Vos chiffres doivent venir de vos contenus et de la bande passante de vos spectateurs.

Ce qu'il faut mettre sur le diagramme

• Le trajet des octets. Dessinez les uploads et les segments qui vont vers le stockage et le CDN, pas à travers votre API.
• L'unité de travail. « Une tâche par rendu et par morceau » indique aux relecteurs comment fonctionnent les retries et le parallélisme.
• Formats et protection. Nommez HLS, DASH ou CMAF, et le DRM si vous l'utilisez.
• Le signal « prête ». Une vidéo n'est lisible qu'une fois le packaging terminé ; montrez où vit cet état.

La même forme file et workers apparaît dans l'article sur l'architecture événementielle. Côté cloud, le diagramme d'architecture AWS multi-région traite la diffusion depuis plusieurs régions, et le diagramme d'architecture serverless montre comment des événements de stockage peuvent déclencher des fonctions au lieu d'une flotte de workers.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez deux nœuds Personne du pack Modèle C4 pour le créateur et le spectateur.
3. Ajoutez des nœuds Conteneur pour l'API d'upload, les workers de transcodage, le packager et l'API de lecture, ainsi qu'une Base de données pour les métadonnées vidéo.
4. Ajoutez deux nœuds Stockage objet et un CDN du pack Cloud, une File d'attente du pack Données pour les tâches de transcodage et un Système externe pour le serveur de licences DRM.
5. Dessinez l'ingestion dans le couloir du haut et la lecture dans celui du bas, numérotez les étapes d'upload sur les arêtes et ajoutez un bloc Markdown du pack Base avec votre échelle.

L'exemple utilise 13 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Qu'est-ce qu'une échelle de débits adaptatifs ? L'ensemble des rendus dans lesquels une vidéo est encodée, chacun avec sa résolution et son débit. Le lecteur choisit le meilleur que la connexion du spectateur peut tenir, et change quand la bande passante varie.

Faut-il utiliser HLS ou DASH ? Souvent les deux. Packagez une fois en segments CMAF et écrivez un manifeste HLS et un manifeste DASH : les appareils Apple et les autres lecteurs sont couverts sans stocker deux copies.

Pourquoi envoyer directement vers le stockage objet ? De gros fichiers qui passent par vos serveurs d'API monopolisent connexions et mémoire, et une connexion coupée fait recommencer l'upload. Les uploads multipart présignés vont directement dans le stockage et reprennent partie par partie.

Comment le transcodage est-il parallélisé ? Découpez la source en morceaux aux images clés et encodez chaque morceau et chaque rendu comme une tâche séparée, puis assemblez ou packagez les résultats.

Faut-il un CDN pour la vidéo ? Au-delà d'un petit public, oui. Les segments sont des fichiers statiques, et un CDN sert les requêtes répétées depuis des caches proches des spectateurs plutôt que depuis votre stockage.

Commencez gratuitement — un siège, sans carte bancaire.