Implémentation de limites de simultanéité adaptatives – DZone

Des services hautement disponibles et fiables sont la marque de fabrique de toute entreprise florissante dans l’économie numérique d’aujourd’hui. En tant que propriétaire de service, il est important de s’assurer que vos services respectent les SLA. Mais lorsque des bogues arrivent en production ou que le trafic utilisateur augmente de manière inattendue, les services peuvent ralentir sous un grand volume de demandes et échouer. Si elles ne sont pas traitées à temps, ces pannes ont tendance à se répercuter sur votre infrastructure, entraînant parfois une panne complète.

Chez FluxNinja, nous croyons que limites de simultanéité adaptatives sont le moyen le plus efficace de garantir que les services sont protégés et continuent de fonctionner dans le cadre des SLA.

Que sont les limites de simultanéité ?

La simultanéité est le nombre de requêtes qu’un service peut traiter à un moment donné. Il est calculé à l’aide de la loi de Little, qui stipule que dans l’état stable à long terme d’un système de production, le nombre moyen d’articles L dans le système est le produit du taux d’arrivée moyen λ et du temps moyen W qu’un article passe dans le système, c’est-à-dire L=λW. Si des demandes excédentaires arrivent au-delà de L, elles ne peuvent pas être servies immédiatement et doivent être mises en file d’attente ou rejetées. Et cela pourrait entraîner une accumulation importante de files d’attente, ralentissant les temps de réponse des services. Cependant, les files d’attente ne se créent pas tant que les services respectent leurs limites de simultanéité.

Les limites de simultanéité sont difficiles à estimer, en particulier lorsqu’il existe un grand nombre de micro-services interdépendants et d’environnements en évolution rapide.

• Mises à jour dans les micro-services: Les micro-services sont mis à jour fréquemment, et quelle que soit la limite de simultanéité que vous avez initialement définie, elle pourrait être obsolète dans la prochaine version de votre micro-service, ce qui entraînerait un goulot d’étranglement des performances ou une interruption du service. De plus, les ajouts de fonctionnalités et les changements de configuration rendent difficile le suivi de l’évolution des limites de simultanéité.
• Environnements à taux de désabonnement élevé : Les événements de scale-in et scale-out modifient les limites de simultanéité. Lorsque les services évoluent, les limites de simultanéité doivent être ajustées dynamiquement pour équilibrer le trafic entrant.

C’est pourquoi la définition dynamique de limites de simultanéité (Adaptive Concurrency Limits) en fonction de la santé globale du service est le meilleur moyen de protéger un service et de respecter les SLA.

Limites adaptatives de simultanéité par rapport aux limites de débit

À première vue, les limites de simultanéité et les limites de débit semblent faire le même travail. Mais ils servent des objectifs très différents.

Les limites de débit sont une technique préventive – elles empêchent l’utilisation abusive d’un service par un utilisateur particulier, en s’assurant que le service reste disponible pour les autres utilisateurs. Mais cette technique n’aide pas s’il y a une augmentation du trafic global non attribuée à un utilisateur spécifique.

D’autre part, les limites adaptatives de concurrence sont une technique de protection de la fiabilité. À l’aide des limites de simultanéité adaptatives, il est possible de détecter le moment où le nombre de requêtes adressées à un service dépasse la limite de simultanéité d’un service et de déclencher des interventions de fiabilité.

Utilisation d’Aperture pour les limites de simultanéité adaptatives

Aperture est une plate-forme open source de contrôle de flux et de fiabilité qui peut vous aider à définir des limites de simultanéité adaptatives pour vos services. Au cœur d’Aperture se trouve une boucle de système de contrôle, qui se manifeste par :

1. Observation : les agents d’Aperture surveillent l’écart de la latence actuelle de votre service par rapport aux tendances historiques à l’aide de Golden Signals et identifient l’accumulation ou la détérioration de la charge.
2. Analyse : Aperture Controller, qui est le cerveau de la boucle de contrôle, évalue en permanence les écarts par rapport aux SLA et communique les décisions de contrôle de flux aux agents.
3. Actionnement : les agents d’Aperture se trouvent juste à côté des instances de service, réglementant et hiérarchisant les demandes via un planificateur.

Pour montrer comment les limites de simultanéité adaptative peuvent être définies dans la pratique, plongeons dans une configuration de démonstration des agents et des contrôleurs Aperture.

Configuration de la démo

Aperture est livré avec un terrain de jeu, préconfiguré avec un générateur de trafic, un exemple d’application et une instance de Grafana que vous pouvez utiliser pour voir divers signaux générés par une politique.

Le composant logiciel enfichable ci-dessus montre une application de démonstration avec trois services et un générateur de trafic nommé wavepool-generator.

Topologie des services

L’application de démonstration est un exemple de topologie de micro-services, où la demande découle de service1 pour service2 et service2 pour service3. Chaque service ajoute un délai avec une gigue pour simuler le traitement. Le service 3 est le service en amont configuré avec une limite de simultanéité artificielle pour simuler des scénarios de surcharge.

Modèle de trafic

Le générateur de trafic est conçu pour générer une charge de trafic symétrique pour deux types d’utilisateurs : les abonnés et les invités. Fondamentalement, le générateur de charge alterne périodiquement entre les scénarios de trafic régulier et de trafic élevé. Sa configuration est présente sous le fichier playground/load_generator/scenarios/load_test.js.

export let vuStages = [
  { duration: "10s", target: 5 },
  { duration: "2m", target: 5 },
  { duration: "1m", target: 30 },
  { duration: "2m", target: 30 },
  { duration: "10s", target: 5 },
  { duration: "2m", target: 5 },
];

