Реверс-проксі і маршрутизація

1) Роль реверс-проксі

Реверс-проксі - «фронтова лінія» платформи: приймає TLS, розподіляє трафік між апстрімами, застосовує політики безпеки і продуктивності. Мета - мінімальна латентність, передбачувана маршрутизація і швидка ізоляція деградуючих інстансів/зон.

2) Шари та протоколи

L4: TCP/UDP proxy (SNI-based TLS passthrough, QUIC). Низька ціна, без розуміння HTTP.
L7: HTTP/1. 1–2–3, gRPC, WebSocket. Багата маршрутизація (host, path, headers, cookies), трансформації і кеш.

TLS-модель: термінувати на периметрі (NGINX/Envoy), всередині - mTLS/mesh. SNI дозволяє віртуальні хости на одному IP.

3) Стратегії маршрутизації (L7)

1. Host-based: по домену ('api. brand. com'→ кластер'brand-api').
2. Path-based: `/v1/payments` → `payments-svc`, `/v1/wallets` → `wallets-svc`.
3. Header-based: `X-Region: eu-central`, `X-Tenant: 42`, `User-Agent`/`Accept`.
4. Cookie-based: A/B-тести, «липкі» сесії.
5. Weighted/Canary: відсоток трафіку на нову версію (1-5% → 100%).
6. Geo/ASN: по країні/ASN направляємо в найближчий РОР/регіон.
7. Consistent hashing: прив'язка ключа (user_id/tenant_id) до інстансу → кеш-локалітет/липкість.
8. Shadow/Mirroring: копіюємо трафік на «тіньовий» апстрім без впливу на відповідь (для регрес-тестів).

4) Балансування і відмовостійкість

Алгоритми: round-robin, least-request, random, ring-hash (consistent).
Health-checks: активні (HTTP/TCP) + пасивні (за кодами/таймаутами).
Outlier ejection: тимчасово «вибивати» хост з підвищеною помилковістю/латентністю.
Retries: обмежено, з per-try timeout і джиттером; не ретраїти небезпечні методи без ідемпотентності.
Connection pooling: тримати warm-пули до апстрімів, обмежувати максимуми.

5) Продуктивність периметра

Кешування: по ключу (method + host + path + Vary), умови'ETag/If-None-Match', TTL і stale-while-revalidate.
Компресія: brotli/gzip для текстових відповідей.
HTTP/2/3: мультиплексування, header-compression; переконатися в сумісності WAF/IDS.
Request coalescing: схлопувати паралельні запити за один і той же ключ кешу.

6) Безпека на проксі

TLS: 1. 2 + (краще 1. 3), OCSP stapling, HSTS.
WAF/бот-фільтри: до маршрутизації в апп.
CORS/CSP/Fetch-Metadata: відповідно до політиків.
Header-гігієна: `X-Forwarded-For/Proto`, `Forwarded`, `traceparent`; захист від header-injection і oversize.
Body/headers limits: ранні 413/431 для DoS-патернів.
mTLS для партнерських інтеграцій та внутрішніх API.

7) Схеми деплоя: canary/blue-green/версії

Weighted routing на level-7 (1%, 5%, 25%, 50%, 100%).
Header-gate: включати фічу за прапором/заголовком (internal/testing).
Blue-green: перемикання цілком DNS/route, швидкий rollback.
Shadow: паралельний прогін нової версії із записом метрик/логів.

8) Sticky-сесії і хеш-маршрутизація

