Au sein de notre CDN, nous développons continuellement de nouvelles façons innovantes d’aider notre infrastructure à maintenir des performances et une résilience élevées lors d’augmentations soudaines de charge. Cela implique souvent d’explorer les optimisations sur les techniques existantes que nous utilisons. De plus, la validation de nouvelles approches est une partie importante de ce processus, car elle garantit que les nouveaux changements ont les impacts positifs attendus dans les environnements de production.
Lorsque le contenu devient populaire, nous le répliquons sur plusieurs serveurs dans un centre de données/point de présence (POP). Cela nous permet de mieux équilibrer la charge et de gérer de telles surtensions, réduisant ainsi le risque de surcharge des serveurs. Ce mécanisme de réplication est appelé «Hot Filing», et le contenu populaire est appelé un «Hot file». Nous avons récemment développé une optimisation de l’équilibrage de charge adaptatif (ALB) qui améliore notre classement à chaud traditionnel en le rendant plus résistant aux pics de trafic. En particulier, il décide dynamiquement de la quantité de réplication nécessaire en mesurant la charge du serveur au lieu de s’appuyer sur des seuils statiques. Cela répartit la charge de manière plus uniforme sur tous les serveurs d’un POP, augmentant ainsi la capacité globale de traitement des requêtes de tout POP et, par conséquent, du CDN. Notre article précédent sur l’évaluation d’un système d’équilibrage adaptatif de charge détaille les mécanismes de cette optimisation.
Dans cet article, nous validons l’impact positif de cette optimisation en production. Nous commençons par définir les indicateurs que nous avons utilisés pour mesurer l’impact. Ensuite, nous montrons l’impact de l’optimisation sur chacune de ces métriques à travers des exemples. Enfin, nous montrons l’impact global de l’optimisation sur tous les POP où elle a été déployée. En résumé, nous avons constaté que les serveurs de temps totaux ont vu la charge excessive au-delà d’un seuil prédéfini réduite d’au moins 70 %, tandis que presque tous les pop ont vu une amélioration de cette métrique. Cette optimisation est désormais activée globalement pour tout le trafic client.
Définition des métriques
Pour évaluer l’impact de cette nouvelle optimisation en production, nous avons défini et surveillé trois métriques :
- Asymétrie du serveur : il s’agit du rapport entre la charge d’un serveur et la charge médiane de tous les serveurs du POP.
- Nombre de fichiers Hot : il s’agit du nombre de fichiers répliqués par le mécanisme Hot Filing à un moment donné. L’équilibrage adaptatif de la charge devrait augmenter le nombre de fichiers actifs, car le remplissage à chaud est le mécanisme sous-jacent de sa distribution de charge.
- Les serveurs consacrent plus de temps à l’asymétrie cible : cette mesure évalue l’efficacité de l’équilibrage adaptatif de la charge. Lorsque nous définissons notre seuil d’asymétrie cible à une valeur particulière, nous voulons voir que l’asymétrie de la plupart des serveurs est généralement inférieure à cette valeur.
Impact de l’optimisation sur les métriques surveillées
ATTEINDRE L’ÉCART CIBLE
La figure ci-dessous montre deux instantanés de la répartition de la charge des serveurs dans un POP. Sur la gauche (sans Adaptive Load Balancing), nous voyons un nombre de serveurs qui dépassent la cible d’asymétrie (encadré rouge) avec leur charge supérieure à 1,8 fois la médiane du pop. Sur la droite (avec Adaptive Load Balancing), nous voyons un meilleur équilibre entre les serveurs, aucun serveur ne présentant une charge supérieure à 1,8 fois la médiane.
Modification de la répartition de la charge avec l’équilibrage adaptatif de la charge. Nous remarquons une réduction des serveurs surchargés.
NOMBRE DE FICHIERS ACTIFS ET RÉPARTITION DE LA CHARGE
Ensuite, nous avons examiné l’impact du nombre de fichiers actifs et les modifications correspondantes de la charge sur chaque serveur. Le graphique ci-dessous montre que le nombre de fichiers actifs a augmenté lorsque ALB a été activé sur un POP. Ce comportement était attendu car le mécanisme augmente de manière sélective les chances que les fichiers soient déchargés des serveurs avec une charge plus élevée.
Fondamentalement, l’archivage à chaud et l’ALB réduisent la charge sur les serveurs individuels en augmentant le nombre de serveurs qui traitent des fichiers particuliers. Cela augmente la charge de stockage sur chaque serveur. Cependant, les fichiers supplémentaires choisis pour être répliqués à un moment donné sont relativement faibles par rapport au nombre total de fichiers servis à partir du POP, car ils sont sélectionnés uniquement à partir de serveurs aberrants qui nécessitent un déchargement. Dans la plupart des cas, l’espace de cache supplémentaire utilisé est très petit par rapport à l’espace disque total. Par conséquent, le compromis est utile mais important à identifier et à connaître. Dans notre implémentation, nous avons inclus des vérifications de sécurité pour valider que l’utilisation du cache n’est pas affectée négativement par cette optimisation.
Nombre de fichiers actifs. Ce nombre augmente lorsque l’équilibrage de charge adaptatif est activé (marqueur rouge) car les serveurs aberrants tentent d’être déchargés.
Le deuxième graphique montre le volume de trafic fourni par chaque serveur sur la même période à ce pop. Nous avons observé que lorsque l’équilibrage adaptatif de la charge était activé (ligne rouge pointillée), la charge sur les serveurs devenait plus équilibrée. Cela a rendu les serveurs plus résistants au trafic entrant et réduit le risque de surcharge des serveurs.
Répartition de la charge (Mbps) dans un POP entre le 05/02-05/04. Lorsque l’équilibrage adaptatif de la charge est activé, la distribution devient plus fluide, avec un plus grand nombre de serveurs fournissant un trafic plus proche de la médiane. Cela permet d’atténuer le risque que les serveurs soient surchargés par du nouveau trafic.
TEMPS PASSÉ AU-DESSUS DE LA CIBLE SKEWNESS
Ici, nous avons considéré une expérience dans laquelle un pop a été réglé pour maintenir une asymétrie cible de 1.6x. Dans la figure ci-dessous, la ligne orange montre la distribution de « skewness du serveur » sur la période de l’expérience. En comparant cette distribution à la ligne bleue, qui est la distribution respective pour la période de référence (pas d’équilibrage adaptatif de la charge), nous avons observé un déplacement de charge vers la médiane. Notamment, la « queue » de la distribution a également été réduite de manière significative, le 99e percentile étant passé de 2,12 à 1,52, en dessous de l’asymétrie cible.
Adaptive Load Balancing diminue la charge maximale du serveur et rapproche les charges du serveur de la médiane.
Réduire cette « queue » dans la distribution est l’objectif principal de l’optimisation puisque les serveurs dans cette queue, c’est-à-dire ceux qui ont la charge la plus élevée, courent un plus grand risque d’être surchargés par de nouveaux pics de trafic. Pour mieux quantifier cette réduction, nous avons également mesuré le nombre de minutes pendant lesquelles un serveur a fourni du trafic sur la cible pendant les périodes d’expérience avec/sans équilibrage adaptatif de la charge :
Adaptive Load Balancing réduit le temps passé par les serveurs à livrer une charge au-delà d’un seuil cible.
Dans ce cas, nous avons observé une réduction de 88 % du temps passé par rapport à l’asymétrie cible dans ce pop. C’est un bon indicateur que l’équilibrage de charge adaptatif peut maintenir l’asymétrie de la distribution de charge autour de la valeur souhaitée.
Résultats du déploiement mondial
Après avoir testé l’optimisation sur une poignée de POP sélectionnés et avoir constaté de bons résultats sur les métriques mesurées, nous avons déployé le système sur chaque POP pour quantifier l’impact agrégé au fil du temps. Comme précédemment, nous avons mesuré le nombre de minutes collectives de serveurs dans un pop passées à livrer le trafic au-dessus de notre asymétrie cible spécifiée (définie sur 1,8 x la charge médiane du serveur dans un pop). Le graphique suivant montre deux distributions de minutes passées par les serveurs au-delà de ce seuil pour 75 pop. La ligne bleue correspond à 4 jours de données de référence et la ligne orange à 4 jours de données d’équilibrage adaptatif de la charge. Le décalage global de la distribution vers la gauche montre que les serveurs des fenêtres contextuelles exécutant l’équilibrage de charge adaptatif ont passé moins de minutes au-dessus du seuil.
Minutes cumulées passées par les serveurs à livrer une charge supérieure au seuil spécifié (1,8 * médiane) sur 4 jours pour tous les pop. Avec Adaptive Load Balancing, la distribution est décalée vers la gauche, montrant que le mécanisme maintient les charges du serveur en dessous de la déviation cible par rapport à la médiane pendant de longues périodes.
Pour mieux comprendre les impacts sur les POP individuels, nous avons également enregistré le changement en pourcentage de cette mesure pour chaque POP. Les résultats ont montré que la moitié des POP ont vu une réduction de 70 à 95% du nombre total de serveurs de temps au-dessus de la cible asymétrie, et presque tous les POP ont vu une réduction du temps passé au-dessus du seuil.
Dans le cadre de nos efforts continus visant à améliorer continuellement les performances et la fiabilité de notre CDN, nous avons récemment déployé et évalué une optimisation de la façon dont nous équilibrons la charge du trafic au sein d’un POP. Cette optimisation identifie les serveurs chargés au-delà d’un seuil spécifié par rapport au reste du POP et décharge ces serveurs, atténuant notamment le risque d’impact sur les performances en cas de nouveaux pics de trafic. Les résultats de la production démontrent des améliorations significatives qui ont été cohérentes avec les résultats de simulation précédents en montrant l’efficacité de l’optimisation à maintenir la distribution de la charge du serveur dans une asymétrie souhaitée. Par conséquent, nous avons désormais activé cette optimisation à l’échelle mondiale pour l’ensemble du trafic client.
Remerciements particuliers à Angela Chen pour son travail sur la mise en œuvre et le déploiement de ce mécanisme. Merci aussi à Scott Yeager, Derek Shiell, Marcel Flores, Anant Shah et Reed Morrison pour leur aide dans les discussions générales, Colin Rasor, Richard Rymer et Olexandr Rybak pour leur aide dans la collecte et la visualisation des données.