Bilanciamento carico e failover

1) Obiettivi e termini

Il bilanciamento distribuisce il traffico tra istanze/aree/regioni per prestazioni e sostenibilità.
Failover - Failover gestito in caso di guasto.
RTO/RPO: tempo di ripristino mirato e perdita di dati accettabile.
SLO: target di disponibilità/latenza «porta» per il feeling automatico e il ripristino.

2) Livelli di bilanciamento

2. 1 L4 (TCP/UDP)

Prestazioni, semplicità, TLS passthrough Contro - Nessuna comprensione del percorso/cookie.
Esempi: NLB/GLB, HAProxy/Avvoy L4, IPVS.

2. 2 L7 (HTTP/gRPC)

Pro: instradamento su strada/header, pesi canari, sticky. Contro - più costoso per CPU/latenza.
Esempi: NGINX/HAProxy/Avvoy/Cloud ALB/API Gateway.

2. 3 Livello globale

Risposta GNS/GSLB: health-checks + geo/ponderato.
Anycast/BGP: un IP in tutto il mondo, il punto più vicino dell'annuncio.
CDN/Edge: cash/feelover nel perimetro.

3) Algoritmi di distribuzione

Round-robin/weighted sono di base.
Least connection/latency - per le richieste «pesanti».
Consistent hasing - Adesivo a chiave (user/tenant) senza sessione centrale.
Hash-based locality - per la cache e i servizi stateful.

4) Sessioni e adesività (sticky)

Cookie-sticky: L7 LB installa i cookie per tornare all'istanza.
Src-IP sticky: su L4, peggio con NAT/CGNAT.
Consistent hasing: meglio per cache/chat orizzontali.
Aim: se possibile, fai il servizio stateless, altrimenti - estrai lo stato (sessioni in Redis/DB) per semplificare la failover.

5) Affidabilità: health-checks e disinstallazione

Active checks: HTTP 200/test profondi del percorso aziendale (ad esempio, '/healthz/withdraw ', con dipendenze).
Passive (outlier detection) - Esegue backend a 5xx/timeout.
Warm-up - Abilita le nuove istanze (slow-start).
Graceful drain - Rimuovi dal pool in attesa del completamento delle richieste.

NGINX (esempio):

nginx upstream api {
zone api 64k;
least_conn;
server app-1:8080 max_fails=2 fail_timeout=10s;
server app-2:8080 max_fails=2 fail_timeout=10s;
keepalive 512;
}
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 2;

Avvoy outlier detection (sezione):

yaml outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

6) Gestione dei guasti: timeout/retry/circuito-breaking

Timeouts: più breve del timeout del cliente; Imposta per-route.
Retries: 1-2 con jitter e idipotenza; divieto di ritrae su POST senza chiavi idempotenza.
Circuito breaker: limitazione delle richieste o degli errori simultanei; recupero «semiaperto».
Budgets: limiti di retro/fusione di burst per non creare self-DDOS.

7) Kubernets-pattern

I ClusterIP/NodePort/LoadBalancer/Ingress sono i primitivi di base.
Readover/Liveness - Traffico solo per i sottoboschi finiti.
PodDisruptionBudget di non far cadere contemporaneamente N battute.
HPA/VPA: scalabilità CPU/RED metriche, collegamento con LB.
ServiceTopology/Topology Aware Hins - Località per zona.
Servizio type=LoadBalancer: almeno 2 repliche per AZ.

Esempio di readoverper un percorso critico:

yaml readinessProbe:
httpGet: { path: /healthz/dependencies, port: 8080 }
periodSeconds: 5 failureThreshold: 2

8) Traffico incrociato e crociato-regionale

Multi-AZ (all'interno della regione) - Distribuire equamente (zonal LB) e memorizzare le repliche sincrone.

Multi-region:

Active-Active: entrambe le regioni gestiscono il traffico più complessa: è necessario replicare i dati, coerenza e instradamento geografico.
Active-Passive: la regione principale serve, la riserva è calda/calda/fredda. Più semplice, più veloce, ma superiore alla RPO.

strategie GSLB:

Geo-DNS (regione più vicina).
Weighted DNS (canarini/ridistribuzione).
Latency-based (misure RTT).
Failover = in base ai segnali di salute/disponibilità (propes da più punti vant).

9) Dati e failover

Cache/state: regionale, se possibile; per Active-Active - CRDT/hash consistenti.

OBD:

