Shaping e roteamento de tráfego

1) Porquê tudo isso

• Estabilidade: Não deixamos que os vizinhos ruidosos atinjam os canais.
• Justiça: prioridades e quotas entre tenentes/classes.
• Eficiência: Enviamos o pedido para onde ele é processado mais rápido/barato.
• Controle de alterações: lançamentos canários/weighted sem risco.
• Economia: otimização dos valores egress/egress e CDN-dinheiro-truque.

2) Conceitos básicos

2. 1 Traffic shaping vs policing

Shaping - Alinha o tráfego, tampando e enviando pacotes à velocidade de destino (suavizar «explosões»).
Policing - «punição» de excesso (drop/marcação) sem tampão. Mais duro, mas mais barato.

2. 2 Classes, filas e disciplinas

Filas com prioridade (PRIO), WFQ/DRR (distribuição justa), HTB (quotas hierárquicas), CoDel/RED (combate ao tampão), ECN (sinal de sobrecarga sem drop).
O L7 é uma «fila» como limites RPS/conectórios/bytes e grupos prioritários.

2. 3 Algoritmos de limitação

Token Bucket (n tokens adicionado com rate r; consulta «gasta» k tokens).
Leaky Bucket (saída fixa; bom para suavizar).
Limites globais/locais: locais - rápidos, globais - justos (Redis/etcd/para-tenante).

3) QoS em L3/L4

3. 1 DSCP/ToS e classe de serviço

Marquem pacotes por tipo de tráfego ( , backend-RPC, tarefas de fundo).
Em datacenters - Alinhe a política DSCP com a fábrica de rede/nuvem.

3. 2 Linux tc: HTB + fq _ codel (esboço)

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

O ECN reduz os dropos nos picos; Limita o bufê.
O BBR (em vez do Cubic) muitas vezes reduz a latência p99, especialmente sobre o WAN/filas pesadas.

4) Rotação L7 (HTTP/gRPC/WS)

4. 1 Critérios de routing

Caminhos/técnicas ('/api/v1/', 'POST'), cabeçalhos (versão do cliente, porta-bandeiras, heder de canário), cookies (A/B, sticky), marca JWT (tenant/role), geo/ASN, janelas de tempo, carga (outlier detation).
Protocolo: HTTP/2 (multiplexagem), HTTP/3/QUIC (resistência à perda de pacotes), gRPC (bi-di streams), WebSocket (conectórios de longa vida).

4. 2 Deflit/lançamentos de canário ponderado

Root 'v1: 95%', 'v2: 5%', aumento automático em métricas verdes.
Recorte: erros/latência/invariantes de negócios.

Envoy (esboço)

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 sessões de sticky e consent hasing

Sessão affinity por cookie/IP/JWT.
Consistent hasing para clusters de dinheiro, serviços charding, gaitwees rate limit.

Nginx

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

4. 4 Routing geo e latency-aware

GeoIP/ASN na borda (CDN/edge) → RR/região mais próxima.
Latency-aware: health-amostras periódicas + medição de RPT → o tráfego para o cluster «mais rápido».

4. 5 Outlier detection / circuit breaking

Bater «más» instâncias: max-ejation-percent, erros básicos/latência.
Circuito breaker: limites para conectórios/RPS/em filas.

5) Traffic shaping ao nível das passarelas/pilha

5. 1 Rate limiting

Local (per-pod) é uma réplica barata, mas não justa.
Global (Redis/etcd): justiça per-tenant/API-chave.
Políticos: per-road, per-method, per-tenant, burst.

Envoy RLS (esboço)

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 e prioridades

Os grupos prioritários são « »> «sistema»> «fundo».
DRR/WFQ equivalentes em L7: quotas/peso per-cliente/tenante.

5. 3 Sobrecarga e proteção

Load-shed: rejeição/degradação por excesso de orçamento.
Adaptável concurrency: dinâmica de limites de p50/p95/queue-len.
Server-side backpressure: 429/503 + Retry-After.

6) eBPF e CNI

6. 1 Cilium/eBPF

Filtragem/rotação no núcleo: menos contexto-pergaminho, políticas finas L3-L7.
Maglev hasing para distribuição estável.
eBPF para per-pod QoS (TC/XDP hooks).

6. 2 Calico/NetworkPolicies

Políticas de acesso L3/L4, classes de prioridade básicas, integração com Kubernetes QoS (Guaranteed/Burstable/BestEffort).

