La qualité du streaming vidéo dépend de millions de choses qui vont bien, comme la gestion d’une charge de travail fluctuante en permanence ou la gestion de « foules éclair » lorsque de nombreux téléspectateurs entrent dans un flux en même temps. C’est pourquoi fournir un flux vidéo fiable et de haute qualité dans le cadre d’un service payant – où les téléspectateurs s’attendent à une expérience semblable à celle de la télévision – nécessite des outils et des mesures pour articuler avec précision les défis de performance afin que vous puissiez savoir où et comment résoudre les problèmes.
Les CDN sont une solution indispensable en streaming vidéo car ils offrent une évolutivité à faible latence à la demande dans le monde entier. En plus des optimisations qui améliorent la façon, le CDN équilibre la croissance chaotique de l’audience qui peut accompagner un flux en direct, offrant de grandes performances à l’utilisateur final nécessite une couche supplémentaire de visibilité, de mesures, d’outils et d’automatisation.
Dans cet article, nous examinerons des exemples d’optimisations récentes des performances que nous avons faites pour un grand service de streaming vMVPD nord-américain, notamment :
- Mesures que nous utilisons pour améliorer/résoudre les problèmes de performances
- Comment définir la performance et comment la mesurer
- Optimisations continues que nous prenons pour améliorer les performances vidéo
Numéros de systèmes autonomes : la complexité derrière le rideau
Le Web moderne est construit autour de plusieurs couches interconnectées de réseaux appelés ASN (numéros de système autonomes), chacune composée de grands groupes d’adresses IP couplées à des CDN (réseaux de diffusion de contenu) qui réduisent la congestion en rendant le contenu disponible à la périphérie. Essentiellement, comme on le verra ci-dessous, Internet consiste en un réseau de réseaux, chacun ayant son modèle d’affaires et ses priorités uniques.
Source : Research Gate
Associée à la complexité inhérente des ASN qui interagissent les uns avec les autres, leur portée et leur échelle sont à elles seules. L’outil vizAS tente de visualiser les interconnexions entre les nombreux ASN pays par pays. Par exemple, rien qu’aux États-Unis, il existe 16 979 ASN et 24 905 relations de peering sur les réseaux. Dans le monde, il existe plus de 90 000 ASN.
https://stats.apnic.net/vizas/index.html
De notre point de vue en tant que fournisseur de CDN, la complexité liée à la connexion à des milliers d’ASN est aggravée par la nécessité de répondre aux exigences de performance de chaque client, au profil d’utilisation, au type de trafic et à de nombreux autres facteurs. Par exemple, un service comme Twitter aura un profil d’utilisation ou une empreinte bien différente de celle d’une société de jeux qui proposera une mise à jour majeure. De même, un radiodiffuseur diffusant en continu un événement sportif en direct a un profil différent d’un service de diffusion en continu à la demande. Même deux services de streaming en direct ont probablement des profils différents, chacun nécessitant une optimisation des performances personnalisée.
En coulisses, nous disposons d’un grand nombre de paramètres de configuration que nous pouvons ajuster et ajuster pour aider les clients à atteindre leurs objectifs et leurs exigences en matière de performances. Pour certains, la performance peut être ce qu’ils attendaient (ou mieux) du départ, et nous n’avons pas besoin de changer quoi que ce soit. D’autres peuvent avoir des objectifs spécifiques, tels que le TTFB (Time to First Byte) plus rapide, une mesure importante pour les services de streaming, qui doivent être pris en compte.
Compte tenu de la complexité et de la taille d’Internet, il est impossible de fournir des améliorations de performance utiles et cohérentes grâce à des approches « whack-a-mole » ou scattershot. Les gains réels proviennent de la collecte de données complète et de l’analyse intensive des données pour identifier la cause profonde d’un problème ou obtenir de manière proactive un aperçu des changements de configuration du réseau qui profiteront le plus à un client.
Fournir des informations RTT avec Stargazer
L’un des indicateurs les plus importants pour déterminer la latence du réseau et l’intégrité des performances globales est le temps d’aller-retour (RTT). Il s’agit de la durée, mesurée en millisecondes, qu’il faut à un paquet pour voyager de la source à la destination et qu’une réponse soit renvoyée à la source. Il peut être utilisé pour diagnostiquer et améliorer les performances du réseau sur plusieurs vecteurs, y compris la congestion, les problèmes matériels, les erreurs de configuration et les problèmes de routage.
Compte tenu de l’importance de cette métrique, nous avons construit un système interne appelé Stargazer que nous utilisons pour agréger les données RTT provenant de diverses sources, y compris nos capteurs, les données que nous importons de clients et les tiers qui surveillent également les informations RTT. Stargazer surveille les temps de réponse sortants vers le client. D’autres sources de données peuvent inclure les tables BGP (Border Gateway Protocol) des routeurs, le mappage des routeurs vers des emplacements géographiques, les journaux RTT pour les connexions des clients et les informations sur le volume du trafic. En outre, le système peut effectuer des sondes actives telles que des traceroutes et des ping si nécessaire.
Derrière l’activité de monitoring, Stargazer, en conjonction avec d’autres outils que nous avons développés, nous permet d’interroger toutes les données que nous avons collectées et d’effectuer une analyse approfondie qui ouvre la voie à des améliorations continues. Nos administrateurs réseau peuvent utiliser ces informations pour isoler les problèmes et identifier les routes ou les configurations réseau afin d’optimiser les performances en fonction des objectifs et des exigences spécifiques des clients. Et, comme nous le verrons plus loin, il est également utile pour comprendre l’effet des nouvelles technologies, telles que le protocole BBR (bande passante de goulot d’étranglement et temps de propagation aller-retour), sur les performances.
Optimisation d’un serveur d’origine
Pour mieux comprendre comment fonctionne l’optimisation des performances en pratique, examinons un exemple impliquant un client de streaming vidéo en direct récemment ajouté qui avait besoin d’optimiser pour une architecture multi-CDN . Dans une architecture client CDN traditionnelle, le client fait une requête à l’un de nos POP, et le cache POP se remplit à partir de l’origine, comme indiqué ci-dessous.
Cependant, ce client a choisi de tirer parti d’une architecture multi-CDN pour augmenter la redondance et la résilience et potentiellement augmenter les performances. Ceci est rendu possible par notre architecture Origin Shield illustrée à la figure 4. Origin Shield offre plus de contrôle sur la façon dont le trafic des différents clients peut être acheminé pour les meilleures performances.
Contrairement à une relation CDN traditionnelle, tout le trafic, y compris celui desservi par le deuxième CDN, retourne à l’un de nos POP (AGA) situé à Atlanta pour remplir le cache. L’AGA POP sert alors d’origine, ou plus précisément, ce que l’on appelle le bouclier d’origine, allégeant ainsi la charge considérable du serveur d’origine du client. L’AGA POP a été choisi comme emplacement du bouclier d’origine en raison de son taux de cache-hit plus élevé et de ses performances que le deuxième CDN. Une préoccupation majeure, cependant, était l’optimisation des performances entre les deux CDN.
La première étape du processus consistait à envisager d’optimiser les itinéraires empruntés par le deuxième CDN vers AGA, en faisant office de bouclier d’origine. L’un des problèmes immédiatement apparus était une mauvaise performance entre les CDN et un nombre élevé de délais de connexion impactant le TTFB. Pour creuser dans les problèmes de performance, nous avons utilisé Stargazer pour envoyer un traceroute de AGA à la destination prévue et capturer les ASN utilisés pour chaque saut.
Comme indiqué dans le résumé ci-dessous, un traceroute a été envoyé de AGA à une adresse IP sur le deuxième CDN, simulant le chemin du client.
Nous avons remarqué que plusieurs houblons se trouvaient dans l’ASN 7018, qui n’était pas la route préférée car elle impliquait plus de houblons et avait plus de congestion. En utilisant Stargazer, nous avons rapidement confirmé le problème et apporté les modifications appropriées au réseau. Comme le montre le résumé traceroute ci-dessous, après avoir effectué le changement de réseau, nous avons diminué le nombre de sauts et amélioré RTT en passant à ASN 7922, ce qui a également résolu le problème des délais d’attente TTFB.
Dans un autre exemple, nous avons utilisé l’outil Stargazer pour déterminer le meilleur chemin de bouclier d’origine vers le serveur d’origine d’un client situé sur la côte est. Pour réduire efficacement la charge sur le point d’origine d’un client et améliorer les performances de livraison, le point d’ancrage du bouclier d’origine doit être proche du point d’origine. Parfois, ce n’est pas nécessairement la pop physique la plus proche qui fonctionne le mieux. C’est une combinaison du moins d’ASN, du moins de congestion et de temps de RTT faibles. Comme vous pouvez le voir dans le graphique avant et après ci-dessous, un traceroute Stargazer a montré que le passage de la pop NYA (New York) à la pop DCC (Washington, DC) a réduit le nombre de sauts à trois, entraînant une amélioration globale de la performance du RTT.
Analyse plus approfondie avec Sweeper Fish
Avec plus de 7 000 interconnexions et plus de 300 POP dans notre CDN à l’échelle mondiale, il y a beaucoup de travail d’optimisation en cours. Pour éviter de tourner la roue sur des tâches qui ne font peut-être pas beaucoup de différence, nous avions besoin d’un moyen efficace de prioriser les actions entreprises par nos équipes opérationnelles. Ce besoin a conduit au développement d’un outil compagnon de Stargazer appelé Sweeper Fish qui évalue les endroits où les problèmes existent et nous permet de les buller de manière hiérarchisée.
Sweeper Fish est également utile pour déterminer si une route est encombrée et si elle est susceptible de causer des problèmes. Revenons à l’exemple multi-CDN, nous avons utilisé Sweeper Fish pour découvrir quelles routes étaient encombrées. Pour ce faire, Sweeper Fish a mesuré le delta entre le 25e et le 75e percentile pour les données RUM (Real User Measurement) pour tous les clients sur tous les chemins vers le POP AGA, en se concentrant sur le chemin du deuxième CDN vers nous, ASN7922. L’écart-type pour tout le trafic sur cet ASN est indiqué ci-dessous.
Nous avons également confirmé que la configuration précédente via ASN7018 n’était pas la solution. L’analyse de Sweeper Fish a montré que l’IQR (interquartile Range) a atteint un pic de 20-60 à millisecondes (voir figure 9) en raison de la congestion sur cette route. L’IQR, également appelé Midspread ou Middle 50%, fournit un moyen utile d’analyser une route et de signaler rapidement les problèmes. Plus l’IQR est bas, mieux c’est.
En revanche, le POP AGA était constamment entre 10-22 millisecondes sur la route que nous avons fini par utiliser, ASN7922, comme indiqué ci-dessous. En comparant différents ASN, Sweeper Fish nous permet de choisir le meilleur itinéraire le moins encombré et/ou d’identifier les problèmes à résoudre.
Réglage TCP
La congestion entraîne également l’abandon et la retransmission des paquets. Cela se produit lorsque les chemins entre les POP sont distants et que l’algorithme TCP n’est pas optimisé. Puisque AGA était à l’origine de notre exemple, il était possible pour les POP lointains qui ont atteint AGA d’avoir ce problème. Bien que répartis sur de nombreuses fenêtres contextuelles, les journaux CDN agrégés ci-dessous nous ont permis d’identifier les zones problématiques comme indiqué par les cases.
Figure 11. Les journaux de serveur agrégés identifient rapidement les zones problématiques où les paquets sont abandonnés et retransmis.
Évaluation du BBR
La bande passante du goulot d’étranglement et le temps de propagation aller-retour (BBR) est un algorithme de contrôle de congestion TCP alternatif développé par Google qui a commencé à gagner du terrain. Il diffère des algorithmes de contrôle de congestion basés sur les pertes, tels que le TCP-Cubic omniprésent, et introduit un paradigme de fonctionnement différent. Il met à jour en permanence la quantité de données pouvant être en vol en fonction du RTT minimum que la session a vu jusqu’à présent pour éviter le gonflement de la mémoire tampon.
Notre analyse a révélé que BBR est utile pour améliorer les performances de RTT, mais ne constitue pas une solution universelle. Il y a des moments où vous voulez l’utiliser et d’autres fois où vous ne le faites pas. Stargazer nous aide à déterminer quand nous voulons l’utiliser en suivant le profil cohérent des RTT vers les destinations sur des périodes. Cela nous permet de déterminer les meilleurs endroits pour appliquer BBR afin de réduire les retransmissions et d’améliorer le contrôle du flux.
D’après l’analyse présentée dans les tableaux ci-dessous, nous avons conclu que le passage à BBR améliorerait légèrement le rendement du POP AGA vers le deuxième CDN et l’origine du client. Le premier ensemble de graphiques montre que le passage de TCP-Cubic à TCP BBR a entraîné une diminution des retransmissions, tandis que le second ensemble de graphiques indique que le passage à BBR a entraîné une légère augmentation du débit moyen.
Figure 12. Dans cet exemple, le passage de TCP-Cubic à TCP BBR a entraîné une diminution des retransmissions
Figure 13. Dans cet exemple, le passage à BBR pour le contrôle de flux à partir de TCP-Cubic pour AGA POP a réduit les retransmissions et légèrement amélioré le débit moyen.
Conclusion
Internet est vaste et complexe – il s’agit essentiellement d’un réseau de réseaux. Pour Edgecast, aujourd’hui Edgio, l’optimisation des performances pour les cas d’utilisation client serait quasiment impossible sans une analyse approfondie pour mieux cerner les zones problématiques et tester les changements de configuration possibles. Pour améliorer les performances de nos clients, nous avons développé un ensemble robuste d’outils pour surveiller les RTT en permanence afin de pouvoir apporter des améliorations rapides et efficaces à notre réseau. Pour un service de streaming vidéo en direct, nous avons trouvé des moyens d’optimiser les performances pour leurs besoins uniques tout en évaluant l’utilisation de BBR pour leur application. Le résultat a été une solution de streaming haute performance exploitant deux CDN. Et nous n’en avons pas encore fini. Alors que la congestion du réseau continue d’augmenter, nous ne cesserons jamais d’optimiser notre réseau pour nous assurer que nos clients et leurs clients bénéficient de la meilleure expérience en ligne possible.
