Home Articles techniques Optimisation du CDN pour la diffusion en direct
Applications

Optimisation du CDN pour la diffusion en direct

About The Author

Outline

Flash Crowd et votre diffusion en direct

Alors que les services de streaming se battent pour un nombre limité de téléspectateurs et que l’attention diminue, les événements en direct, qui sont un moteur éprouvé de l’engagement du public, sont devenus un facteur important dans la stratégie de contenu d’un éditeur. Cependant, même si le streaming en direct peut diffuser des audiences de manière fiable, le streaming fiable d’événements en direct à grande échelle comporte un ensemble de défis. Les réseaux de diffusion de contenu (CDN) peuvent aider à fournir une évolutivité à la demande ; cependant, même les CDN doivent être optimisés pour la diffusion en direct.

Peut-être le défi le plus évident de streaming en direct est la «foule flash» — ce phénomène se produit lorsque de nombreux téléspectateurs entrent dans un flux en direct à la fois — avides de prendre le coup d’envoi ou d’effectuer des heures supplémentaires. Suivant le comportement typique du public que nous avons observé en diffusant plus de 100 000 événements sportifs, lors du match de finale de la NBA 6, le nombre de téléspectateurs a augmenté rapidement, passant de presque rien à tipoff à un pic de 2,04 millions de téléspectateurs au 3e trimestre. Le nombre de téléspectateurs est passé de moins de 10 000 sessions à plus de 1 millions dans la première heure et à 1,5 millions après la mi-temps, ajoutant parfois plus de 100 000 nouveaux téléspectateurs par minute. Ce type d’échelle rapide met la pression sur n’importe quel CDN. Mais la diffusion de vidéos en direct est encore plus difficile. Toute interruption peut entraîner une interruption de la lecture.

Comme l’illustre cet exemple tiré d’un récent événement en direct sur notre réseau, le phénomène du « flash crowd » rend la diffusion de vidéos via un CDN plus difficile que la diffusion d’octets de contenu réguliers.

Dans cet article, nous nous penchons sur les foules et autres défis, puis nous explorons comment Verizon Media tire parti de ses nombreuses années d’expérience dans le domaine du CDN pour résoudre certains des problèmes courants de nos clients, ce qui en fait le bon choix pour offrir des événements en direct de haute qualité – peu importe s’il s’agit de sports, de concerts, de politique… ou peut-être du premier atterrissage sur Mars.

Pourquoi Live Stream Caching est différent

La diffusion d’événements en direct sur Internet implique l’utilisation d’un ou plusieurs formats de streaming ABR (Adaptive bitrate), tels que MPEG-DASH, Apple HLS, Adobe HDS et Microsoft Smooth Streaming. Il s’appuie généralement sur des serveurs Web HTTP standard comme origines et CDN pour distribuer le contenu à grande échelle.

Notre vaste CDN mondial chez Verizon Media, aujourd’hui Edgio, dispose de nombreux pop et d’une capacité de plus de 250+ Tbps, ce qui nous permet de nous adapter facilement pour gérer les pics de trafic importants et les foules flash. Cependant, la capacité et l’échelle ne sont qu’une partie de l’équation. Ce qui est particulièrement important dans le streaming en direct, c’est la capacité du CDN à interagir avec le serveur d’origine et les clients tout en s’adaptant à un large public de visionnage qui vient tout à la fois.

Le profil de trafic en direct est unique et nettement différent de tout le reste, même de la VOD, car pendant les événements en direct, l’encodeur publie continuellement de nouveaux segments de médias (la durée typique est de 2 à 10 secondes) sur le serveur d’origine, et le CDN récupère toujours ce contenu nouvellement publié et le propage à travers le réseau. Ce processus prend un temps différent de zéro ; par conséquent, une certaine latence ne peut pas être évitée. Cependant, il est crucial que le CDN soit extrêmement efficace et intelligent pour remplir le cache et gérer les requêtes des clients pendant et, plus important encore, avant de lancer le processus de remplissage du cache. Idéalement, le CDN devrait être en mesure de maintenir la charge sur le serveur d’origine à un minimum absolu tout en évitant d’ajouter trop de latence supplémentaire à l’ensemble du pipeline multimédia. Cela garantit aux utilisateurs finaux côté client une lecture fluide et continue.

Notre CDN dispose d’un large éventail de fonctionnalités qui nous permettent de maximiser le déchargement à l’origine et d’améliorer l’expérience de l’utilisateur final avant, pendant et après la fin du processus de remplissage du cache.

Optimisations du cache de diffusion en direct

Comme le montre le graphique ci-dessous, notre plate-forme multimédia utilise une série d’optimisations réglables pour obtenir une diffusion rapide et fiable pour le streaming en direct. Dans les sections suivantes, nous expliquerons pourquoi ils sont importants et comment ils fonctionnent.

