I team che arrivano a Cloudflare Load Balancing da un ALB AWS spesso configurano tutto correttamente e poi riscontrano comportamenti che il loro modello mentale non spiega: un client continua ad arrivare alla stessa origine per minuti dopo che si è verificato un errore, la distribuzione del carico appare non uniforme tra le istanze e il failover richiede più tempo di quanto suggeriscono i controlli di integrità. Il prodotto funziona, ma in modo diverso dal previsto, perché opera sul DNS, non sul livello di trasporto o di applicazione.
Come funziona davvero il bilanciamento del carico di Cloudflare
Cloudflare Load Balancing è un servizio di distribuzione del traffico che interviene durante la risoluzione dei nomi. Quando un client effettua una query DNS per il dominio bilanciato, Cloudflare Authoritative valuta quali origini sono integre, applica la regola di controllo configurata e restituisce l'IP dell'origine selezionata. Da quel momento, il client si connette direttamente all'origine (o al PoP di Cloudflare, se la registrazione è proxy) e tutte le richieste provenienti da quella sessione vanno a quella destinazione fino alla scadenza del TTL e il client deve risolvere nuovamente il nome.
Ciò significa che la distribuzione del carico avviene tramite risoluzione DNS, non tramite richiesta HTTP. A due client simultanei che risolvono il dominio nello stesso secondo è possibile assegnare origini diverse. Un singolo client che risolve il nome una volta e mantiene aperta la connessione rimane sulla stessa origine indefinitamente. Se sono presenti dieci istanze in esecuzione dietro un ALB, l'ALB distribuisce le richieste tra di esse con ogni nuova richiesta. Con Cloudflare LB, la granularità è il cliente, non la richiesta.
Il sistema di controlli dello stato corregge il percorso quando una fonte fallisce. Cloudflare esegue controlli sanitari attivi da più PoP, non da un singolo punto, rispetto a ciascuna origine registrata. Quando la percentuale di errori supera la soglia configurata, l'origine viene contrassegnata come danneggiata e rimossa dal pool di risoluzione. I nuovi client che risolvono il proprio nome dopo questo tag non ricevono più l'IP dell'origine problematica. I client che hanno già risolto il nome e hanno l'IP memorizzato nella cache continuano a provare a connettersi fino alla scadenza del TTL. Il failover ha quindi due componenti di latenza: il tempo necessario al controllo dello stato per rilevare e contrassegnare l'errore e il TTL rimanente dei client che sono già stati risolti.
Il modello di prezzo e cosa copre
Il piano base di Cloudflare Load Balancing costa $ 5 al mese e include due pool di origine, cinque origini per pool e controlli sanitari configurabili. Il costo aggiuntivo di $ 0,50 per 500.000 query di controllo sanitario si applica al volume generato dai controlli: con intervalli di 60 secondi e distribuzione su più PoP, il volume mensile aumenta rapidamente, ma è ancora in un intervallo ragionevole per configurazioni attive-passive con piccoli pool.
Per una semplice configurazione attivo-passiva (un pool principale con due fonti e un pool di fallback) la fattura mensile è inferiore a $ 10 nella maggior parte degli scenari. Per architetture più elaborate con più pool regionali e controlli granulari dello stato per PoP, il costo aumenta, ma rimane competitivo rispetto al sovraccarico operativo derivante dalla gestione del failover manuale tra regioni.
Geo Steering: routing in base alla provenienza geografica del cliente
Geo Steering è la funzionalità che trasforma il Load Balancer in un vero e proprio layer di routing geografico. La configurazione associa regioni (continenti o paesi specifici) a pool di origini. I clienti brasiliani risolvono il dominio e ricevono l'IP di origine a San Paolo. I clienti europei ricevono l'IP di origine a Francoforte. L'autorità di Cloudflare identifica la posizione geografica del risolutore che ha effettuato la query e restituisce la risposta dal pool corrispondente.
Quando il pool regionale diventa non disponibile (tutte le origini in esso contenute contrassegnate come degradate) Cloudflare passa automaticamente al pool di fallback globale configurato. Il cliente europeo il cui pool di Francoforte è esterno riceve l'IP da San Paolo o da qualsiasi altro pool sano, senza intervento manuale. Questo meccanismo di fallback automatico è ciò che rende Geo Steering utile per l'elevata disponibilità geografica, non solo per l'ottimizzazione della latenza.
L'affinità della sessione cookie integra il routing geografico nei casi in cui la stessa istanza deve servire lo stesso client su più risoluzioni DNS. Cloudflare inserisce un cookie nella risposta HTTP che identifica l'origine selezionata e Load Balancer utilizza questo cookie per restituire il client alla stessa origine nelle risoluzioni successive, anche se il TTL è già scaduto. Per le applicazioni stateless ciò è irrilevante; Per le sessioni che archiviano il contesto nella memoria dell'istanza, è il meccanismo che impedisce l'interruzione dell'esperienza durante le normali risoluzioni TTL.
La distinzione che cambia il disegno dell'architettura
Un ALB opera al livello 7. Riceve connessioni TCP, ispeziona le intestazioni HTTP, applica le regole di instradamento del percorso e delle intestazioni e distribuisce ogni singola richiesta a un'istanza del pool backend. Vede ogni richiesta. Puoi eseguire il routing basato sul percorso: /api va a un gruppo di istanze, /static va a un altro. Può iniettare o modificare intestazioni. Ha visibilità sul corpo della richiesta se il protocollo lo consente.
Cloudflare LB non vede le richieste individuali. Risponde alle query DNS. Non c'è modo di controllare il percorso /api perché il percorso non esiste nemmeno a livello DNS: appare solo dopo che il client ha stabilito la connessione TCP con l'origine e ha inviato l'HTTP GET. Questa non è una limitazione accidentale; è la conseguenza naturale dell'operare sul protocollo sbagliato per quel livello di granularità.
Il modello che combina i due risolve problemi diversi ad ogni strato. Cloudflare LB si occupa dell'instradamento geografico e del failover tra regioni: i clienti in Brasile arrivano a San Paolo, i clienti in Europa arrivano a Francoforte e, se San Paolo fallisce, il traffico migra automaticamente. All'interno di ciascuna regione, un ALB o nginx distribuisce le richieste tra le istanze del pool, esegue l'instradamento basato sul percorso e gestisce il carico a livello di richiesta. I due coesistono senza conflitti perché risolvono problemi a diversi livelli dello stack.
Cosa significano i controlli di integrità per lo SLA di failover
La velocità del failover dipende da tre variabili: l'intervallo di controllo dello stato, il numero di errori consecutivi necessari per contrassegnare un'origine come danneggiata e il TTL del record DNS. Con controlli dello stato ogni 60 secondi e due errori consecutivi come soglia, il caso peggiore per il rilevamento è di 120 secondi. Aggiungendo il TTL, che per i record proxy è di 60 secondi, la finestra massima di failover è di circa 3 minuti.
La riduzione dell'intervallo di controllo dello stato accelera il rilevamento, ma aumenta il volume delle query addebitate. Il punto di pareggio dipende dallo SLA sulla disponibilità del servizio. Per i sistemi in cui sono accettabili 3 minuti di errore parziale (l'origine morta non serve nuovi client al momento del rilevamento, ma i client con cache attiva continuano a provare fino al TTL) la configurazione predefinita è adeguata. Per i sistemi in cui qualsiasi deviazione del traffico verso una fonte degradata è inaccettabile, la combinazione di TTL basso, controllo dello stato a breve intervallo e almeno due controlli PoP in parallelo riduce nella pratica la finestra a meno di 2 minuti.
Il punto che i team con background ALB sottovalutano è che Cloudflare LB non interrompe le connessioni attive quando un'origine viene contrassegnata come degradata. Smette di restituire quell'IP nelle nuove risoluzioni DNS. I client che hanno già l'IP memorizzato nella cache continuano a provare. Il timeout della connessione TCP o l'errore dell'applicazione è ciò che il client sperimenterà fino alla scadenza del TTL e una nuova risoluzione restituisce un IP integro. L'impatto effettivo dipende dalla frazione di client attivi con cache nuova rispetto a quella scaduta al momento dell'errore.
Leggi anche
- DNS Cloudflare: infrastruttura di rete che va ben oltre la risoluzione dei nomi
- DNS proxy vs solo DNS: cosa cambia e quando ciascuna modalità ha senso
- DNSSEC con Cloudflare: cosa protegge, cosa non protegge e come attivarsi senza problemi
- Instradamento email Cloudflare: ricevi email sul tuo dominio — e cosa non è incluso
- KV vs R2 vs Cache API: quando utilizzare ciascun livello di archiviazione Cloudflare
- Cloudflare KV: cosa significa distribuzione globale quando è necessario scrivere