Shaping и маршрутизация трафика

1) Зачем это все

• Стабильность: не даем «шумным соседям» забить каналы.
• Справедливость: приоритеты и квоты между тенантами/классами.
• Эффективность: направляем запрос туда, где он обрабатывается быстрее/дешевле.
• Контроль изменений: канареечные/weighted-релизы без риска.
• Экономия: оптимизация egress/egress-стоимостей и CDN-кэш-хитрейта.

2) Базовые понятия

2.1 Traffic shaping vs policing

Shaping — выравнивает трафик, буферизуя и отправляя пакетами с целевой скоростью (сглаживание «взрывов»).
Policing — «карает» превышения (дроп/маркировка) без буферизации. Жестче, но дешевле.

2.2 Классы, очереди и дисциплины

Очереди с приоритетом (PRIO), WFQ/DRR (справедливое распределение), HTB (иерархические квоты), CoDel/RED (борьба с буферблоатом), ECN (сигнал о перегрузке без дропа).
На L7 — «очереди» в виде лимитов RPS/коннектов/байт и приоритетных пулов.

2.3 Алгоритмы лимитирования

Token Bucket (n токенов добавляется с rate r; запрос «тратит» k токенов).
Leaky Bucket (фиксированный отток; хорош для сглаживания).
Глобальные/локальные лимиты: локальные — быстрые, глобальные — справедливые (Redis/etcd/пер-тенант).

3) QoS на L3/L4

3.1 DSCP/ToS и классы обслуживания

Маркируйте пакеты по типу трафика (интерактив, бэкенд-RPC, фоновые задания).
В датацентрах — согласуйте политику DSCP с сетевой фабрикой/облаком.

3.2 Linux tc: HTB + fq_codel (эскиз)

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

ECN снижает дропы на пиках; RED/CoDel ограничивает буферблоат.
BBR (вместо Cubic) часто уменьшает p99 латентность, особенно поверх WAN/тяжелых очередей.

4) L7-маршрутизация (HTTP/gRPC/WS)

4.1 Критерии роутинга

Пути/методы (`/api/v1/`, `POST`), заголовки (версия клиента, фича-флаги, канареечный хедер), куки (A/B, sticky), JWT-клеймы (tenant/role), гео/ASN, временные окна, нагрузка (outlier detection).
Протокол: HTTP/2 (мультиплексирование), HTTP/3/QUIC (устойчивость к потере пакетов), gRPC (bi-di streams), WebSocket (долгоживущие коннекты).

4.2 Взвешенный сплит/канареечные релизы

Роут `v1: 95%`, `v2: 5%`, автоматическое повышение при «зеленых» метриках.
Отсечки: ошибки/латентность/бизнес-инварианты.

Envoy (эскиз)

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-сессии и consistent hashing

Session affinity по cookie/IP/JWT-идентификатору.
Consistent hashing для кэш-кластеров, шардированных сервисов, гейтвеев rate limit.

Nginx

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

4.4 Гео- и latency-aware роутинг

GeoIP/ASN на краю (CDN/edge) → ближайший POP/регион.
Latency-aware: периодические health-пробы + измерения RTT → трафик в «самый быстрый» кластер.

4.5 Outlier detection / circuit breaking

Выбивание «плохих» инстансов: max-ejection-percent, базовые ошибки/латентность.
Circuit breaker: лимиты на коннекты/RPS/в очередях.

5) Traffic shaping на уровне шлюзов/мэш-стека

5.1 Rate limiting

Локальный (per-pod): дешевый, но не справедливый меж-реплик.
Глобальный (Redis/etcd): справедливость per-tenant/API-ключ.
Политики: per-route, per-method, per-tenant, burst.

Envoy RLS (эскиз)

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 и приоритеты

Приоритетные пулы: «интерактив» > «системные» > «фоновый».
DRR/WFQ эквиваленты на L7: квоты/веса per-клиент/тенант.

5.3 Перегрузка и защита

Load-shed: отказ/деградация при превышении бюджетов.
Adaptive concurrency: динамика лимитов из p50/p95/queue-len.
Server-side backpressure: 429/503 + Retry-After.

6) eBPF и CNI-уровень

6.1 Cilium/eBPF

Фильтрация/маршрутизация в ядре: меньше контекст-свитчей, тонкие политики L3–L7.
Maglev hashing для стабильного распределения.
eBPF-программы для per-pod QoS (TC/XDP hooks).

6.2 Calico/NetworkPolicies

Политики доступа L3/L4, базовые классы приоритета, интеграция с Kubernetes QoS (Guaranteed/Burstable/BestEffort).

