Shaping et routage du trafic

1) Pourquoi c'est tout

• Stabilité : ne laissons pas les « voisins bruyants » marquer les canaux.
• Équité : priorités et quotas entre tenants et classes.
• Efficacité : nous envoyons la demande là où elle est traitée plus rapidement/moins cher.
• Contrôle du changement : Canaries/weighted-releases sans risque.
• Économies : Optimisation de la valeur egress/egress et du cache CDN.

2) Concepts de base

2. 1 Traffic shaping vs policing

Shaping - aligne le trafic en tamponnant et en envoyant des paquets à la vitesse cible (lissage « explosions »).
Politique - « punit » les dépassements (drop/marquage) sans tampon. Plus dur, mais moins cher.

2. 2 Classes, files d'attente et disciplines

Files d'attente prioritaires (PRIO), WFQ/DRR (répartition équitable), HTB (quotas hiérarchiques), CoDel/RED (lutte contre le bloat tampon), ECN (signal de surcharge sans drop).
Sur L7, « file d'attente » sous forme de limites RPS/connexions/octets et pools prioritaires.

2. 3 Algorithmes de limitation

Token Bucket (n tokens ajoutés avec rate r ; demande « dépense » k tokens).
Leaky Bucket (sortie fixe ; bon pour le lissage).
Limites globales/locales : locales - rapides, globales - équitables (Redis/etcd/per-tenant).

3) QoS sur le L3/L4

3. 1 DSCP/ToS et classes de service

Marquez les paquets comme le trafic (l'interactif, bekend-RPC, les devoirs de fond).
Dans les centres de données - concilier la politique DSCP avec l'usine réseau/nuage.

3. 2 Linux tc : HTB + fq_codel (croquis)

bash
Clearing tc qdisc del dev eth0 root 2 >/dev/null         true

Корневая HTB с 1Gbit tc qdisc add dev eth0 root handle 1: htb default 30 tc class add dev eth0 parent 1: classid 1:1 htb rate 1gbit

Класс latency-critical 200Mbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 200mbit ceil 1gbit prio 0 tc qdisc add dev eth0 parent 1:10 handle 10: fq_codel

Класс background 100Mbit tc class add dev eth0 parent 1:1 classid 1:30 htb rate 100mbit ceil 1gbit prio 2 tc qdisc add dev eth0 parent 1:30 handle 30: fq_codel

3. 3 ECN/RED/BBR

L'ECN réduit les drops aux pics ; RED/CoDel limite le bloat tampon.
Le BBR (au lieu de Cubic) réduit souvent la latence p99, en particulier au-dessus des WAN/files d'attente lourdes.

4) Routage L7 (HTTP/gRPC/WS)

4. 1 Critères d'itinérance

Chemins/méthodes ('/api/v1/', 'POST'), titres (version client, drapeaux ficha, heder canarien), cookies (A/B, sticky), JWT-stimes (tenant/role), géo/ASN, fenêtres temporelles, charge (outler detection).
Protocole : HTTP/2 (multiplexage), HTTP/3/QUIC (résistance à la perte de paquets), gRPC (bi-di streams), WebSocket (connexions à longue durée de vie).

4. 2 Splite pondéré/sorties canaries

Rout'v1 : 95 % ',' v2 : 5 % ', augmentation automatique avec les mesures « vertes ».
Coupures : erreurs/latence/invariants d'affaires.

Envoy (croquis)

yaml route:
weighted_clusters:
clusters:
- name: svc-v1 weight: 95
- name: svc-v2 weight: 5

Istio

yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService spec:
hosts: ["svc"]
http:
- route:
- destination: { host: svc, subset: v1, weight: 95 }
- destination: { host: svc, subset: v2, weight: 5 }

4. 3 Sticky-sessions et consistance hashing

Session affinity par cookie/IP/JWT ID.
Consistent hashing pour les clusters de cache, les services chardonnés, les gateways rate limit.

Nginx

