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) → найближчий РОР/регіон.
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 на верхніх), ви отримаєте передбачувані хвости латентності, стійкість до перевантаження і контрольовані, безпечні релізи.