La foule Flash et votre diffusion en direct
Alors que les services de streaming se battent pour un nombre limité de téléspectateurs et que la portée de l’attention diminue, les événements en direct, qui sont un moteur avéré 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 fournir des audiences de manière fiable, le streaming fiable d’événements en direct à grande échelle présente 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. Le défi le plus évident du streaming en direct est peut-être la « foule éclair » — ce phénomène se produit lorsque de nombreux téléspectateurs entrent en streaming en direct à la fois — avides d’attraper le coup d’envoi ou les 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 6 de la finale de la NBA, le public a rapidement augmenté, passant de presque rien au tipoff à un pic de 2,04 millions de téléspectateurs au 3ème trimestre. L’audience est passée de moins de 10 000 sessions à plus d’un million dans la première heure et à 1,5 millions après la mi-temps, ajoutant parfois plus de 100 000 nouveaux 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 perturbation peut entraîner une interruption de la lecture.
Comme l’illustre cet exemple d’un récent événement en direct sur notre réseau, le phénomène de « 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 examinons les foules éclair et d’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 pour nos clients, ce qui en fait le bon choix pour offrir des événements live de haute qualité – qu’il s’agisse de sports, concerts, 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 de 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 des CDN pour distribuer le contenu à grande échelle.
Notre vaste CDN mondial chez Verizon Media, aujourd’hui Edgio, a de nombreux POP et 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 éclair. 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 distinctement différent de tout autre profil, 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 sur 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 traiter 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 média. Les utilisateurs finaux côté client bénéficient ainsi d’une lecture fluide et continue.
Notre CDN dispose d’un large éventail de fonctionnalités qui nous permettent de maximiser le déchargement d’origine et d’améliorer l’expérience de l’utilisateur final avant, pendant et après la fin d’un 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.
Protection 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 Shield 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 une seule POP comme bouclier ou une POP 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 éclair. Cependant, il peut ne pas suffire de traiter le profil de trafic unique du streaming 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 de cache qui dessert le premier client sans délai mais garde 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 élément de contenu déjà partiellement dans le cache. Le partage partiel du cache permet à d’autres clients de regrouper un remplissage de cache préexistant, de sorte que le contenu vidéo peut être distribué à plusieurs clients simultanément dès qu’il commence à 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 à charger dans le pop CDN. Ce point dans le temps est très petit (cela peut arriver en quelques millisecondes seulement), mais la foule flash en 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 de coin, mais il est plus probable que cela se produise avec le streaming en direct en raison des foules éclair. À 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. Le temps d’attente de remplissage du cache est une salle d’attente virtuelle destinée à améliorer le déchargement d’origine et à faire face aux surchargements Flash. Lorsque les en-têtes de réponse HTTP pour 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 en pool en attente. Le « temps d’attente » réel (millisecondes) est hautement configurable et peut être ajusté 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 se trouve 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 à partir 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-demande de spawn pour Miss. Cette fonctionnalité déclenche également un remplissage du cache pour l’ensemble du contenu, satisfaisant différentes demandes de plage d’octets avec un seul voyage vers le serveur d’origine. Spawn Sub-Request for Miss et cache Fill Wait Time se complètent mutuellement dans leur utilisation, travaillant ensemble pour accélérer le streaming en direct et améliorer les métriques telles que le temps de démarrage de la vidéo et la remise en mémoire tampon.
Autres optimisations CDN de streaming en direct
Dépôt à chaud
Comme le nombre de spectateurs d’un flux en direct augmente rapidement, les serveurs de cache qui auparavant géraient facilement la charge à 500 000 spectateurs sont soudainement dépassés lorsque le nombre de spectateurs triple ou quadruple en quelques minutes. De plus, 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 émissions sportives en direct ou des 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 impactés pour aider à répartir la charge.
Le Hot Filing est le processus de détection et de réplication automatiques de contenu extrêmement populaire, comme des segments de flux en direct, sur plusieurs serveurs de cache dans un POP pour répondre à une forte demande. Il s’agit d’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 réduit notre vitesse de réplication de 5 secondes à environ 1–2 secondes. En plus des diffusions en direct, nous pouvons également rendre chaud d’autres contenus, 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 au robinet pour répondre aux demandes imprévisibles des flux en direct. Tout comme il n’y a pas de substitut aux pouces cubes pour les voitures musculaires, il n’y a pas de substitut à la bande passante avec les CDN. La mise en œuvre de ces stratégies et d’autres stratégies d’optimisation du cache nécessite 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 lui placent.
Actuellement, plus de 80 % du contenu de notre réseau est de la vidéo, une bonne partie de ce trafic étant consacrée aux flux en direct. Nous avons diffusé 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 en même temps que la popularité croissante des diffusions en direct, nous sommes en bonne voie d’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 à la limite. Fournir 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 du cache, temps d’attente de remplissage du cache, Spawn Sub Request for Miss et Hot Filing sont des fonctionnalités puissantes qui peuvent être adaptées à votre infrastructure et à vos exigences uniques de streaming en direct. 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 le cas 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 le contenu de la manière la plus rapide et la plus fiable possible. Cependant, les techniques pour optimiser le 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 beaucoup de marge de manœuvre, le CDN est plus que à la hauteur des fluctuations et de 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 fournissant des flux en direct aux téléspectateurs à grande échelle. Nos optimisations de mise en cache vidéo en direct, dont la plupart sont réglables pour les clients individuels, fonctionnent ensemble pour protéger les demandes des spectateurs contre la surcharge de votre infrastructure vidéo.