nginx upstream api {
hash $cookie_user_id consistent;
server 10. 0. 0. 1;
server 10. 0. 0. 2;
}

4. 4 Itinéraires Géo- et Latency-aware

GeoIP/ASN au bord (CDN/edge) → la région/RR la plus proche.
Latency-aware : échantillons santé périodiques + mesures RTT → trafic vers le cluster « le plus rapide ».

4. 5 Outlier detection / circuit breaking

Sélection des « mauvaises » instances : max-ejection-percent, erreurs de base/latence.
Circuit breaker : limites pour les connexions/RPS/dans les files d'attente.

5) Traffic shaping au niveau des passerelles/mash pile

5. 1 Rate limiting

Local (per-pod) : pas cher mais pas juste inter-réplique.
Global (Redis/etcd) : justice per-tenant/clé API.
Politiques : per-route, per-method, per-tenant, burst.

Envoy RLS (croquis)

yaml typed_per_filter_config:
envoy. filters. http. ratelimit:
"@type": type. googleapis. com/envoy. extensions. filters. http. ratelimit. v3. RateLimit domain: "api"
rate_limit_service:
grpc_service: { envoy_grpc: { cluster_name: rate_limit_cluster } }

5. 2 Fairness et priorités

Pools de priorité :> Système> Arrière-plan.
DRR/WFQ équivalents par L7 : quotas/poids par client/tenant.

5. 3 Surcharge et protection

Load-shed : défaillance/dégradation lorsque les budgets sont dépassés.
Concurrence adaptative : dynamique des limites de p50/p95/queue-len.
Server-side backpressure: 429/503 + Retry-After.

6) eBPF et niveau CNI

6. 1 Cilium/eBPF

Filtrage/routage dans le noyau : moins de pulls contextuels, politiques subtiles L3-L7.
Maglev hashing pour une distribution stable.
Programme eBPF pour per-pod QoS (TC/XDP hooks).

6. 2 Calico/NetworkPolicies

Stratégies d'accès L3/L4, classes de priorité de base, intégration avec Kubernetes QoS (Guaranteed/Burstable/BestEffort).

7) passerelles Edge/CDN et API

CDN : clés cache (normaliser query/headers), stale-while-revalidate, protection origin (rate limit/filtres bot).
passerelles API : authentification, quotas/plans tarifaires (per-consumer), restrictions SLA, géo-itinéraire, version API.
WAF : filtrage sur le bord pour ne pas gaspiller le CPU du noyau.

8) Bus asynchrones/streaming

Kafka/NATS/Pulsar : quotas pour les producteurs/consumers, limite de taille batch, backpressure via lag.
Routage d'événements : clés de lot (tenant/idempotency-key), « clignotant » les lots pour l'uniformité.
Exactly-once ≈ « efficace une fois » : producteurs transactionnels + singes idempotent.

9) Timouts, Retrai, backoff

Temporisation de bout en bout : client <proxy <service (pas l'inverse).
Retrai : nombre limité avec backoff exponentiel jitterisé, mais pas de tempêtes.
L'idempotence est obligatoire pour les retraits ; autrement - SAGA/compensation.
Hedged/parallel requests (attention) : améliore p99, augmente le trafic total.

10) Observabilité et SLO

10. 1 Métriques

rate_limit_hits, requests_queued, shed_requests_total, latency_ms{p50,p95,p99}, error_ratio, retry_attempts, outlier_ejections, queue_time_ms.

10. 2 Tracing

Balayer Correlation-ID ; dissociez les spans du type de cause : 'retry' shed 'throttle' queue '.
Links pour rétracteurs/hedges pour comprendre l'impact sur les sous-systèmes.

10. 3 Logs/rapports

Résumé par drop/shedding/limites, cartes thermiques par itinéraire.
Panneaux distincts pour le per-tenant de la justice (fairness index).

10. 4 exemples de SLO

"p99 ≤ 300 ms à 95-percentile de charge ; shed ≤ 0. 1%; error_ratio ≤ 0. 5%».
Au moins 95 % du quota est garanti à la classe interactive en cas de surcharge.