Bouclier d’origine

Tout d’abord, Origin Shield est une couche de cache supplémentaire entre les serveurs périphériques CDN et l’origine. Nous créons une origine virtuelle dans l’un des POP qui, à son tour, gère toutes les requêtes de tous les autres emplacements POP. Lorsqu’un serveur périphérique CDN reçoit une requête d’un utilisateur et ne peut pas satisfaire la requête du cache, le serveur périphérique récupère l’objet à partir du pop de bouclier plutôt que de l’extraire directement de l’origine du client. En tant que CDN mondial, nous offrons à nos clients la possibilité d’attribuer un point de vente unique comme bouclier ou un point de vente bouclier par région (États-Unis, UE, Asie, etc.).

Origin Shield nous aide à protéger le serveur d’origine en cas de pics de trafic importants et de foules flash. Cependant, il peut ne pas être suffisant de traiter le profil de trafic unique de la diffusion en direct.

Partage partiel du cache

En streaming en direct, un modèle typique est que plusieurs clients demandent un segment du flux qui n’est pas encore dans le cache. Un CDN peut traiter ces demandes de plusieurs façons. Tout d’abord, il peut envoyer plusieurs demandes de remplissage de cache simultanées à l’origine (une par demande de chaque nouveau client), ce qui permet de minimiser la latence et d’optimiser l’expérience de l’utilisateur final. Une deuxième option consiste à envoyer une seule requête de remplissage du cache qui dessert le premier client sans délai mais qui maintient les autres en attente jusqu’à ce que le fichier complet soit chargé dans le cache (cette méthode vise à minimiser la charge sur l’origine).

Malheureusement, aucune de ces options ne représente une solution particulièrement intéressante.

Au lieu de cela, notre approche établit un équilibre entre ces deux options en permettant à un seul remplissage de cache déjà en vol d’être partagé entre plusieurs clients demandant le même contenu déjà partiellement dans le cache. Le partage partiel du cache permet à d’autres clients de se désolidariser d’un remplissage de cache préexistant, de sorte que le contenu vidéo peut être livré à plusieurs clients simultanément dès qu’il commence à se charger dans le cache. Résultat : des temps de démarrage plus rapides, une latence plus faible et une charge d’origine réduite.

Temps d’attente de remplissage du cache

Il y a un intervalle entre le moment où le client demande le fichier vidéo et le moment où il commence à se charger dans le CDN POP. Ce moment dans le temps est très petit (cela peut arriver en quelques millisecondes seulement), mais la foule du flash streaming en fait un défi très important car il pourrait être composé de centaines, voire de milliers de requêtes. Dans ce cas, la fonctionnalité de partage partiel du cache décrite ci-dessus n’aurait pas encore démarré. Généralement, cela est considéré comme un cas d’angle, mais il est plus probable que cela se produise avec le streaming en direct en raison des foules flash. À ce moment critique, le CDN pourrait submerger l’origine en transmettant trop de requêtes à la fois.

Plusieurs requêtes pour le même fichier sont regroupées pour éviter ce problème, et une seule requête est envoyée à l’origine. Cache Fill Wait Time est une salle d’attente virtuelle pour améliorer le déchargement à l’origine et faire face aux foules flash. Lorsque les en-têtes de réponse HTTP de la requête unique arrivent et que cette requête commence à recevoir le fichier de l’origine, le cache peut alors être partagé avec tous les utilisateurs groupés en attente. Le « temps d’attente » réel (millisecondes) est hautement configurable et peut être affiné en fonction des capacités d’origine spécifiques et des besoins du client.

Spawn sous-demande pour Miss

Lorsque plusieurs utilisateurs demandent le même contenu non mis en cache, comme indiqué ci-dessus, il y a un risque que le premier client soit sur un appareil lent, comme un smartphone sur une connexion 3G. Cela nuit à tous les autres clients car un cache se remplit normalement à la vitesse à laquelle le client peut absorber le contenu. Pour éviter ce scénario, nous pouvons découpler le remplissage de notre cache du premier client potentiellement lent/défaillant et le remplir de l’origine plus rapidement (à notre vitesse maximale). Cette fonctionnalité est également plus fiable car maintenant le remplissage du cache continue même si le client initial se déconnecte ou si quelque chose provoque l’interruption de la connexion. Nous décrivons ce comportement comme une sous-requête spawn pour Miss. Cette fonctionnalité déclenche également un remplissage du cache pour l’ensemble du contenu, satisfaisant différentes requêtes de plage d’octets avec un seul trajet vers le serveur d’origine. Spawn Sub-Request for Miss et cache Fill Wait Time se complètent dans leur utilisation, travaillant ensemble pour accélérer le streaming en direct et améliorer les mesures telles que le temps de démarrage et de remise en mémoire tampon de la vidéo.

