Cloudflare ha risolto il problema delle origini anycast

Cloudflare misura le latenze per dedurre la posizione reale delle origini anycast

C’è un dettaglio implementativo, nascosto in fondo a l’annuncio pubblicato lo scorso 10 luglio, che vale più di mille slide di marketing: per capire se un’origine è raggiungibile tramite anycast, Cloudflare confronta le latenze di probe inviati da più data center contemporaneamente. Sembra poco. In realtà è la chiave che sblocca Smart Tiered Cache for Public Cloud Regions, l’estensione della cache a livelli intermedi pensata specificamente per chi ospita origini su AWS, GCP, Azure o Oracle Cloud — e che nessun altro CDN, a quanto risulta, ha mai implementato in questa forma.

Il probe che svela l’anycast

Il problema che questa tecnica risolve è più insidioso di quanto sembri. Le regioni cloud pubbliche instradano il traffico verso i loro endpoint usando anycast: lo stesso indirizzo IP viene annunciato da più location fisiche, e chi vi si connette finisce sul nodo “più vicino” secondo le regole del BGP, non su un server fisso e identificabile. Per un CDN che vuole costruire una gerarchia di cache — un livello superiore (upper tier) che aggrega le richieste prima che raggiungano l’origine — questo è un problema serio: se non sai dove si trova realmente l’origine, non puoi scegliere con certezza quale tuo data center posizionare come intermediario ottimale.

La soluzione di Cloudflare aggira l’ostacolo capovolgendo la prospettiva. Invece di fidarsi della risoluzione anycast per dedurre una posizione geografica, il sistema effettua il rilevamento delle origini anycast misurando empiricamente da quali data center Cloudflare la latenza verso quell’origine è più bassa. È un approccio da manuale di networking pragmatico: non chiedere al protocollo cosa dovrebbe succedere, misura cosa succede davvero. Il confronto delle latenze di probe funziona come una sorta di triangolazione passiva, che permette di dedurre la topologia reale della rete anycast senza bisogno che il cliente dichiari manualmente dove si trova la sua origine cloud. Per chi gestisce infrastrutture distribuite su più provider, questo significa che il tiering intelligente smette di essere un’approssimazione basata su ipotesi geografiche e diventa una misurazione continua, aggiornata, resiliente ai cambi di routing che i cloud provider fanno silenziosamente ogni giorno. Ma questa non è che l’ultima mossa di un percorso iniziato anni fa.

Dalla prima cache intelligente alle origini cloud: l’evoluzione

Per capire la portata dell’annuncio, bisogna riavvolgere il nastro. Smart Tiered Cache non nasce ieri: il lancio originale risale al febbraio 2021, con l’obiettivo dichiarato di generare automaticamente la topologia di cache ottimale invece di lasciare che fossero gli operatori a configurarla a mano, POP per POP. Da lì, l’evoluzione è stata incrementale ma costante. A novembre 2024 il sistema è stato esteso al supporto di R2, lo storage object di Cloudflare: l’obiettivo era ridurre latenza e costi di egress rilevando automaticamente la posizione dei bucket e selezionando i tier superiori più efficienti, eliminando la necessità di configurazioni manuali per ogni combinazione di bucket e regione.

Il passo successivo, a gennaio 2025, ha affrontato un problema adiacente ma distinto: il bilanciamento del carico. Con il supporto per Smart Tiered Cache per Load Balancing, Cloudflare ha iniziato a selezionare automaticamente un singolo data center di livello superiore condiviso da tutti gli origin presenti in un pool di bilanciamento, invece di trattare ogni origine come un’entità isolata da ottimizzare separatamente. È un trade-off interessante: si rinuncia a una granularità perfetta origin-per-origin in cambio di una topologia di cache coerente e più semplice da ragionare, che evita la frammentazione della cache su troppi tier diversi quando gli origin di un pool sono comunque intercambiabili dal punto di vista applicativo. Con l’arrivo del supporto per le regioni cloud pubbliche, questa stessa filosofia — automatizzare la scoperta della topologia invece di chiedere all’utente di dichiararla — viene applicata al caso più ostico di tutti: origini che non hanno una sede fissa perché vivono dietro anycast. E mentre Cloudflare affina il meccanismo, i concorrenti restano al palo.

Cosa manca agli altri (e cosa cambia per te)

Basta guardare ai competitor per capire che il probing anycast non è un dettaglio da nota a piè di pagina, ma la differenza tra un sistema che si auto-configura e uno che scarica il problema sull’utente. Origin Shield di AWS CloudFront, per esempio, è progettato per funzionare bene quando l’origine si trova in una regione AWS nota e dichiarata: la documentazione stessa chiarisce che Origin Shield non risolve il problema di ambiguità anycast per origini multi-cloud, perché semplicemente non è quello il caso d’uso per cui è stato pensato. Funziona bene nel giardino recintato di AWS, molto meno se la tua origine vive altrove o dietro un indirizzo anycast che AWS non controlla.

Fastly non se la cava meglio. Il suo modello di shielding richiede ai clienti la configurazione manuale del POP shield da utilizzare: un approccio che funziona finché sai esattamente dove si trova la tua origine, ma che si sgretola nel momento in cui quella certezza viene meno. E secondo quanto emerge dalla stessa documentazione Fastly, il sistema non affronta affatto il problema dell’ambiguità delle origini anycast nel cloud — il che, tradotto in pratica operativa, significa che chi ospita su più provider cloud con indirizzamento anycast deve indovinare, testare, e ri-testare manualmente quale configurazione di shielding minimizzi la latenza. Ogni cambiamento nella topologia di rete del cloud provider rischia di rendere obsoleta quella configurazione dall’oggi al domani, senza che nessun meccanismo automatico se ne accorga.

La differenza pratica per chi progetta stack multi-cloud è tutt’altro che accademica. Meno configurazione manuale significa meno superficie per errori umani e meno debito tecnico da manutenere quando un provider cambia silenziosamente le proprie rotte anycast. Meno ambiguità nella topologia significa poter fidarsi che il livello di cache intermedio scelto dal sistema sia effettivamente quello ottimale, non un’approssimazione basata su assunzioni statiche fatte mesi prima. Per chi sviluppa su multi-cloud, l’arrivo di Smart Tiered Cache per Public Cloud Regions significa poter trattare le origini cloud come nodi intelligenti di una rete che si auto-organizza, non come endpoint statici da raggiungere per tentativi — un cambio di prospettiva piccolo sulla carta, ma che nella pratica operativa vale ore di debug risparmiate ogni volta che un cloud provider decide di riorganizzare, senza preavviso, la propria infrastruttura di rete.