Une gestion efficace des ressources est essentielle pour s’assurer qu’aucun client ou tâche ne monopolise les ressources et n’entraîne des problèmes de performances pour les autres. Shuffle-sharding est une technique précieuse pour y parvenir. En divisant les ressources en segments égaux et en les mélangeant périodiquement, le shuffle-sharding peut répartir les ressources de manière uniforme et empêcher tout client ou tâche de s’appuyer trop longtemps sur un segment spécifique. Cette technique est particulièrement utile dans les scénarios avec un risque de mauvais acteurs ou de clients ou de tâches qui se comportent mal. Dans cet article, nous explorerons en profondeur le shuffle-sharding, en expliquant comment il équilibre les ressources et améliore les performances globales du système.
Modèle
Avant de mettre en œuvre le shuffle-sharding, il est important de comprendre ses principales dimensions, paramètres, compromis et résultats potentiels. La création d’un modèle et la simulation de différents scénarios peuvent vous aider à mieux comprendre le fonctionnement du shuffle-sharding et son impact sur les performances et la disponibilité de votre système. C’est pourquoi nous allons explorer plus en détail le shuffle sharding, en utilisant un notebook Colab comme terrain de jeu. Nous discuterons de ses avantages, de ses limites et des facteurs à prendre en compte avant de l’implémenter. À la fin de cet article, vous aurez une meilleure idée de ce que le shuffle-sharding peut et ne peut pas faire et s’il s’agit d’une technique appropriée pour votre cas d’utilisation spécifique.
Dans les applications pratiques, le shuffle-sharding est souvent utilisé pour répartir uniformément les ressources disponibles entre différentes requêtes ou tâches. Cela peut impliquer de mapper différents clients ou connexions à des sous-ensembles de nœuds ou de conteneurs ou d’attribuer des cœurs spécifiques à différents types de requêtes (ou « requêtes » pour être court).
Dans notre simulation, nous avons lié les requêtes aux cœurs de processeur. L’objectif est de garantir que les ressources CPU disponibles sont partagées équitablement entre toutes les requêtes, empêchant toute requête de prendre le contrôle des ressources et d’avoir un impact négatif sur les performances des autres.
Pour ce faire, chaque requête est limitée à seulement 25 % des cœurs disponibles, et aucune requête n’a plus d’un cœur en commun. Cela permet de minimiser les chevauchements entre les requêtes et d’éviter qu’une requête ne consomme plus que sa juste part de ressources.
Voici une visualisation de la façon dont les cœurs (colonnes) sont alloués à chaque type de requête (lignes) et comment le chevauchement entre eux est minimisé (chaque requête a exactement trois cœurs attribués) :
Le chevauchement maximal entre les lignes n’est que d’un bit (c’est-à-dire 33 % des cœurs attribués) et le chevauchement moyen est d’environ 0,5 bit (moins de 20 % ou des cœurs attribués). Cela signifie que même si un type de requête devait prendre en charge 100 % des cœurs alloués, les autres auraient toujours une capacité suffisante pour s’exécuter, contrairement à l’affectation uniforme, où une requête malveillante pourrait monopoliser l’ensemble du processeur du nœud.
Pour évaluer l’impact de différents facteurs sur les performances du système, nous avons effectué quatre simulations, chacune avec des dimensions différentes :
- Affectation de requête uniforme, où n’importe quel type de requête peut être affecté à n’importe quel cœur, par rapport à l’affectation de partitionnement aléatoire, où les requêtes sont attribuées en fonction des principes de partitionnement aléatoire.
- Baseline, où toutes les requêtes se comportent bien, par rapport à la présence d’un mauvais type de requête qui prend 100 % des ressources du processeur et ne se termine jamais.
Examinons le taux d’erreur (qui n’inclut pas le mauvais type de requête car il échoue dans 100 % des cas) :
En regardant le graphique du taux d’erreur, nous pouvons observer que le Uniforme de base scénario a un point de saturation légèrement plus élevé que le Partage aléatoire de la ligne de base scénario, atteignant un taux de requête supérieur d’environ 5 % avant que le système ne commence à se dégrader. Cela est attendu car le partitionnement aléatoire partitionne les cœurs de processeur en sections plus petites, ce qui peut réduire l’efficacité de l’allocation des ressources lorsque le système est proche de sa pleine capacité.
Cependant, lorsque l’on compare les performances de Uniforme contre. Shuffle-Sharding en présence d’un voisin bruyant qui s’empare de toutes les ressources disponibles, on voit que Shuffle-Sharding surpasse Uniforme d’environ 25 %. Cela démontre que les avantages du shuffle-sharding pour empêcher la prise en charge des ressources et assurer une allocation équitable des ressources l’emportent sur la réduction mineure de l’efficacité dans des conditions de fonctionnement normales.
En ingénierie, les compromis font partie de la vie, et le shuffle-sharding ne fait pas exception. Bien qu’il puisse diminuer le point de saturation pendant les opérations normales, il réduit considérablement le risque de pannes lorsque les choses ne se passent pas comme prévu, ce qui est inévitable tôt ou tard.
Débit du système
Outre les taux d’erreur, un autre indicateur clé pour évaluer les performances d’un système est le débit, qui mesure le nombre de requêtes que le système peut traiter en fonction du taux de RPS. Pour analyser le débit du système, nous avons examiné les mêmes données sous un angle différent.
Dans le graphique ci-dessous, nous pouvons voir une légère différence entre les scénarios Baseline Uniform et Baseline Shuffle-Sharding, où Uniform surpasse légèrement Sharding à de faibles taux de RPS. Cependant, la différence devient beaucoup plus importante lorsque nous introduisons un client/tâche/requête défectueux qui monopolise toutes les ressources disponibles. Dans ce scénario, Shuffle-Sharding surpasse Uniform par une marge considérable :
Latence
Examinons maintenant les graphiques de latence, qui montrent la latence moyenne, médiane (p50) et p90 des différents scénarios.
Dans le scénario Uniforme, nous pouvons voir que la latence de toutes les requêtes approche assez rapidement du seuil d’expiration à tous les niveaux. Cela démontre que la monopolisation des ressources peut avoir un impact significatif sur les performances de l’ensemble du système, même pour les requêtes bien conduites :
Dans le scénario Sharding, nous pouvons observer que le système gère la situation beaucoup plus efficacement et conserve la latence des requêtes qui se comportent bien comme si rien ne s’était passé jusqu’à ce qu’il atteigne un point de saturation, qui est très proche de la capacité totale du système. Il s’agit d’un résultat impressionnant, qui met en évidence les avantages du shuffle-sharding pour isoler l’impact de la latence d’un voisin bruyant/qui se comporte mal.
Utilisation du processeur
Au cœur du shuffle-sharding se trouve l’idée de distribuer des ressources pour empêcher tout le navire de couler, mais de ne permettre qu’une section d’être inondée. Pour illustrer ce concept, examinons les données CPU simulées.
Dans la simulation uniforme, la saturation du processeur se produit presque instantanément, même avec de faibles taux de RPS. Cela montre à quel point la monopolisation des ressources peut avoir un impact significatif sur les performances du système, même sous une charge minimale. Cependant, dans la simulation Sharding, le système maintient des performances constantes et fiables, même dans des conditions difficiles. Ces résultats de simulation s’alignent sur les graphiques de latence et d’erreur que nous avons vus précédemment – le mauvais acteur a été isolé et n’a affecté que 25% de la capacité du système, laissant les 75% restants disponibles pour les requêtes bien comportées.
Réflexions finales
En conclusion, le shuffle-sharding est une technique précieuse pour équilibrer des ressources limitées entre plusieurs clients ou tâches dans des systèmes distribués. Sa capacité à empêcher la monopolisation des ressources et à garantir une allocation équitable des ressources peut améliorer la stabilité du système et maintenir des performances cohérentes et fiables, même en présence de clients, de tâches ou de requêtes défectueux. De plus, le shuffle-sharding peut aider à réduire le rayon d’explosion des défauts et à améliorer l’isolation du système, soulignant son importance dans la conception de systèmes distribués plus stables et fiables.
Bien sûr, en cas de panne, d’autres mesures doivent être appliquées, telles que la limitation du débit du client/tâche fautif ou son déplacement vers une capacité dédiée afin de minimiser l’impact sur le système. Des pratiques opérationnelles efficaces sont essentielles pour maximiser les avantages du shuffle-sharding. Pour d’autres techniques pouvant être utilisées conjointement avec le shuffle-sharding, consultez les liens ci-dessous.
N’hésitez pas non plus à jouer avec la simulation et à modifier les paramètres tels que le nombre de types de requêtes, de cœurs, etc. pour avoir une idée du modèle et de la manière dont différents paramètres peuvent l’affecter.
Cet article poursuit le thème de l’amélioration des performances/disponibilité des services abordé dans les articles précédents Assurer des performances prévisibles dans les systèmes distribués, Naviguer les avantages et les risques de la couverture des demandes pour les services réseau FIFO vs LIFO : quelle stratégie de mise en file d’attente est la meilleure pour la disponibilité et la latence ?.