Proxy inverse et routage

1) Rôle du proxy inverse

Le proxy inverse est la « ligne de front » de la plate-forme : accepte TLS, répartit le trafic entre les apstrymes, applique des politiques de sécurité et de performance. L'objectif est une latence minimale, un routage prévisible et une isolation rapide des instances/zones dégradées.

2) Couches et protocoles

L4: TCP/UDP proxy (SNI-based TLS passthrough, QUIC). Prix bas, pas de compréhension HTTP.
L7: HTTP/1. 1–2–3, gRPC, WebSocket. Routage riche (host, path, headers, cookies), transformations et cache.

Modèle TLS : terminier sur le périmètre (NGINX/Envoy), à l'intérieur - mTLS/mesh. SNI permet aux hôtes virtuels sur une seule IP.

3) Stratégies de routage (L7)

1. Host-based : par domaine ('api. brand. com '→ cluster' 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 basé : Tests A/B, sessions « collantes ».
5. Weighted/Canary : pourcentage de trafic par nouvelle version (1-5 % → 100 %).
6. Geo/ASN : Par pays/ASN, nous dirigons vers la RR/région la plus proche.
7. Consistent hashing : ancre la clé (user_id/tenant_id) à l'instance → cache localité/collante.
8. Shadow/Mirroring : nous copions le trafic vers l'apstream « shadow » sans affecter la réponse (pour les tests de régression).

4) Équilibrage et tolérance aux pannes

Algorithmes : round-robin, least-request, random, ring-hash (consistance).
Health-checks : actif (HTTP/TCP) + passif (par code/temporisation).
Ejection Outlier : Temporairement « assommer » l'hôte avec une erreur/latence accrue.
Retries : limité, avec un timeout per-try et un gitter ; ne pas rétracter les méthodes dangereuses sans idempotence.
Connection pooling : garder les pools warm aux apstrymes, limiter les maxima.

5) Performance du périmètre

Mise en cache : par clé (method + host + path + Vary), conditions 'ETag/If-None-Match', TTL et stale-while-revalidate.
Compression : brotli/gzip pour les réponses textuelles.
HTTP/2/3 : multiplexage, header-compression ; s'assurer de la compatibilité WAF/IDS.
Request coalescing : Attraper des requêtes parallèles pour la même clé de cache.

6) Sécurité sur le proxy

TLS: 1. 2 + (mieux que 1. 3), OCSP stapling, HSTS.
WAF/filtres de bot : avant le routage vers l'app.
CORS/CSP/Fetch-Metadata : selon les politiques.
Header-гигиена: `X-Forwarded-For/Proto`, `Forwarded`, `traceparent`; protection contre l'injection et l'oversize.
Limites de body/headers : début 413/431 pour les modèles DoS.
mTLS pour les intégrations partenaires et les API internes.

7) Schémas de dépliage : canary/blue-green/versions

Weighted routing на level-7 (1%, 5%, 25%, 50%, 100%).
Header-gate : inclure le ficha par drapeau/titre (internal/testing).
Bleu-vert : basculement DNS complet/route, rollback rapide.
Shadow : exécution parallèle d'une nouvelle version avec enregistrement de métriques/logs.

8) Sticky-sessions et hachage routage

Cookie-stickiness (`Set-Cookie: SRV=shard-a; Path=/; httpOnly ') pour les charges stateful.
Ring-hash/consistent par 'user _ id/tenant _ id' - réduction des handicaps croisés du cache.
Mise en garde : éviter le collant « éternel » pour les charges de write → hot-spot ; utiliser un quota per-tenant.

9) Routage régional et géo

Anycast + géo-DNS pour sélectionner le POP le plus proche.
Header-override (par exemple, « X-Region ») pour les tests et le débogage.
Harmoniser avec la localisation légale des données (route par région/juridiction).

10) Observation et contrôle

Métriques RED : RPS, taux d'erreur (par classe), p95/p99 per-route/cluster.
Outlier/santé : nombre d'ejects/ré-inclusions, slow-call-rate.
Logs : structurés, sans PII ; la corulation 'trace _ id '/' span _ id'.
Tracing (OTel) : dormeurs de ingress→router→upstream ; exemples sur les graphiques p99.

11) Exemples de configurations

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 + manifeste pour le 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) Transformation et interopérabilité

Normaliser les en-têtes/chemins, recensement 'Location', contrôle 'Cache-Control'.
gRPC ↔ HTTP/JSON via des traducteurs (grpc-json-transcoder).
WebSocket/HTTP2 upgrade : assurez-vous que le proxy manque 'Upgrade '/' Connection'.

13) Tests et scénarios de chaos

Charge : burst, long plateau, corps « long » (slow-POST).
Injection de retard/perte dans les apstrymes → vérification de retries/timeout/outlier.
Métriques canaries : p95/p99, error-rate de la nouvelle version vs de l'ancienne ; rollback automatique par SLO.
Shadow : comparaison des réponses (échantillonnage) et side-by-side-logique.

14) Anti-modèles

Les retraits mondiaux sans tenir compte de l'idempotence et de la dedline → les prises et les tempêtes.
Sticky-sessions sans contrôle des chardes « chaudes » → distorsion de charge.
Absence de checks/outler-ejection → instances « pourries » dans le pool.
Titres/corps illimités → DoS le plus simple.
Le mélange des transformations et de la sécurité sans version des schémas → des régressions inattendues.
Une clé cache globale unique sans 'Vary' → des réponses incorrectes.

15) Spécificités iGaming/Finance

Régionalité : routage selon la juridiction du joueur/marque ; isolement des zones de paiement.
Itinéraires critiques (dépôts/conclusions) : délais courts, répétition unique, idempotence ; les clusters individuels.
PSP/KYC : upstream pools dédiés, politiques strictes de retri/timeout, circuit-breaker, géo-pins.
Canaux AB : expériences sécurisées de paiement/limites uniquement pour la voie de lecture ; write - à travers les drapeaux et les petits pourcentages.

16) Chèque-liste prod-prêt

• TLS 1. 2+/1. 3, OCSP stapling, HSTS; correct « X-Forwarded- ».
• Règles de routage claires : host/path/header/cookie ; documentation.
• Health-checks, outlier-ejection, per-try timeout, retraits limités.
• Weighted/canary + shadow; auto-rollback par SLO/alerts.
• Cache/compression/ETag ; limites body/headers ; request coalescing.
• Logs/trajets avec 'trace _ id' ; métriques RED + outlier/santé ; dashboards per-route/cluster.
• WAF/filtres de bot/CORS ; protection contre l'oversize et le slow-POST.
• Sticky/consistent hashing là où il faut ; contrôle des chardes chaudes.
• Les configis sont versionnés, les migrations sont sûres, les secrets dans KMS/Vault.

17) TL; DR

Terminier TLS sur le périmètre et acheminer vers L7 par host/path/header/cookie. Pour les sorties - canary weighted et shadow ; pour la durabilité - health-checks, outlier-ejection, retries limitées avec per-try timeout. Utilisez le cache, la compression et le consistent hashing lorsque cela améliore votre p95. Mesurez les signaux RED et l'état des clusters, gardez le WAF et les limites de taille. Pour les voies de paiement critiques, des clusters distincts, des SLA courts et une gestion rigoureuse des retraits/idempotentielles.