7) Edge/CDN и API-шлюзы

CDN: кэш-ключи (нормализация query/headers), stale-while-revalidate, защита origin (rate limit/бот-фильтры).
API-шлюзы: аутентификация, квоты/тарифные планы (per-consumer), SLA-ограничения, гео-роутинг, версия API.
WAF: фильтрация на краю, чтобы не тратить CPU ядра.

8) Асинхронные шины/стриминг

Kafka/NATS/Pulsar: квоты на продюсеров/консюмеров, лимит batch-размеров, backpressure через lag.
Маршрутизация событий: ключи партиционирования (tenant/idempotency-key), «мерцающие» партиции для равномерности.
Exactly-once ≈ «эффективно один раз»: транзакционные продюсеры + идемпотентные синки.

9) Таймауты, ретраи, backoff

Таймауты сквозные: клиент < прокси < сервис (не наоборот).
Ретраи: ограниченное число с джиттеризированным экспоненциальным backoff, но без штормов.
Идемпотентность обязательна при ретраях; иначе — SAGA/компенсации.
Hedged/parallel requests (осторожно): улучшает p99, увеличивает общий трафик.

10) Наблюдаемость и SLO

10.1 Метрики

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

10.2 Трейсинг

Прокидывайте Correlation-ID; размечайте спаны типом причины: `retry|shed|throttle|queue`.
Линки для ретраев/hedges, чтобы понимать влияние на подсистемы.

10.3 Логи/отчеты

Сводка по дропам/шеддингу/лимитам, тепловые карты по маршрутам.
Отдельные панели для пер-тенант справедливости (fairness index).

10.4 SLO-примеры

«p99 ≤ 300 мс при 95-перцентиле нагрузки; shed ≤ 0.1%; error_ratio ≤ 0.5%».
«Не менее 95% квоты гарантировано интерактивному классу при перегрузке».

11) Примеры конфигураций

11.1 Nginx: rate limit + burst + канареечный сплит

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: пер-тенант квоты (резерв через 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 хинты

Guaranteed для критичных подов (requests=limits).
PodPriority & Preemption: критичные поды вытеснят фоновые при дефиците.
Topology Spread Constraints: распределение по зонам для устойчивости.

12) Анти-паттерны

Глобальный лимит «на глаз» → ложные 429/таймауты у важных клиентов.
Ретраи без джиттера/идемпотентности → шторма.
Путаница таймаутов (клиентский > серверного) → зависания и «двойные работы».
Общие кэши/очереди для prod и экспериментов → загрязнение данных.
«Всегда sticky» без здравого смысла → неравномерная нагрузка/горячие узлы.
Отключенный outlier detection → «гнилой» инстанс портит метрики недели.

13) Чек-лист внедрения

• Сегментируйте трафик: классы/тенанты/маршруты.
• Задайте целевые бюджеты: RPS/коннекты/байты и p95/p99.
• Включите rate limit (локальный + глобальный), circuit breaker, outlier detection.
• Настройте канареечный сплит + автооткат по метрикам.
• Пропишите таймауты/ретраи с экспоненциальным backoff + джиттер.
• Включите ECN/BBR (где возможно) и fq_codel/HTB для egress.
• Отдельные пулы/кэши/очереди для «тени» и экспериментов.
• Дашборды: метрики лимитов, очередей, латентности, fairness.
• SLO и runbook: критерии шеддинга/отката/включения.

14) FAQ

Q: Что выбрать: shaping или policing?
A: Для пользовательских путей — shaping (сглаживание без дропов). Для сервис-классов «фон»/«bulk» — policing для защиты критичных потоков.

Q: Как избежать ретрай-штормов?
A: Джиттеризированный backoff, лимит попыток, идемпотентность, серверные подсказки `Retry-After`, глобальные квоты.

Q: Sticky или hashing?
A: Sticky — когда нужна сессия/кэш локален пользователю; hashing — когда нужна равномерность и стабильность шардинга.

Q: Что дает HTTP/3/QUIC?
A: Без HOL-блокировок TCP, лучшая устойчивость к потерям, быстрее восстановление — заметно снижает хвосты p99/p999.

15) Итоги

Эффективный shaping и L7-маршрутизация — это согласованный набор политик: приоритеты и квоты, справедливое распределение, безопасные лимиты и умный роутинг, подкрепленные наблюдаемостью и SLO. Следуя описанным практикам (HTB/fq_codel/ECN на нижних уровнях и Envoy/Istio/Nginx/eBPF на верхних), вы получите предсказуемые хвосты латентности, устойчивость к перегрузке и контролируемые, безопасные релизы.