Replica sincrona = RPO basso, latenza superiore.
Latitudine asincrona = inferiore, ma RPO> 0.
Code: mirroring/topic multiclaster; deduplicazione degli eventi.
Progettare l'idampotenza delle operazioni e la meccanica replay.

10) Perimetro: DNS/Anycast/BGP/CDN

DNS: TTL breve (30-60s) + health-checks fuori dalla rete.
Anycast: più ROR con un solo IP - Il più vicino accetta il traffico, il feelover a livello di instradamento.
CDN/Edge: cache e gateway per la protezione, statica/media in caso di caduta origin; origin-shield + пер-POP health.

11) Campioni di configurazione

HAProxy L7:

haproxy defaults timeout connect 2s timeout client 15s timeout server 15s retries 2 option redispatch

backend api balance leastconn option httpchk GET /healthz/dependencies http-check expect status 200 server app1 app-1:8080 check inter 5s fall 2 rise 2 slowstart 3000 server app2 app-2:8080 check inter 5s fall 2 rise 2 slowstart 3000

NGINX sticky по cookie:

nginx upstream api {
hash $cookie_session_id consistent;
server app-1:8080;
server app-2:8080;
}

Envoy retry/timeout (route):

yaml route:
timeout: 2s retry_policy:
retry_on: 5xx,connect-failure,reset num_retries: 1 per_try_timeout: 500ms

12) Failover automatico: segnali e gate

T-SLI: 5xx-rate, p95/p99, saturation, handshack TLS, TCP resets.
Business SLI: successo di depositi/pagamenti, nessun errore di pagamento per PSP.
Se superate le soglie, disattivare la zona/istanza, aumentare il peso del pool stabile, cambiare la GSLB.
Runbook - Istruzioni passo passo per passo e ritorno (rollback).

13) Test e ispezioni (chaos & game-days)

Test Chaos: disattivazione di AZ/regioni, degrado del database/cache, simulazione packet-loss.
Game-day - Un feeling che coinvolge i team.
Diagnostica: traccia da perimetro a backend, mappatura delle annotazioni di output e metriche.

14) Sicurezza e compliance

mTLS tra i LB↔servisy, WAF/Rate limits sul perimetro.
Zone di errore/segmentazione - Isolamento blast-radius.
Criteri: disattivazione dei singoli punti di guasto (SPOF), requisiti per «minimo N repliche/AZ».

15) Anti-pattern

Una zona LB per tutto il traffico prod (SPOF).
Nessuna verifica approfondita dì/healthz "(verde - ma database/coda non disponibile).
Il Retrai non è idepotente a prendere transazioni/pagamenti.
Sticky per IP con NAT di massa si è verificato uno squilibrio.
Failover DNS con TTL elevato (orologi pre-failover).
Nessun graceful drain in caso di deposito - diradamento delle richieste.

16) Assegno foglio di implementazione (0-45 giorni)

0-10 giorni

Separare le istanze di ≥2 AZ; attivare readava/liveness, health-checks.
Configura L7-timeouts/retries (1 tentativo), outlier detection.
Abilita graceful drain e slow-start.

11-25 giorni

Inserisci GSLB (geo/weighted) o Anycast per il perimetro.
Pesi canari/regole di percorrenza; sticky tramite cookie/consistent hash.
SLO-gate per il feeling automatico (p95/5xx + business SLI).

26-45 giorni

DR regionale: Active-Active o Active-Passive con test di traduzione.
Giorni chaos con disattivazione AZ/regioni, report RTO/RPO.
Runbook automatizzati e (script pausa/shift/rollback).

17) Metriche di maturità

La copertura Multi-AZ è ≥ al 99% dei percorsi critici.
DNS/GSLB/Anycast sono incorporati per endpoint pubblici.
MTTR in caso di caduta di un AZ <5 minuti (p95).
RPO per i dati critici di destinazione (ad esempio, 30 secondi).
Game-days trimestrali e feelover pianificato di successo.

18) Conclusione

Bilanciamento e failover affidabili sono le regole L7 locali (timeouts/retries/CB, health-checks), l'adesività e l'hash corretti, la stabilità delle zone crociate e GSLB/DNS/Anycast sul perimetro. Aggiungi SLO-gate, idampotenza, graceful drain e test chaos regolari - e qualsiasi perdita di nodo, zona o anche regione diventa un evento gestibile con RTO/RPO prevedibile.

Bilanciamento carico e failover