export let options = {
  discardResponseBodies: true,
  scenarios: {
    guests: {
      executor: "ramping-vus",
      stages: vuStages,
      env: { USER_TYPE: "guest" },
    },
    subscribers: {
      executor: "ramping-vus",
      stages: vuStages,
      env: { USER_TYPE: "subscriber" },
    },
  },
};

Et générer le modèle de trafic suivant –

• Accélérer jusqu’à 5 utilisateurs simultanés dans 10s.
• Tenir à 5 utilisateurs simultanés pour 2m.
• Accélérer jusqu’à 30 utilisateurs simultanés en 1m (surcharges service3).
• Tenir à 30 utilisateurs simultanés pendant 2 m (surcharges service3).
• Rampe vers le bas 5 utilisateurs simultanés dans 10s.
• Tenir à 5 utilisateurs simultanés pour 2m.

Déploiement des politiques d’Aperture pour les limites de simultanéité adaptatives

Aperture est livré avec une liste prédéfinie de politiques Aperture et de tableaux de bord Grafana qui peuvent être utilisés à la fois comme guide pour créer de nouvelles politiques et comme plans Aperture prêts à l’emploi pour générer des politiques personnalisées pour un service et le cas d’utilisation. Les politiques sont évaluées périodiquement, comme défini dans les plans. En savoir plus sur la génération de politique d’ouverture ici.

Le terrain de jeu est configuré avec une politique de gradient de latence. Cette stratégie est configurée pour mesurer la latence de service de service3 via Flux Meter, et ce signal est utilisé pour détecter un état de surcharge. Le limiteur de simultanéité est déployé sur service1, qui est le service en aval (voir Topologie du service). Cela garantit que lorsque service3 est surchargé, nous cessons d’accepter des demandes supplémentaires au point d’entrée, c’est-à-dire service1pour éviter le travail inutile.

Aperture est livré avec un mode de simulation qui peut être configuré dynamiquement, ce qui nous permet de valider le comportement de la politique sans affecter le trafic entrant.

Lorsqu’aucune protection n’est configurée pour les services

Avec l’aide du tableau de bord Grafana fourni par Aperture, la latence de service 3 (Dans ce cas, la politique d’Aperture s’exécute en mode simulation) peut être facilement surveillée.

Augmentation du trafic

Une fois que le générateur de trafic commence à augmenter le nombre d’utilisateurs, la latence de service3 (sous le panneau FluxMeter) Commence à toucher 140 ms. Alors que dans des conditions normales, il est inférieur à 60 ms. Ces pics de latence pourraient entraîner une mauvaise expérience utilisateur, ou si cette latence continue d’augmenter, elle atteindra le délai d’attente du client et le service deviendra complètement indisponible, déclenchant une défaillance en cascade potentielle dans toute l’application.

En outre, il convient de mentionner; la charge de travail des utilisateurs abonnés n’est pas priorisée, ce qui implique que si les utilisateurs invités font trop de demandes, les utilisateurs abonnés seront confrontés aux conséquences telles qu’une latence élevée et des problèmes de délai d’expiration des demandes.

Quand Aperture protège le service

Une fois qu’Aperture devient actif, il commence à évaluer tous les signaux. Le tableau de bord des signaux est disponible sous aperture-controller à l’intérieur de Grafana. Ces signaux sont transmis à travers un circuit, convertissant les signaux en décisions de contrôle.

Pour en savoir plus sur le fonctionnement d’un circuit, consultez ce schéma de circuit de la politique.

Les métriques du signal doré dans Prometheus sont importées en tant que signaux, et chaque signal peut être tracé pour comprendre le fonctionnement d’un circuit tel que –

• EMA – Ceci est utilisé pour calculer le point de consigne de latence.
• IS_OVERLOAD – Suit si la politique pense qu’un service est surchargé.
• LOAD_MULTIPLIER – Suit les décisions de délestage publiées sur les agents Aperture
• Et etc.

Tableau de bord des signaux

Après avoir évalué les signaux via des circuits, des décisions sont prises. L’un des avantages de la politique est qu’elle peut être personnalisée pour une latence d’acceptation maximale en fonction des exigences et du SLO.

Quand Aperture protège le service.

Ici, le modèle de trafic est le même que précédemment. Cependant, cette fois-ci, Aperture utilise les limites de simultanéité des services pour décider d’approuver une demande de traitement ou de la rejeter.

Scénario de trafic normal

Dans des circonstances normales, la latence oscille autour de 50 ms. C’est là qu’Aperture apprend la latence de base en faisant une moyenne mobile exponentielle sur les lectures de latence. Pour suivre le trafic entrant, consultez le panneau « Incoming Concurrency », et pour le trafic accepté, vérifiez le panneau « Accepted Concurrency », comme indiqué ci-dessus dans l’instantané.

Les charges de travail d’invité et d’abonné indiquées sur les indices 0 et 1, respectivement, ont des taux d’acceptation égaux dans le panneau « Décisions de charge de travail », car il n’y a pas de baisse de trafic pendant les charges normales au début.

De plus, Aperture estime automatiquement le coût d’admission de la demande pour chaque charge de travail, qui peut être suivi dans le panneau « Workload Latency ». Cette estimation permet de hiérarchiser et de planifier équitablement les demandes lors de scénarios de surcharge. Le planificateur d’Aperture peut hiérarchiser les charges de travail en fonction des attributs de la demande. Par exemple, dans cette politique, la charge de travail de l’utilisateur abonné est configurée pour avoir une priorité plus élevée que les charges de travail de l’utilisateur invité.

Augmentation du trafic

Lorsque les générateurs de trafic commencent à augmenter le nombre d’utilisateurs simultanés, service3 se trouvera en situation de surcharge, entraînant une augmentation de la latence. Dès qu’Aperture détecte ce pic de latence, il limite la simultanéité sur service1. En fonction des priorités configurées dans la politique,…