Alors que les volumes de trafic fournis par notre CDN continuent d’augmenter, nous continuons d’étendre l’empreinte de notre CDN en termes de nombre et de taille de points de présence (POP). À mesure que la taille des POP augmente, il est important de répartir la charge sur leurs serveurs afin de maintenir leur santé et leur stabilité et de garantir la résilience aux pics de trafic éphémères.
Système d’équilibrage de charge de courant
Les requêtes arrivant à un POP sont équilibrées en charge vers différents serveurs en fonction de l’URI de requête.
Lorsqu’une demande arrive à un POP, un serveur frontal traite la demande et la met en correspondance avec un serveur cache en fonction de l’URI demandé. Le hachage cohérent (ou, pour être plus précis, le hachage Rendezvous réalisé à l’aide du protocole CARP -cache Array Routing Protocol) garantit que la même ressource sera toujours mappée sur le même serveur cache tant que ce serveur est sain. Cette cartographie cohérente est cruciale pour la performance. L’envoi d’une requête à un serveur qui ne possède pas la ressource demandée dans son cache nécessitera l’extraction de la ressource à partir d’un autre serveur, ce qui augmentera la latence de réponse. Il est important de noter que le hachage cohérent permet également une distribution assez uniforme des ressources sur tous les serveurs de cache du POP, ce qui contribue à répartir la charge de travail.
Cependant, les différentes ressources varient en popularité, et un serveur qui sert une ressource populaire peut finir par servir beaucoup plus de trafic que d’autres dans la pop. Pour cette raison, un mécanisme appelé Hot Filing entre en jeu lorsqu’une ressource devient rapidement très populaire et commence à utiliser une fraction considérable des ressources réseau ou CPU d’un serveur. Hot Filing réplique rapidement cette ressource sur un ou plusieurs serveurs supplémentaires. Il informe les frontaux des serveurs sur lesquels se trouvent les répliques, ce qui se traduit par une répartition plus large de la charge générée par les ressources.
Possibilité d’amélioration
La logique qui déclenche le Hot Filing aujourd’hui est basée sur des seuils fixes qui garantissent qu’aucune ressource unique n’est responsable de plus d’un débit prédéterminé de requêtes ou d’octets servis par un serveur. Si une charge de ressource dépasse ce seuil, elle est distribuée davantage. Cependant, un défi avec des seuils fixes est que si une fraction considérable de la charge d’un serveur sur un serveur est générée par des ressources juste en dessous de ce seuil, ces ressources ne seront pas Hot Filed. Ainsi, leur chargement de requête respectif ne sera pas distribué.
Pour cette raison, nous avons observé que même avec la combinaison de l’équilibrage de charge basé sur les ressources et du Hot Filing, la répartition de la charge entre les serveurs d’un POP peut souvent être inégale, certains serveurs fournissant plus de 2 à 3 fois la charge médiane.
La répartition inégale de la charge réseau est courante dans de nombreux pop à tout moment, avec certains serveurs fournissant jusqu’à 2 fois plus de trafic que la moyenne.
Cette inégalité n’est pas toujours un problème car les serveurs peuvent rester performants tant qu’ils n’atteignent pas leur capacité. Cependant, dans des cas extrêmes, l’impact peut être très apparent. La figure suivante illustre un exemple réel de cet effet.
Deux serveurs atteignent ou dépassent leur capacité réseau, tandis que le reste du POP fournit des volumes de trafic plus faibles. Les serveurs aberrants subissent une inflation évidente sur les bilans de santé (temps de réponse).
Dans cet instantané de la répartition de la charge réseau à un point de vente particulier, alors que la plupart des serveurs envoient de faibles volumes de trafic, deux serveurs servent plus de 2 fois la charge médiane, atteignant leur capacité grâce à une ou quelques ressources très populaires. Cela a un impact observable sur leur métrique de bilan de santé, une approximation de leur temps de réponse minimum. Les valeurs saines de cette mesure sont généralement inférieures à 1 ms et des alertes sont émises lorsqu’elles dépassent 10 ms. Dans cet exemple, le bilan de santé a augmenté à des valeurs supérieures à 100 ms et a persisté pendant au moins une heure, au cours de laquelle les serveurs surchargés ont probablement mal fonctionné.
Nous avons également observé des cas où quelques serveurs sont constamment plus chargés que le reste du POP pendant plusieurs jours. Pendant ces périodes, ces serveurs chargés sont généralement moins résilients aux pics de trafic entrants que les autres serveurs du POP. Cela est exacerbé pendant les heures de pointe, car leur charge peut atteindre ou dépasser leur capacité, bien qu’il y ait une capacité disponible dans le reste du POP.
SYSTEME adaptatif d’Equilibrage de charge de demande
Sur la base de ces observations, nous avons étudié l’idée du Hot Filing avec des seuils dynamiques. Cette approche tient compte de la répartition de la charge entre les serveurs à un moment donné et de l’emplacement de chaque serveur dans cette répartition. Sur la base de ces conditions, un seuil spécifique au serveur est calculé en fonction de la place du serveur dans la répartition de la charge : un serveur dont la charge est supérieure à la médiane se voit attribuer un seuil inférieur à celui d’un serveur dont la charge est inférieure, ce qui favorise un déchargement plus important pour les serveurs en queue de distribution.
Les seuils de serveur sont générés en fonction de l’emplacement actuel de répartition de la charge de chaque serveur. Un serveur dont la charge est supérieure à la médiane se voit attribuer un seuil inférieur à celui d’un serveur dont la charge est inférieure.
Plus précisément, nous définissons deux paramètres qui contrôlent le niveau de Hot Filing :
- BaseThresh contrôle la valeur de référence pour le seuil de chaque serveur. Un seuil spécifique au serveur est dérivé de cette valeur et ajusté pour le serveur en fonction de sa charge actuelle.
- α ∈ (0, 2) contrôle l’agressivité avec laquelle l’algorithme ajuste les poids pour les serveurs nécessitant un déchargement.
Ensuite, pour chaque serveur dans le POP, nous générons un poids W(s) ∈ (0, 2), qui est inversement proportionnel à la charge actuelle du serveur, en utilisant la formule:
Où : α ∈ (0, 1) BW(s) est la charge actuelle du serveur BWmin est la charge la plus faible du serveur BWmin est la charge la plus élevée du serveur alors, le seuil T(s) de chaque serveur est calculé comme suit :
Dans notre implémentation, nous configurons BaseThresh sur une valeur correspondant à nos charges de travail. Nous laissons l’algorithme choisir dynamiquement la valeur de α, de sorte que le déchargement plus agressif est imposé sur les serveurs aberrants (plus chargés) si ces serveurs sont très loin de la médiane en termes de charge.
Évaluation à l’aide des charges de travail de production CDN
Nous évaluons notre approche en simulation, en utilisant des instantanés des charges de travail de production. Pour mesurer la (modification de) asymétrie dans la répartition de la charge sur les serveurs dans un POP, nous définissons le « facteur d’asymétrie » :
En d’autres termes, S mesure la distance entre le serveur le plus chargé et la médiane. Par exemple, S=2 signifie que le serveur le plus chargé fournit 2 fois la charge médiane. Idéalement, nous voulons que tous les serveurs soient proches de la médiane, de sorte que les valeurs inférieures pour S sont meilleures (S=1 étant l’optimal théorique). La figure ci-dessous montre comment S change sur plusieurs itérations du processus de dépôt à chaud en fonction des seuils dynamiques, du nombre de nouveaux fichiers à chaud générés à chaque itération et de la valeur de α sélectionnée à chaque itération.
Distribution de charge après plusieurs itérations dos à dos de l’algorithme. La charge sur les serveurs les plus chargés est réduite de 2,73 x la valeur médiane 1,42 x la valeur médiane, et le trafic au sein du POP devient plus uniformément réparti.
La ligne bleue (« start ») indique l’état de départ, représentant un instantané réel de la répartition de la charge à un POP. Nous notons que S est diminué après chaque itération jusqu’à ce qu’un point où plus de Hot Files (HF) ne soit généré soit atteint. Au fur et à mesure que la queue est ajustée à chaque itération, la distribution devient plus uniforme, avec plus de serveurs plus proches de la charge médiane.
Ensuite, nous répétons la même expérience 10 fois pour 6 POPS différents:
Changement du facteur d’asymétrie (S) pour 6 pop. S converge en 5 itérations, diminuant de 92% en moyenne.
Chaque groupe de barres de la figure représente un pop différent, et chaque barre d’un groupe représente une itération ultérieure. La première barre de chaque groupe représente l’état de départ, tiré des instantanés de charge de travail de production. Chaque barre représente les valeurs de 10 passages. Nous observons que dans tous les cas, la diminution de S est beaucoup plus spectaculaire dans la première itération que dans n’importe laquelle des itérations suivantes où S atteint des valeurs plus acceptables. Fait important, la répartition de la distribution (illustrée par les moustaches), ainsi que les valeurs aberrantes (diamants), sont réduites de la même manière. Nous observons que le mécanisme d’équilibrage de charge converge après un petit nombre d’itérations et n’aurait besoin d’être déclenché que lorsque S devient élevé en raison d’un nouveau trafic déséquilibré.
Étapes suivantes
La répartition de la charge entre les serveurs dans un POP est importante pour les performances. Alors qu’un certain degré d’inégalité est attendu en raison de la popularité rapide des ressources, les serveurs surchargés de manière persistante, malgré la capacité disponible dans le reste de la POP, pourraient affecter leurs performances et leur résilience à davantage de pics de trafic entrant. Dans ce travail, nous avons exploré une amélioration de notre mécanisme d’équilibrage de charge existant, qui peut aider à atténuer ces inégalités de charge.
Les résultats de la simulation étant prometteurs, nous intégrons ce changement dans notre mécanisme existant et surveillons les résultats en production. Tester cette méthode de production nous permettra d’obtenir des résultats plus réalistes et d’évaluer des facteurs supplémentaires plus difficiles à quantifier en simulation. Ces facteurs incluent la résilience aux charges de travail hautement dynamiques, les effets liés à l’heure, les modifications de réplication des ressources et les frais généraux associés.
Explorez notre site Web pour en savoir plus sur la façon dont notre réseau de diffusion de contenu offre de meilleures performances, sécurité et fiabilité.