Load balancing based on workload latency using exponentially weighted moving average (EWMA) - Alibaba Cloud Service Mesh

Les algorithmes d'équilibrage de charge standard, tels que le round robin et la moindre requête, distribuent le trafic selon des règles statiques. Ils ne disposent d'aucune visibilité sur les performances réelles de chaque pod. Si un pod répond lentement en raison d'une contention des ressources, d'un cache froid ou de voisins bruyants sur l'hôte, ces algorithmes continuent de lui acheminer du trafic. Cela augmente la latence globale et les taux d'erreur.

La version 1.21 de Service Mesh (ASM) introduit peak EWMA (peak Exponentially Weighted Moving Average), un algorithme d'équilibrage de charge qui surveille le temps de réponse de chaque pod en temps réel et déplace automatiquement le trafic des pods lents vers les plus rapides. Cette approche réduit considérablement la latence de queue (P90, P95, P99).

Fonctionnement de peak EWMA

Peak EWMA attribue un score à chaque pod backend en combinant les poids statiques, les latences observées et les taux d'erreur dans une moyenne mobile. Contrairement à une moyenne simple, EWMA accorde plus d'importance aux observations récentes, ce qui permet à l'algorithme de réagir rapidement aux pics de latence. La variante « peak » suit spécifiquement la latence dans le pire des cas, ce qui la rend efficace pour les scénarios de trafic en rafale où certains pods se dégradent temporairement.

Quand utiliser peak EWMA