7) Edge/CDN e passarelas API

CDN: chaves de dinheiro (normalização query/headers), stale-while-revalidate, proteção de origin (rate limit/bot-filtros).
Passarelas API: autenticação, quotas/planos tarifários (per-consumer), restrições SLA, geo-routing, API.
WAF: filtragem na borda para não gastar CPU de núcleo.

8) Pneus assincrônicos/streaming

Kafka/NATS/Pulsar: quotas de produtores/consoadores, limite de tamanho batch, backpressure via lag.
Roteirização de eventos: chaves de partilha (tenant/idempotency-key), partituras «sutis» para uniformidade.
Exactly-once ≈ «efetivamente uma vez», produtores de transações + sinos idumpotentes.

9) Timouts, retrações, backoff

Os horários são passíveis: o cliente <proxy <serviço (não o contrário).
Retrai: número limitado com backoff exponencial jitterizado, mas sem tempestades.
A idimpotência é obrigatória nos retais; senão, SAGA/compensação.
Hedged/paralel requests (cuidado): melhora o p99, aumenta o tráfego geral.

10) Observabilidade e SLO

10. 1 Métricas

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

10. 2 Training

Coloque Correlation-ID; Selecione o tipo de causa "retry" shed "throttle" queue ".
Links para retrações/hedges para entender o impacto nos subsistemas.

10. 3 Logs/relatórios

Resumo sobre drop/shedding/limitações, mapas térmicos sobre as rotas.
Painéis individuais para o feirness index (fairness index).

10. 4 exemplos SLo

"p99 ≤ 300 ms a 95 percenteis de carga; shed ≤ 0. 1%; error_ratio ≤ 0. 5%».
Pelo menos 95% da cota é garantida à classe interativa quando a sobrecarga.

11) Exemplos de configuração

11. 1 Nginx: rate limit + burst + split canário

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: per-tenante quotas (reserva por 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 hintes

Guaranteed para pos críticos (requests = limits).
& Preempition: Subprocuradores críticos vão substituir os fundos com escassez.
Topology Spread Constraits: distribuição por áreas de estabilidade.

12) Anti-pattern

Limite global de «por olho» → falso 429/timeout em clientes importantes.
Retrai sem jitter/idempotação → tempestade.
A confusão de timeouts (cliente> servidor) → as seções e os «trabalhos duplos».
Cachês compartilhados/filas para prod e experiências → contaminação de dados.
«Sempre sticky» sem bom senso → carga desigual/nódulos quentes.
O outlier detation desativado → a instância podre as métricas da semana.

13) Folha de cheque de implementação

• Segmenta o tráfego: classes/tenentes/rotas.
• Defina os orçamentos de destino: RPS/conectórios/bytes e p95/p99.
• Inclua rate limit (local + global), circuito breaker, outlier detation.
• Configure o split canário + revincula automática nas métricas.
• Sugira os temporizadores/retrações com backoff exponencial + jitter.
• Inclua ECN/BBR (sempre que possível) e fq _ codel/HTB para egress.
• Balas individuais/cachês/filas para «sombras» e experiências.
• Dashboard: métricas de limites, filas, latência, fairness.
• SLO e runbook: critérios de shedding/reversão/inclusão.

14) FAQ

Q: O que escolher, shaping ou policing?
A: Para caminhos personalizados - shaping (suavização sem drop). Para as classes de serviço «fundo «/» bulk »- policing para proteger os fluxos críticos.

Como evitar tempestades de retais?
A: backoff titerizado, limite de tentativa, idempotidade, dicas de servidor 'Retry-After', quotas globais.

Q: Sticky ou hasing?
A: Sticky - quando você precisa de sessão/dinheiro é local para o usuário; hashing - quando você precisa de uniformidade e estabilidade do sharding.

Q: O que o HTTP/3/QUIC dá?
A: Sem bloqueios HOL TCP, melhor resistência a perdas, recuperação mais rápida - reduz significativamente as caudas p99/p999.

15) Resultado

O shaping eficiente e o roteamento L7 são um conjunto alinhado de políticas: prioridades e quotas, distribuição justa, limites seguros e roteamento inteligente, apoiados pela observabilidade e SLO. Seguindo as práticas descritas (HTB/fq _ codel/ECN nos níveis inferiores e Envoy/Istio/Nginx/eBPF nos níveis superiores), você terá caudas de latência previsíveis, resistência à sobrecarga e lançamentos controláveis e seguros.