Cookie-stickiness (`Set-Cookie: SRV=shard-a; Path=/; HttpOnly') для stateful-навантажень.
Ring-hash/consistent по'user _ id/tenant _ id'- зменшення крос-інвалідицій кешу.
Застереження: уникати «вічної» липкості для write-навантажень → hot-spot; використовуйте пер-тенант квоти.

9) Регіональна та гео-маршрутизація

Anycast + гео-DNS для вибору найближчого POP.
Header-override (наприклад,'X-Region') для тестів і налагодження.
Узгоджувати із законодавчо необхідною локалізацією даних (route по регіону/юрисдикції).

10) Спостережуваність і контроль

Метрики RED: RPS, error-rate (за класами), latency p95/p99 per-route/cluster.
Outlier/health: кількість еджектів/повторних включень, slow-call-rate.
Логи: структуровані, без PII; кореляція'trace _ id '/' span _ id'.
Трейсинг (OTel): спани ingress→router→upstream; exemplars на графіках p99.

11) Приклади конфігурацій

11. 1 NGINX: host/path/weighted + кеш

nginx map $http_x_canary $canary { default 0; "1" 1; }
upstream app_v1 { least_conn; server 10. 0. 0. 1:8080 max_fails=3 fail_timeout=10s; }
upstream app_v2 { least_conn; server 10. 0. 0. 2:8080; }

server {
listen 443 ssl http2;
server_name api. example. com;

Кэш proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=apicache:256m max_size=10g inactive=10m use_temp_path=off;

location /v1/ {
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Request-ID $request_id;
proxy_read_timeout 300ms; proxy_connect_timeout 100ms;

Weighted: 5% on v2 if canary = 1, otherwise 0%
set $backend app_v1;
if ($canary) { set $backend app_v2; }
proxy_pass http://$backend;
}

Static with cache location/assets/{
proxy_cache apicache;
proxy_cache_valid 200 10m;
add_header Cache-Control "public, max-age=600";
proxy_pass http://static_cluster;
}
}

11. 2 Envoy: header-routing, canary, outlier-ejection, mirroring

yaml static_resources:
clusters:
- name: svc_v1 type: STRICT_DNS lb_policy: LEAST_REQUEST outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50
- name: svc_v2 type: STRICT_DNS lb_policy: LEAST_REQUEST
- name: mirror_svc type: STRICT_DNS

listeners:
- name: https filter_chains:
- filters:
- name: envoy. filters. network. http_connection_manager typed_config:
route_config:
virtual_hosts:
- name: api domains: ["api. example. com"]
routes:
- match:
prefix: "/v1"
headers:
- name: "X-Region"
exact_match: "eu"
route:
cluster: svc_v1 timeout: 350ms retry_policy:
retry_on: connect-failure,reset,5xx num_retries: 1 per_try_timeout: 200ms request_mirror_policies:
- cluster: mirror_svc runtime_key: mirror. enabled
- match: { prefix: "/v1" }
route:
weighted_clusters:
clusters:
- name: svc_v1 weight: 95
- name: svc_v2 weight: 5

11. 3 Traefik: rules + middleware

yaml http:
routers:
api:
rule: "Host(`api. example. com`) && PathPrefix(`/v1`)"
service: svc middlewares: [hsts, compress]
middlewares:
hsts:
headers:
stsSeconds: 31536000 stsIncludeSubdomains: true compress:
compress: {}
services:
svc:
weighted:
services:
- name: v1 weight: 95
- name: v2 weight: 5

11. 4 Kubernetes: Ingress + маніфест для canary (NGINX Ingress)

yaml apiVersion: networking. k8s. io/v1 kind: Ingress metadata:
name: api annotations:
nginx. ingress. kubernetes. io/canary: "true"
nginx. ingress. kubernetes. io/canary-weight: "5"
spec:
rules:
- host: api. example. com http:
paths:
- path: /v1 pathType: Prefix backend:
service:
name: svc-v1 port: { number: 8080 }

12) Трансформації та сумісність

Нормалізація заголовків/шляхів, перепис'Location', управління'Cache-Control'.
gRPC ↔ HTTP/JSON через транслятори (grpc-json-transcoder).
WebSocket/HTTP2 upgrades: переконатися, що проксі пропускає «Upgrade »/« Connection».

13) Тестування та хаос-сценарії

Навантажувальні: бурсти, довгі плато, «довгі» тіла (slow-POST).
Ін'єкція затримок/втрат до апстрімів → перевірка retries/timeout/outlier.
Canary-метрики: p95/p99, error-rate нової версії vs старої; автоматичний rollback по SLO.
Shadow: порівняння відповідей (семплювання) і side-by-side-логіка.

14) Антипатерни

Глобальні ретраї без урахування ідемпотентності і дедлайну → дублі і шторм.
Sticky-сесії без контролю «гарячих» шардів → перекіс навантаження.
Відсутність health-checks/outlier-ejection → «гнилі» інстанси в пулі.
Безлімітні заголовки/тіла → найпростіший DoS.
Змішування трансформацій і безпеки без версії схем → несподівані регреси.
Єдиний глобальний кеш-ключ без'Vary'→ невірні відповіді.

15) Специфіка iGaming/фінансів

Регіональність: маршрутизація по юрисдикції гравця/бренду; ізоляція зон виплат.
Критичні маршрути (депозити/висновки): короткі таймаути, один повтор, ідемпотентність; окремі кластери.
PSP/KYC: виділені upstream-пули, суворі політики retry/timeout, circuit-breaker, гео-піни.
AB-канали: безпечні експерименти з виплатами/лімітами тільки для read-шляху; write - через прапори і малі відсотки.

16) Чек-лист prod-готовності

• TLS 1. 2+/1. 3, OCSP stapling, HSTS; коректні'X-Forwarded-'.
• Чіткі правила маршрутизації: host/path/header/cookie; Документація.
• Health-checks, outlier-ejection, per-try timeout, обмежені ретраї.
• Weighted/canary + shadow; авто-rollback по SLO/алертам.
• Кеш/компресія/ETag; ліміти body/headers; request coalescing.
• Логи/трейси з'trace _ id'; метрики RED + outlier/health; дашборди per-route/cluster.
• WAF/бот-фільтри/CORS; захист від oversize і slow-POST.
• Sticky/consistent hashing там, де потрібно; контроль hot-шардів.
• Конфіги версіонуються, міграції безпечні, секрети в KMS/Vault.

17) TL; DR

Термінуйте TLS на периметрі і маршрутизуйте на L7 по host/path/header/cookie. Для релізів - weighted canary і shadow; для стійкості - health-checks, outlier-ejection, обмежені retries з per-try timeout. Використовуйте кеш, компресію і consistent hashing там, де це покращує p95. Міряйте RED-сигнали і стан кластерів, тримайте WAF і ліміти розмірів. Для критичних платіжних шляхів - окремі кластери, короткі SLA і суворе управління ретраями/ідемпотентністю.