Algorithme	Idéal pour	Limitations
`ROUND_ROBIN`	Charges de travail uniformes avec des performances de pod similaires	Ignore l'état de santé et la latence des pods
`LEAST_REQUEST`	Équilibrage de charge général (valeur par défaut d'ASM)	Ne tient pas compte des différences de temps de réponse
`RANDOM`	Distribution simple et sans état	Aucune intelligence concernant les performances des pods
`PEAK_EWMA`	Charges de travail présentant une latence inégale entre les pods ou un trafic en rafale	Nécessite ASM 1.21 ou une version ultérieure

Choisissez PEAK_EWMA lorsque :

Les pods backend ont des temps de réponse incohérents (par exemple, en raison d'une contention des ressources ou d'un matériel hétérogène).
Votre service gère un trafic en rafale susceptible de surcharger temporairement des pods individuels.
La latence de queue (P95/P99) est plus importante que la latence moyenne pour votre cas d'utilisation.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

Une instance ASM version 1.21 ou ultérieure. Consultez la rubrique Créer une instance ASM
Un cluster Container Service for Kubernetes (ACK) ajouté à l'instance ASM. Consultez les rubriques Ajouter un cluster à une instance ASM et Mettre à jour une instance ASM
Un client kubectl connecté au cluster ACK. Consultez la rubrique Se connecter à un cluster à l'aide de kubectl

Configurer peak EWMA

Appliquez une DestinationRule qui définit l'algorithme d'équilibrage de charge PEAK_EWMA pour votre service cible.

Connectez-vous à la console ASM. Dans le volet de navigation de gauche, choisissez Service Mesh > Mesh Management.
Sur la page Mesh Management, cliquez sur le nom de votre instance ASM. Dans le volet de navigation de gauche, choisissez Traffic Management Center > DestinationRule. Cliquez sur Create from YAML.

Collez le code YAML suivant et cliquez sur Create. Remplacez simple-server et simple-server.default.svc.cluster.local par le nom et l'hôte réels de votre service.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: simple-server
  namespace: default
spec:
  host: simple-server.default.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: PEAK_EWMA  # Latency-aware load balancing

Exemple : Mesurer l'amélioration de la latence

Cet exemple montre comment peak EWMA réduit la latence de queue lorsque les pods backend ont des temps de réponse inégaux. La configuration utilise deux déploiements derrière un seul service :

simple-server-normal : répond en 50 à 100 ms (pod sain).
simple-server-high-latency : répond en 500 à 2 000 ms (simule un pod dégradé).

Un pod sleep agit en tant que client et envoie 100 requêtes pour mesurer la latence avec et sans peak EWMA.

Architecture diagram

Étape 1 : Activer la surveillance des métriques

Activez la surveillance des métriques pour l'instance ASM afin d'observer les variations de latence avant et après l'activation de peak EWMA. Consultez la rubrique Collecter des métriques dans Managed Service for Prometheus.

Étape 2 : Déployer l'environnement de test

Connectez-vous au cluster ACK avec kubectl, puis créez un fichier sleep.yaml avec le contenu suivant :

Afficher sleep.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
    service: sleep
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: sleep
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      terminationGracePeriodSeconds: 0
      serviceAccountName: sleep
      containers:
      - name: sleep
        image: curlimages/curl
        command: ["/bin/sleep", "infinity"]
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /etc/sleep/tls
          name: secret-volume
      volumes:
      - name: secret-volume
        secret:
          secretName: sleep-secret
          optional: true
---

Déployez l'application sleep :

kubectl apply -f sleep.yaml

Créez un fichier simple.yaml avec le contenu suivant :

Afficher simple.yaml

apiVersion: v1
kind: Service
metadata:
  name: simple-server
  labels:
    app: simple-server
    service: simple-server
spec:
  ports:
  - port: 8080
    name: http
  selector:
    app: simple-server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: simple-server
  name: simple-server-normal
  namespace: default
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: simple-server
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: simple-server
    spec:
      containers:
      - args:
        - --delayMin
        - "50"
        - --delayMax
        - "100"
        image: registry-cn-hangzhou.ack.aliyuncs.com/test-public/simple-server:v1.0.0.0-g88293ca-aliyun
        imagePullPolicy: IfNotPresent
        name: simple-server
        ports:
        - containerPort: 80
          protocol: TCP
        resources:
          limits:
            cpu: 500m
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: simple-server
  name: simple-server-high-latency
  namespace: default
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: simple-server
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: simple-server
    spec:
      containers:
      - args:
        - --delayMin
        - "500"
        - --delayMax
        - "2000"
        image: registry-cn-hangzhou.ack.aliyuncs.com/test-public/simple-server:v1.0.0.0-g88293ca-aliyun
        imagePullPolicy: IfNotPresent
        name: simple-server
        ports:
        - containerPort: 80
          protocol: TCP
        resources:
          limits:
            cpu: 500m
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
---

Déployez les deux déploiements de serveur :

kubectl apply -f simple.yaml

Étape 3 : Exécuter un test de référence avec l'algorithme par défaut

L'algorithme par défaut LEAST_REQUEST sert de référence. Envoyez 100 requêtes depuis le pod sleep vers le service simple-server :

kubectl exec -it deploy/sleep -c sleep -- sh -c 'for i in $(seq 1 100); do time curl simple-server:8080/hello; echo "request $i done"; done'

Résultat attendu (abrégé) :

hello
 this is port: 8080real 0m 0.06s
user    0m 0.00s
sys     0m 0.00s
request 1 done
hello
 this is port: 8080real 0m 0.09s
...
hello
 this is port: 8080real 0m 1.72s
user    0m 0.00s
sys     0m 0.00s
request 100 done

Une fois le test terminé, consultez les métriques de latence :

Sur la page Mesh Management, cliquez sur le nom de votre instance ASM. Dans le volet de navigation de gauche, choisissez Observability Management Center > Monitoring metrics.

Cliquez sur l'onglet Cloud ASM Istio Service et définissez les filtres suivants :

Filtre	Valeur
Namespace	`default`
Service	`simple-server.default.svc.cluster.local`
Reporter	`destination`
Client Workload Namespace	`default`
Client Workload	`sleep`
Service Workload Namespace	`default`
Service Workload	`simple-server-normal + simple-server-high-latency`

Cliquez sur Client Workloads pour afficher le panneau Incoming Request Duration By Source.

Baseline test results with LEAST_REQUEST

Les résultats de référence indiquent une latence P50 de 87,5 ms et une latence P95 de 2,05 s. Étant donné que LEAST_REQUEST distribue le trafic de manière uniforme, le pod lent gonfle la latence de queue globale.

Important

Ces résultats de test proviennent d'un environnement contrôlé. Les résultats réels varient en fonction de votre charge de travail et de votre infrastructure.

Étape 4 : Activer peak EWMA et relancer le test

Créez une DestinationRule pour activer peak EWMA pour le service simple-server. Suivez les étapes de la section Configurer peak EWMA en utilisant le code YAML suivant :

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: simple-server
  namespace: default
spec:
  host: simple-server.default.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: PEAK_EWMA

Relancez le même test :

kubectl exec -it deploy/sleep -c sleep -- sh -c 'for i in $(seq 1 100); do time curl simple-server:8080/hello; echo "request $i done"; done'

Consultez les métriques de latence en utilisant les mêmes filtres que lors de l'étape 3.

Test results with PEAK_EWMA

Les latences P90, P95 et P99 chutent considérablement. Peak EWMA détecte que le pod à haute latence répond lentement et réduit sa part de trafic, acheminant la plupart des requêtes vers le pod plus rapide. La latence globale des requêtes pour le service diminue substantiellement.

Alibaba Cloud Service Mesh:Load balancing based on workload latency using EWMA