11) Exemples de configurations

11. 1 Nginx : rate limit + burst + canaris split

nginx map $http_x_canary $canary { default 0; 1 1; }

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

upstream api_v1 { server 10. 0. 0. 1; }
upstream api_v2 { server 10. 0. 0. 2; }

server {
location /api/ {
limit_req zone=perip burst=20 nodelay;
if ($canary) { proxy_pass http://api_v2; break; }
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_pass http://api_v1;
}
}

11. 2 Envoy: circuit breaker + outlier detection

yaml circuit_breakers:
thresholds:
- priority: DEFAULT max_connections: 1000 max_pending_requests: 500 max_requests: 2000 outlier_detection:
consecutive_5xx: 5 interval: 10s max_ejection_percent: 50 base_ejection_time: 30s

11. 3 Istio : quotas per-tenant (réserve via label)

yaml apiVersion: security. istio. io/v1 kind: AuthorizationPolicy spec:
selector: { matchLabels: { app: api } }
rules:
- when:
- key: request. headers[x-tenant]
values: ["gold"]
Next - RateLimitPolicy in the limit provider with a large quota pool for "gold."

11. 4 Kubernetes QoS hints

Guaranteed pour les pods critiques (requests = limites).
PodPriority & Preemption : les pods critiques remplaceront les pods de fond en cas de pénurie.
Topology Spread Constraints : répartition par zone pour la durabilité.

12) Anti-modèles

La limite globale « par œil » → les faux 429/délais chez les clients importants.
Retrai sans jitter/idempotence → tempête.
Confusion de temporisation (client> serveur) → accrochage et « double travail ».
Caches/files d'attente communes pour prod et expériences de contamination → données.
« Toujours sticky » sans bon sens → charge inégale/nœuds chauds.
Désactivé outlier detection → « pourri » instans gâche les métriques de la semaine.

13) Chèque de mise en œuvre

• Segmenter le trafic : classes/tenants/itinéraires.
• Définir les budgets cibles : RPS/connexions/octets et p95/p99.
• Inclure rate limit (local + global), circuit breaker, outler detection.
• Configurez le split canarien + auto-retour par métriques.
• Effacer les timeouts/retraits avec un backoff exponentiel + jitter.
• Inclure ECN/BBR (si possible) et fq_codel/HTB pour egress.
• Pools/caches/files d'attente séparés pour les « ombres » et les expériences.
• Dashboards : métriques des limites, files d'attente, latence, fairness.
• SLO et runbook : critères Shadding/Recover/Inclusions.

14) FAQ

Q : Que choisir : shaping ou policing ?
R : Pour les chemins d'accès personnalisés - shaping (lissage sans drop). Pour les classes de service « arrière-plan « / » bulk »- policing pour protéger les flux critiques.

Q : Comment éviter les tempêtes rétrogrades ?
R : Backoff jitterisé, limite d'essai, idempotence, conseils de serveur 'Retry-After', quotas mondiaux.

Q : Sticky ou hashing ?
A : Sticky - lorsque vous avez besoin d'une session/cache local à l'utilisateur ; hashing - quand vous avez besoin d'uniformité et de stabilité du sharding.

Q : Qu'est-ce qui HTTP/3/QUIC donne ?
R : Sans verrous HOL TCP, meilleure résistance aux pertes, récupération plus rapide - réduit considérablement les résidus p99/p999.

15) Résultats

L'efficacité du shaping et du routage L7 est un ensemble cohérent de politiques : priorités et quotas, répartition équitable, limites de sécurité et itinérance intelligente, étayées par l'observation et les SLO. En suivant les pratiques décrites (HTB/fq_codel/ECN aux niveaux inférieurs et Envoy/Istio/Nginx/eBPF aux niveaux supérieurs), vous obtiendrez des résidus de latence prévisibles, une résistance à la surcharge et des rejets contrôlés et sécurisés.