Autres optimisations CDN de diffusion en direct

Classement à chaud
Alors que le nombre de téléspectateurs d’un flux en direct augmente rapidement, les serveurs de cache qui géraient facilement la charge des téléspectateurs 500k sont soudainement submergés lorsque le nombre de téléspectateurs triple ou quadruple en quelques minutes. En outre, les téléspectateurs peuvent être concentrés autour d’une zone géographique spécifique, généralement pour un événement sportif ou politique populaire. Pour de nombreuses diffusions sportives en direct ou championnats, la concentration des téléspectateurs est susceptible d’être considérablement plus élevée dans les marchés entourant les équipes participantes.

Lorsque cela se produit, les segments de flux en direct doivent être rapidement répliqués sur d’autres serveurs au sein des POP affectés pour aider à répartir la charge.

Le Hot Filing est le processus de détection et de réplication automatiques de contenus extrêmement populaires, tels que des segments de flux en direct, vers plusieurs serveurs de cache en un seul pop pour répondre à une forte demande. C’est une pratique courante parmi les réseaux de diffusion de contenu, mais la vitesse à laquelle ces propagations peuvent se produire compte en fin de compte. Il s’agit d’un domaine d’intérêt permanent pour Edgio. Nous avons récemment abaissé notre vitesse de réplication de 5 secondes à environ 1–2 secondes. En plus des flux en direct, nous pouvons également faire d’autres contenus chauds, tels que des publicités, dans un flux en direct.

Capacité et bande passante
La capacité et la bande passante font référence à la capacité supplémentaire sur le TAP pour répondre aux demandes imprévisibles des flux en direct. Tout comme il n’y a pas de substitut pour les pouces cubes pour les voitures musculaires, il n’y a pas de substitut pour la bande passante avec les CDN. Pour mettre en jeu ces stratégies et d’autres stratégies d’optimisation du cache, il faut que le réseau dispose de la capacité et de la bande passante nécessaires pour gérer le streaming en direct à grande échelle tout en équilibrant la charge que les autres utilisateurs y ont placée.

Actuellement, plus de 80 % du contenu de notre réseau est de la vidéo, et une bonne partie de ce trafic est consacrée aux flux en direct. Nous avons livré plus de 125 000 événements en direct gérés sur notre réseau. Et alors que la qualité du contenu continue de s’améliorer avec la popularité croissante des flux en direct, nous sommes sur la bonne voie pour atteindre 100 Tbps de capacité réseau d’ici la fin de 2019. Notre réseau comprend plus de 140 pop mondiaux et 5 000 interconnexions ou connexions du dernier kilomètre.

Tout fonctionne ensemble

Les lourdes exigences du streaming en direct pousseront votre technologie à ses limites. La fourniture d’un flux fluide à des milliers, voire des millions, nécessite des configurations de mise en cache spéciales. La combinaison de Origin Shield, partage partiel de cache, temps d’attente de remplissage de cache, Spawn Sub Request for Miss et Hot Filing sont des fonctionnalités puissantes qui peuvent être adaptées à votre infrastructure et à vos exigences de streaming en direct uniques. Ils permettent à notre CDN de fournir les meilleures performances possibles pour les événements de streaming en direct, que l’objet soit déjà dans le cache, qu’il ne soit que partiellement dans le cache, ou que le remplissage du cache n’ait pas encore commencé et soit toujours en attente et même dans la situation où la demande se trouve être vraiment la demande du premier client pour un élément de contenu unique.

Le CDN est un composant essentiel de l’infrastructure vidéo en direct. Son système de serveur distribué fournit du contenu à vos utilisateurs car il prend en compte à la fois les emplacements géographiques et réseau et l’origine elle-même pour fournir du contenu de la manière la plus rapide et la plus fiable possible. Cependant, les techniques d’optimisation du CDN pour la diffusion en direct diffèrent considérablement des autres applications qui bénéficient également d’un CDN, y compris la vidéo à la demande (VOD). Avec les bonnes optimisations de cache et une grande marge de manœuvre, le CDN est plus que capable de faire face aux fluctuations et à la variabilité inhérentes au streaming en direct.

Notre CDN offre des capacités de distribution de contenu éprouvées et des optimisations qui minimisent la charge sur le serveur d’origine tout en diffusant des flux en direct aux spectateurs à grande échelle. Nos optimisations de la mise en cache vidéo en direct, dont beaucoup sont réglables pour les clients individuels, fonctionnent ensemble pour protéger les demandes des spectateurs contre l’écrasement de votre infrastructure vidéo.