Dans la continuité de mon article sur le tir de performance des Application Gateway Azure, voyons comment auditer par le feu un HTTP(S) Load Balancer de niveau 7 sur Google Cloud Platform (GCP).

Tester un répartiteur de charge sur GCP réserve une surprise de taille aux ingénieurs habitués aux clouds traditionnels : vous ne testez pas une machine virtuelle isolée, mais la couche périphérique mondiale Google Front End (GFE).

1. Pourquoi la décomposition de latence GCP est redoutable pour le diagnostic

Lorsqu’un tir de charge Vegeta ou Gatling met en évidence un ralentissement sur une URL exposée derrière un Load Balancer GCP, Cloud Monitoring sépare nativement deux métriques fondamentales :

1. https/total_latencies : le temps mesuré depuis la réception de la requête cliente par le GFE jusqu’à l’envoi du dernier octet de réponse ;
2. https/backend_latencies : le temps écoulé entre le moment où le proxy Google transmet la requête à votre back-end (GKE ou groupe de VMs) et la réception de la réponse.

Règle d’or de diagnostic : si total_latencies augmente alors que backend_latencies reste plate à 5 ms, le goulot d’étranglement se situe sur le lien réseau entre votre injecteur et le PoP Google (ou dans l’évaluation des règles WAF Cloud Armor). Si les deux courbes montent en parallèle, c’est votre pool applicatif ou votre base de données qui sature.

2. Campagne de tir avec Vegeta en conteneur

Pour éviter le biais d’une connexion TCP unique réutilisée à l’infini, nous injectons du trafic vers l’IP Anycast du Load Balancer en surveillant les codes retour :

docker run --rm -i peterevans/vegeta sh -c \
  "echo 'GET https://blog.ravindra-job.fr/' | \
   vegeta attack -rate=500 -duration=2m -max-workers=200 | \
   tee results.bin | vegeta report"

3. Le piège du Container-Native Load Balancing (NEG) sur GKE

Lors de nos premiers tirs sur un cluster GKE placé derrière un Load Balancer GCP classique (routage via NodePort et kube-proxy), nous observions un saut réseau supplémentaire (double hop) entre les nœuds du cluster.

En activant l’annotation cloud.google.com/neg: '{"ingress": true}' sur le Service Kubernetes, le Load Balancer GCP route directement les paquets vers l’adresse IP interne de chaque Pod (Network Endpoint Group). Résultat mesuré sous Vegeta à 1 000 req/s :

• Gain de latence p99 : -28 % ;
• Disparition totale des erreurs 502 Bad Gateway lors de la terminaison d’un pod pendant un scale-down.

MàJ 2026 Cloud Armor Adaptive Protection, HTTP/3 et Envoy Metrics

En 2026, préparer et analyser un tir de performance sur GCP implique trois vérifications préalables :

1. Whitelister vos injecteurs dans Cloud Armor Adaptive Protection : le moteur de Machine Learning de Cloud Armor détecte en quelques secondes une signature de tir synthétique (Vegeta, k6, Locust) et propose ou applique automatiquement une règle de rate-limiting (429 Too Many Requests ou 403). Créez toujours une politique de pré-filtrage autorisant les IP publiques de vos nœuds d’injection avant le tir.
2. Tester en HTTP/3 (QUIC) : les Global External Application Load Balancers négocient désormais h3 par défaut. Pour reproduire fidèlement le trafic mobile réel (où QUIC réduit drastiquement le temps de handshake en cas de perte de paquets), utilisez des injecteurs supportant HTTP/3 comme k6 (experimental-http3) ou curl --http3.
3. Exploiter l’en-tête Server-Timing de GCP : sur les nouveaux Load Balancers basés sur Envoy, vous pouvez activer l’injection automatique d’en-têtes de télémétrie qui renvoient directement à votre outil de tir le temps passé dans le proxy vs le back-end.

Partager cette note :

LinkedIn Post X Telegram E-mail Copier le lien

Hardening & Optimisation Performance par CLI gcloud et Terraform

Sur Google Cloud, la performance et la sécurité convergent sur le Global External Application Load Balancer (EXTERNAL_MANAGED) propulsé par Envoy et Andromeda [1]. Pour éliminer les goulets d’étranglement tout en durcissant le plan de données :

• Activez HTTP/3 (QUIC) et le profil TLS RESTRICTED [2].
• Configurez le Connection Draining, l’Outlier Detection (éjection automatique des backends dégradés) et le Cloud Armor Edge Security Policy [3].

1. Commandes CLI (gcloud) : Tuning Haute Performance & Hardening

# Activer l'Outlier Detection (Circuit Breaker L7) + Logging + Cloud Armor
gcloud compute backend-services update prod-api-backend \
  --global \
  --security-policy=prod-cloud-armor-waf \
  --connection-draining-timeout=60s \
  --enable-logging \
  --logging-sample-rate=1.0

# Forcer QUIC (HTTP/3) et la politique SSL stricte sur le proxy HTTPS
gcloud compute target-https-proxies update prod-https-proxy \
  --quic-override=ENABLE \
  --ssl-policy=prod-ssl-policy-strict

2. Terraform HCL : Backend Service avec Circuit Breaker & QUIC

resource "google_compute_backend_service" "perf_hardened_backend" {
  name                            = "prod-api-backend"
  load_balancing_scheme           = "EXTERNAL_MANAGED"
  protocol                        = "HTTP2"
  timeout_sec                     = 30
  connection_draining_timeout_sec = 60
  security_policy                 = google_compute_security_policy.waf_hardened.id

  outlier_detection {
    consecutive_errors                    = 3
    base_ejection_time { seconds = 30 }
    interval { seconds = 10 }
    max_ejection_percent                  = 50
    enforcing_consecutive_errors          = 100
  }

  circuit_breakers {
    max_connections             = 4096
    max_pending_requests        = 1024
    max_requests_per_connection = 100
  }

  log_config {
    enable      = true
    sample_rate = 1.0
  }
}

resource "google_compute_target_https_proxy" "perf_https_proxy" {
  name          = "prod-https-proxy"
  url_map       = google_compute_url_map.default.id
  quic_override = "ENABLE"
  ssl_policy    = google_compute_ssl_policy.strict_tls.id
}

Sources

• [1] Google Cloud Official Documentation : Global External Application Load Balancer
• [2] Google Cloud Official Documentation : SSL Policies & TLS 1.3 Configuration
• [3] Google Cloud Official Documentation : Cloud Armor Edge & Backend Security Policies