2 Le stockage du serveur d’origine vidéo est au cœur de tout service de streaming. Qu’il s’agisse d’un opérateur télécoms qui propose la télévision à ses abonnés, d’un diffuseur qui exploite replay et vidéo à la demande ou d’une plateforme qui diffuse des événements en direct, l’origine est l’endroit où résident les segments de contenu avant que les réseaux de diffusion de contenu (CDN) et les caches en bordure ne les acheminent jusqu’aux spectateurs. Quand le stockage de l’origine est lent ou indisponible, chaque défaut de cache se transforme en roue de chargement. Quand il est sous-dimensionné, le catalogue ne peut pas grandir. Quand il est surdimensionné, il consomme discrètement le budget. Cet article explique le rôle d’une origine, ce que son stockage doit apporter et les architectures utilisées par les opérateurs, avec des conseils pratiques de dimensionnement et de résilience. Il s’adresse aux architectes des plateformes vidéo des opérateurs télécoms, des diffuseurs et des services de streaming. Le rôle d’un serveur d’origine Dans une architecture de streaming type : Les encodeurs et transcodeurs produisent plusieurs déclinaisons de chaque contenu à différents débits et résolutions. Les packagers découpent les déclinaisons en segments et créent les manifestes pour les formats de streaming comme HLS et DASH, à l’avance ou à la volée. L’origine stocke les segments et les manifestes et les sert aux CDN et aux caches en bordure à la demande. Les CDN et caches en bordure gardent les contenus populaires près des spectateurs et sollicitent l’origine lorsqu’ils ne les ont pas. Le rôle de l’origine est de répondre rapidement et de façon fiable aux défauts de cache, quel que soit le niveau de concurrence généré par le CDN. Pour les chaînes en direct, elle absorbe aussi un flux constant de nouveaux segments et les sert en quelques secondes. Ce que le stockage de l’origine doit apporter Un débit de lecture et une concurrence élevés Les contenus populaires sont surtout servis par les caches du CDN, mais la longue traîne du catalogue, les nouveautés à leur sortie et les rafraîchissements de cache sollicitent tous l’origine. Le stockage de l’origine doit soutenir un débit de lecture agrégé élevé et de nombreuses requêtes simultanées, avec une latence prévisible. Des performances sur les petits et moyens objets Les segments de streaming durent généralement quelques secondes chacun : un seul titre peut donc produire des milliers de segments par déclinaison. Les manifestes sont de petits fichiers lus en permanence. Le stockage doit gérer de très grands nombres d’objets et des taux de requêtes élevés, et pas seulement de gros transferts séquentiels. Des performances d’écriture pour le direct et le replay Les chaînes en direct écrivent de nouveaux segments en continu. Les services de replay et de cloud DVR enregistrent de nombreuses chaînes 24 heures sur 24. Le stockage de l’origine doit absorber ces écritures tout en servant les lectures. Capacité et croissance Les catalogues grossissent avec l’ajout de contenus et la production de nouvelles déclinaisons, comme les résolutions supérieures et le HDR. Stocker plusieurs déclinaisons multiplie la capacité. Le stockage doit grandir sans interruption. Disponibilité Une panne de l’origine peut toucher tous les spectateurs dont le contenu n’est pas en cache. Le stockage doit tolérer les pannes matérielles sans interruption et permettre des architectures multisites pour la reprise après sinistre. Les architectures de stockage des origines Stockage local sur les serveurs d’origine Les petits services peuvent stocker les contenus directement sur les serveurs d’origine. C’est simple mais difficile à faire évoluer : les contenus doivent être répliqués sur chaque serveur, et la capacité est limitée par les disques de chacun. NAS partagé Les origines peuvent monter un stockage de fichiers partagé pour que chaque serveur voie l’ensemble du catalogue. Cela fonctionne à échelle modérée, mais un NAS peut peiner face à des nombres de fichiers et des requêtes simultanées très élevés, et les baies scale-up deviennent coûteuses. Stockage objet Le stockage objet s’étend par ajout de nœuds, gère des milliards d’objets et sert les contenus via des API HTTP comme S3. De nombreux packagers et logiciels d’origine peuvent lire et écrire directement dans le stockage objet. Certaines architectures utilisent le stockage objet comme origine elle-même, les CDN puisant directement dedans, tandis que d’autres placent des serveurs d’origine en frontal pour gérer l’empaquetage, l’authentification et la logique des requêtes. Origines hiérarchisées Les grands opérateurs combinent souvent un niveau performance pour le direct et les contenus récents avec un niveau capacité pour l’ensemble du catalogue. Les contenus populaires et en direct résident sur un stockage rapide, tandis que les titres de la longue traîne résident sur un stockage objet et sont récupérés à la demande. Le mode d’empaquetage influe sur le stockage Contenus pré-empaquetés Les contenus sont empaquetés à l’avance dans chaque format et stockés sous forme de segments. Les besoins de stockage sont plus élevés, puisque chaque format et chaque déclinaison sont stockés séparément, mais la diffusion est simple. Empaquetage à la volée Les contenus sont stockés une seule fois dans un format mezzanine ou commun, et l’origine empaquette les segments à la demande pour chaque format de streaming. Cela réduit le stockage, mais demande plus de calcul à l’origine et des lectures rapides des fichiers sources. Beaucoup d’opérateurs combinent les deux : empaquetage à la volée pour la longue traîne et segments pré-empaquetés pour les contenus les plus populaires. Ce choix influe sur la capacité, les profils de requêtes et le calcul placé devant le stockage. Délestage par le CDN et charge de l’origine Les taux de succès du cache CDN déterminent la part du trafic qui atteint l’origine. Un taux élevé signifie que l’origine ne sert qu’une petite part du trafic total, mais cette part peut rester importante en valeur absolue pour un grand service, et elle bondit lorsque les caches sont froids, par exemple après un changement de CDN, une grande sortie ou le début d’un événement en direct. Dimensionnez le stockage de l’origine pour le trafic de défauts de cache au pic, pas pour la moyenne. Le blindage de l’origine (origin shield), où un cache intermédiaire s’intercale entre les caches en bordure et l’origine, peut réduire encore la charge. Résilience et architecture multisite Les services de streaming exploitent généralement des origines sur au moins deux sites. Les modèles courants sont : Des origines actif-actif sur deux sites, chacune détenant l’intégralité du catalogue, avec bascule des CDN de l’une à l’autre. Des origines primaire et secondaire, avec réplication de l’une vers l’autre. Un stockage objet étendu sur plusieurs sites, pour que les serveurs d’origine de chaque site puissent lire n’importe quel contenu. Testez la bascule sous une charge réaliste, y compris ce qui arrive aux chaînes en direct et aux rafraîchissements de cache pendant l’opération. Sécurité et gestion des droits Les origines doivent protéger les contenus contre les accès non autorisés. Les contrôles habituels comprennent des URL à jeton ou des requêtes signées entre CDN et origine, le chiffrement des contenus par gestion des droits numériques (DRM) et la restriction de l’accès à l’origine aux réseaux du CDN et internes. Les identifiants d’accès au stockage doivent être limités aux services d’origine et d’empaquetage. Les considérations régionales Les opérateurs font face à des contraintes différentes selon les régions. Les diffuseurs et opérateurs télécoms européens ont souvent des obligations de contenus nationaux et des préférences en matière de résidence des données : leurs origines se trouvent généralement dans des centres de données nationaux. Sur des marchés comme le Japon et le Moyen-Orient, l’hébergement local est courant pour des raisons de latence et de réglementation. Les accords de droits restreignent souvent les lieux de stockage et de diffusion des contenus, ce qui façonne l’emplacement des origines autant que la technologie. Planifiez les emplacements des origines selon la géographie de l’audience, les droits et la résidence, puis laissez les CDN étendre la portée. Superviser l’origine Les problèmes d’origine se manifestent d’abord par des plaintes de spectateurs : la supervision doit les détecter plus tôt. Suivez les taux de requêtes, les taux d’erreur et les percentiles de latence à l’origine, les taux de succès du cache CDN et la santé du stockage derrière l’origine. Surveillez les hausses soudaines du trafic d’origine, souvent le signe d’un changement de configuration du CDN ou d’une purge de cache, et la hausse de la latence pendant les événements en direct, lorsque l’origine écrit de nouveaux segments tout en les servant. Dimensionner une origine Un exercice de dimensionnement pragmatique comprend : La taille du catalogue : nombre de titres et d’heures, multiplié par les déclinaisons et formats stockés. Les chaînes en direct : nombre de chaînes, débits et durée de conservation des segments pour le time-shift et le replay. Le trafic d’origine au pic : taux de défauts de cache CDN attendu lors des événements de pointe, en requêtes par seconde et en Gbit/s. Le nombre d’objets : segments par heure de contenu multipliés par les déclinaisons et les formats. La croissance : nouveaux contenus par an et ajouts de formats prévus. Le surcoût de protection et les copies sur les sites secondaires. Liste de contrôle : stockage du serveur d’origine vidéo Cartographier le workflow de streaming de l’encodage au CDN. Choisir entre empaquetage préalable, à la volée ou hybride. Dimensionner pour le trafic et les taux de requêtes d’origine au pic, pas en moyenne. Vérifier que le stockage gère de très grands nombres d’objets et de petits fichiers. Planifier la capacité d’écriture pour le direct, le replay et le cloud DVR. Choisir un stockage qui s’étend par ajout de nœuds. Concevoir des origines multisites et tester la bascule. Sécuriser l’accès à l’origine par jetons, DRM et identifiants restreints. Placer les origines selon l’audience, les droits et la résidence. En résumé Le stockage du serveur d’origine vidéo doit répondre rapidement aux défauts de cache du CDN, absorber les écritures du direct et conserver un catalogue croissant de déclinaisons. Le stockage objet en est devenu une base courante parce qu’il s’étend en scale-out, gère d’énormes nombres d’objets et parle des API HTTP, souvent associé à un niveau performance pour le direct et les contenus populaires. Dimensionnez pour le trafic de défauts de cache au pic, concevez une résilience multisite et choisissez les emplacements selon les droits et les exigences régionales. Pour le volet catalogue, voir où un diffuseur doit stocker son catalogue VOD. Questions fréquentes Qu’est-ce qu’un serveur d’origine vidéo ? C’est la source à laquelle les CDN et les caches en bordure vont chercher les segments et manifestes de streaming lorsqu’ils ne les ont pas déjà en cache. Le stockage objet peut-il servir d’origine de streaming ? Oui. Dans certaines architectures, les CDN puisent directement dans le stockage objet, et de nombreuses plateformes d’origine et d’empaquetage lisent dans le stockage objet derrière des serveurs d’origine. Quelle part du trafic atteint l’origine ? Cela dépend des taux de succès du cache CDN. Même avec des taux élevés, les événements de pointe et les caches froids peuvent provoquer de fortes rafales de trafic vers l’origine. L’empaquetage à la volée réduit-il le stockage ? Oui. Stocker les contenus une seule fois et les empaqueter à la demande évite de stocker chaque format séparément, au prix d’un calcul accru à l’origine. Comment les opérateurs rendent-ils les origines résilientes ? Avec des origines multisites, un stockage répliqué ou étendu et une bascule des CDN, testés sous une charge réaliste. Pour aller plus loin Stockage pour le cloud DVR Stockage des catalogues VOD Les archives médias nearline Les gestionnaires d’actifs médias sur stockage objet Stockage des données télécoms (en anglais)
