L’amélioration des performances de notre technologie au profit de nos clients et de leurs publics est une ligne d’action permanente chez Verizon Media, aujourd’hui Edgio. Par exemple, au cours des deux dernières années, nos ingénieurs de performance et de noyau ont éliminé pratiquement toutes les pertes de paquets (plus de 98 % éliminées), amélioré les contrôles de santé des performances de nos serveurs périphériques de 50 % et augmenté la capacité des serveurs de 40 %.
Nous avons également couplé ce qui précède à l’automatisation du réseau et à l’expansion organique du réseau — actuellement plus de 250 Tbps — pour améliorer l’expérience utilisateur. Le réglage minutieux de nos performances a joué un rôle majeur dans notre capacité à prendre en charge les pics de surtension du réseau qui évoluent rapidement et parfois imprévisibles, car nous fournissons des mises à jour logicielles pour des millions de consoles de jeux, des flux vidéo en direct pour des événements sportifs majeurs et lorsque les équilibreurs de charge multi-CDN transfèrent la charge vers notre réseau.
Le maintien de la qualité à grande échelle implique l’optimisation des performances sur chaque partie de la pile technologique Edgio Media Platform : des couches inférieures, au niveau du processeur et de la carte réseau, jusqu’au système d’exploitation et aux applications. En fin de compte, notre objectif est toujours le même : une grande performance. Pour y parvenir, nous effectuons une analyse basée sur les données, en nous appuyant sur des changements de performance mesurables pour valider notre prise de décision.
Optimisations du cache CPU
Nous exploitons 20 000 serveurs dans le monde entier, principalement des chipsets Broadwell et Haswell, généralement avec 32 à 40 cœurs. Nous avons ajouté 12 000 serveurs au cours des trois dernières années seulement. Cependant, la plupart des serveurs ne sont pas optimisés pour s’adapter à nos charges de travail prêtes à l’emploi. Le simple ajout de serveurs ne permet pas un fonctionnement plus efficace et peut créer des défis supplémentaires. Une mise à l’échelle efficace nécessite une optimisation minutieuse des composants existants. Le fait de pouvoir optimiser un serveur pour qu’il soit capable de traiter deux ou trois fois (ou plus) les requêtes qu’avec la configuration par défaut peut faire une différence importante sur les performances globales du réseau.
Le passage de l’espionnage précoce à l’espionnage à domicile
Les CPU modernes utilisent un protocole de surveillance pour garantir que le cache CPU local est cohérent avec la mémoire. Cela permet aux caches d’écouter les modifications apportées aux variables sur n’importe quel CPU et de mettre à jour leurs versions de ces variables en conséquence. Sans surprise, la technique particulière utilisée peut avoir un impact significatif sur les performances de la mémoire.
Par défaut, nos fournisseurs de matériel utilisent un protocole appelé Early Snoop. Il a une latence plus faible pour résoudre la cohérence du cache, car tous les cœurs peuvent faire des requêtes de cohérence du cache simultanément et envoyer des diffusions. Nous avons constaté que nos systèmes génèrent de grandes quantités d’activité simultanée du disque et de la carte réseau pendant les scénarios de charge maximale. Ces activités se traduisent par des diffusions espionnes élevées, ce qui entraîne des goulets d’étranglement dans les communications. Cela ralentit le périphérique d’E/S et peut éventuellement entraîner l’arrêt complet du traitement.
En passant au mode Home Snoop, une approche qui fusionne les requêtes Snoop, nous avons constaté une réduction significative du trafic broadcast. L’interconnexion rapide (QPI) du processeur n’est plus réduite pendant les périodes de lourdes opérations simultanées d’E/S disque et réseau ; en outre, les pertes de paquets que nous avons vues avec Early Snoop ont considérablement diminué en nombre.
La modification du protocole Snoop dépend simplement de la modification d’un paramètre du BIOS. Cependant, redémarrer les serveurs 20 000 sans perturber les clients nécessite une automatisation. Nous pouvons faire en sorte que ce type de changement de déploiement à grande échelle fonctionne en production, en partie grâce à notre plateforme d’automatisation INFORMATIQUE basée sur StackStorm, écrevisse.
Un événement de basculement inattendu
Lors du test du passage à Home Snoop, un basculement s’est produit : l’un de nos plus gros clients multimédia, qui a un déploiement multi-CDN , a rencontré un problème avec un autre fournisseur et a déplacé une partie importante de son trafic vers notre CDN. Cela a été l’occasion de tester les améliorations à grande échelle de Home Snoop, qui ont été extrêmement percuteuses.
La figure ci-dessus montre l’effet de la modification. Le groupe qui utilisait encore Early Snoop a vu ses chutes augmenter de 13,75x (55 000 chutes de paquets par serveur et par jour), tandis que le groupe qui était passé à Home Snoop a vu une augmentation de seulement 4,23x (27 000 chutes de paquets par machine et par jour). Home Snoop a immédiatement prouvé sa valeur lors de l’événement de basculement.
Optimisation de l’interface réseau et réglages des pilotes
Un autre ensemble important de réglages de performances impliquait l’interface réseau et le pilote. Ici, nous nous sommes concentrés sur la réduction des pertes de paquets qui se produisent généralement avec le trafic en rafale. Lors d’événements importants, le trafic entrant était si lourd que la carte réseau ne pouvait pas suivre le rythme, et nous avons constaté des pertes de paquets plus tôt que prévu. En expliquant pourquoi, nous avons constaté que plusieurs paramètres de la carte réseau elle-même devaient être ajustés, y compris le nombre de files d’attente, la taille de la file d’attente et la planification des interruptions. Afin d’optimiser ces spécifications pour notre charge de travail et notre configuration matérielle particulières, nous nous sommes concentrés sur l’optimisation du flux RSS (Receive Side Scaling) en allongeant les files d’attente entrantes, en réduisant leur nombre global et en équilibrant les interruptions sur les nœuds NUMA.
Le graphique ci-dessus montre un test que nous avons effectué en Amérique du Nord, dans lequel chaque pop est divisé en un groupe de contrôle (c.-à-d., non réglé) et un groupe de test (c.-à-d., réglé). Ici, nous présentons le nombre de gouttes additionnées quotidiennement sur une semaine. Après les réglages, notre groupe de test a constaté environ 95 % de pertes de paquets en moins que le groupe de contrôle, ce qui a permis de traiter beaucoup plus de demandes. Cela signifie également que moins d’actions sont nécessaires pour gérer manuellement l’intégrité du réseau lors des surtensions, laissant nos ingénieurs libres de se concentrer sur d’autres domaines.
Réglage de la programmation de l’UC
Alors que le réglage au niveau de la carte réseau et du pilote s’est concentré sur l’amélioration de la capacité totale que nous pouvons fournir, les réglages de la planification du processeur se sont concentrés sur l’amélioration de la cohérence de la diffusion du contenu.
Sans ces syntonisations, les messages entrants et sortants doivent rivaliser pour obtenir des ressources. Lorsque nous avons commencé à étudier la cause principale, nous avons constaté que le conflit sur les ressources résultait de la façon dont le noyau planifiait la gestion de ces messages. Cela signifiait que la charge n’était pas migrée pendant les pics de trafic jusqu’à ce que les CPU en question soient saturés. Pour résoudre ce problème, nous définissons l’affinité CPU de nos processus de serveur Web pour exclure les CPU dédiés au traitement du trafic réseau entrant.
Les graphiques ci-dessus illustrent l’impact de l’activation des réglages de planification de CPU à l’échelle mondiale sur le CDN du 21 au 22 mars. Nous évaluons l’impact sur la base du 95e centile et des valeurs médianes d’une métrique de bilan de santé des performances, une métrique composite démontrant le temps de réponse relatif d’un serveur. Comme prévu, les vallées à faible trafic n’ont pas été réduites de manière significative ; cependant, les pics révèlent une réduction significative des contention entre le trafic entrant et sortant. Cela se traduit par une amélioration majeure des valeurs aberrantes et médianes, en particulier pendant les pics de charge. Nous pouvons désormais mieux gérer les pics de trafic et résoudre les problèmes liés aux comportements aberrants élevés, tels que les rebuffers dans les flux vidéo ou la réactivité globale d’un serveur pour tous les utilisateurs.
Mises à jour des performances du noyau
Optimiser les couches supérieures de notre pile technologique est tout aussi important que de régler les éléments de la couche inférieure. Dans le processus de mise à niveau récente de notre système d’exploitation, nous avons également mis à niveau nos noyaux Linux pour tirer parti du travail d’ingénierie en amont de la communauté Linux kernel. Le nouveau noyau a eu environ quatre ans de développement par rapport à la version précédente déployée, y compris des améliorations au système de gestion de la mémoire, ce qui réduit les allocations de pages bloquantes et améliore la répartition de la charge et les performances lors de l’utilisation de l’API epoll et du partage de socket.
Dans le graphique ci-dessus, vous pouvez voir l’effet du processus de mise à niveau de fin novembre à début janvier comme une baisse des bilans de santé des performances du 99e centile. Les améliorations sous-jacentes du noyau ont conduit à une distribution de charge plus uniforme sur tous nos processeurs de requête de serveur Web. Cela a entraîné une baisse substantielle de ces valeurs aberrantes, rendant les demandes adressées à tous nos clients plus fiables.
Les réglages de performance ont un effet significatif
Au cours des deux dernières années, les ajustements système de grande envergure déployés par l’ingénierie des performances et du noyau ont permis d’éliminer pratiquement toutes les pertes de paquets (plus de 98 % éliminées) et de réduire de moitié nos contrôles d’intégrité des performances sur nos serveurs périphériques. La capacité de nos serveurs a augmenté de 10 à 40 % (la quantité exacte varie en fonction du profil du client et de l’événement), ce qui nous permet de livrer plus de trafic plus rapidement. Le comportement des valeurs aberrantes s’est considérablement amélioré, ce qui rend l’expérience plus cohérente, et nous avons constaté une bonne amélioration sur les médianes, en particulier pendant les pics de charge. En résumé, le réglage des performances de l’ensemble de la pile technologique nous a permis de mieux gérer les pics de trafic inattendus (que ce soit à la suite d’une mise à jour très attendue de la console de jeu ou d’un événement populaire de streaming vidéo en direct) et de fournir des performances plus cohérentes pour tous nos utilisateurs.
