Cloudflare
KV
Cloudflare KV
Consistência Eventual
Cache
Edge
Serverless

Cloudflare KV: cosa significa distribuzione globale quando è necessario scrivere

Come funziona nella pratica l'architettura coerente di Cloudflare KV, per quali carichi di lavoro è progettata e dove ti riporterà in produzione.

Cloudflare KV: cosa significa distribuzione globale quando è necessario scrivere

Cloudflare KV viene venduto come negozio distribuito a livello globale e tale descrizione è tecnicamente corretta. Ciò che tralascia è che "distribuito a livello globale" si applica completamente alle letture e solo parzialmente alle scritture, con un ritardo fino a 60 secondi che cambia tutto su come dovresti usarlo.

Quando scrivi una chiave per KV, la scrittura va a un negozio centrale. Da lì, si propaga a tutti i punti di presenza Cloudflare: più di 300 PoP distribuiti a livello globale. Questa propagazione non è istantanea. La documentazione ufficiale indica fino a 60 secondi affinché tutti i PoP ricevano il nuovo valore. Durante questa finestra, un Lavoratore che corre a Francoforte può restituire il vecchio valore mentre un Lavoratore a San Paolo vede già quello nuovo. Due lavoratori nella stessa regione potrebbero divergere se uno di loro non ha ancora ricevuto l'aggiornamento.

Questa è la coerenza finale. Cloudflare documenta chiaramente questo comportamento, ma la frase "distribuito globalmente" è abbastanza seducente da indurre molti team a non leggere quella parte finché non eseguono il debug di un bug in produzione.

Cosa succede in una lettura

La lettura in KV ha due percorsi e la differenza tra loro è importante per la latenza. Quando un lavoratore fa env.MY_KV.get('chave'), il runtime controlla se quella chiave è memorizzata nella cache nel PoP che sta servendo la richiesta. Se lo è, e lo sarà la maggior parte dei tasti di scelta rapida, la lettura ritorna in meno di un millisecondo, direttamente dalla memoria PoP. Questo è il percorso felice ed è ciò che rende KV eccezionalmente veloce nelle letture.

Se la chiave non è memorizzata nella cache in quel PoP, perché è una chiave nuova, perché è stata scritta di recente e non si è ancora propagata o perché il PoP semplicemente non ha ricevuto quell'input, il runtime cerca nell'archivio centrale. Ciò aggiunge circa 20 ms. Non è drammatico, ma è misurabile e vedrai questo numero apparire in traccia quando la chiave è fredda.

Il dettaglio che genera sorpresa: non c'è alcuna garanzia di lettura-tua-scrittura. Scrivi una chiave e provi immediatamente a leggerla nella stessa invocazione di Worker. La lettura potrebbe restituire il valore precedente. Questo comportamento è documentato e intenzionale: è una conseguenza diretta dell'architettura di memorizzazione nella cache PoP. Se hai bisogno di leggere le tue scritture, KV non è lo strumento giusto per quel flusso.

Per quale carico di lavoro è stato costruito il KV

L'architettura KV ha perfettamente senso quando si conosce il problema che risolve: dati scritti a bassa frequenza e letti ad altissima frequenza. Il modello economico rafforza questo modello. Le letture costano $ 0,50 per milione dopo i primi 10 milioni gratuiti mensili. Le riscrizioni costano $ 0,50 per milione dopo il primo milione gratuito. Nel livello gratuito hai 100mila letture al giorno e solo 1mila scritture al giorno.

I costi e i limiti indicano lo stesso carico di lavoro: scrivere poco, leggere molto. I flag di funzionalità sono l'esempio canonico. Un file JSON con i flag dei prodotti cambia al massimo alcune volte al giorno. Ma viene letto da ogni richiesta di ogni Lavoratore in ogni PoP nel mondo. Una propagazione di 60 secondi è accettabile per un flag: non è necessario che tutti gli utenti del pianeta vedano la funzione nello stesso millisecondo. Il numero di letture, potenzialmente miliardi al mese, viene memorizzato nella cache a un costo minimo.

Lo stesso ragionamento si applica ai modelli HTML renderizzati, alla configurazione dell'applicazione, ai dati di catalogo con una bassa frequenza di aggiornamento e ai token di sessione con un TTL definito. Scrivi una volta, leggi decine di migliaia di volte e KV lo fornisce con la latenza della cache.

Dove ti tradirà KV

Qualsiasi carico di lavoro che richiede coerenza immediata produrrà bug se implementato su KV. Il caso più comune è una sessione utente con stato modificabile. L'utente si disconnette; scrivi il flag di sessione non valida in KV; nei successivi 60 secondi un PoP diverso potrà ancora autenticare le richieste con il vecchio token perché non ha ricevuto l'aggiornamento.

I contatori accurati sono un altro punto di fallimento. KV non ha operazioni atomiche: non c'è confronto e scambio, non c'è incremento atomico. Due lavoratori che leggono simultaneamente lo stesso contatore leggeranno lo stesso valore, aumenteranno in modo indipendente e uno degli incrementi andrà perso. Per i contatori di limitazione della velocità che devono essere accurati, KV è lo strumento sbagliato. Per questo caso esistono oggetti durevoli.

Anche i dati che cambiano per richiesta non si adattano. Se ogni risposta all'utente modifica un valore nel KV, si pagano 0,50 dollari per milione di scritture in un volume che può essere gigantesco, con una latenza di ~150 ms per scrittura per la conferma nell'archivio centrale, più un ritardo di propagazione. Il costo si ridimensiona in un modo che non ha senso economico e la latenza di scrittura apparirà nella coda p99 delle tue richieste.

Per una coerenza immediata per chiave con bassa latenza di scrittura, D1 con l'API Sessions è il percorso attuale di Cloudflare. Per lo stato condiviso che richiede operazioni atomiche, Oggetti durevoli.

Il modello di costo senza illusioni

Il livello gratuito è generoso per la sperimentazione ma limitato per la produzione di qualsiasi volume. 100.000 letture al giorno equivalgono a poco più di 1 richiesta costante al secondo: un'applicazione reale con un traffico ragionevole supera quella in minuti.

Nel livello a pagamento, ciò che cambia è che le letture sono praticamente gratuite su larga scala. $ 0,50 per milione di letture sono abbastanza economici da non apparire come una riga rilevante in bolletta se il tuo carico di lavoro è adeguatamente carico di letture. Le scritture a $ 0,50 al milione, con 1 milione gratuito al mese, coprono la maggior parte degli standard e dei flag di configurazione senza costi significativi.

Ciò che potrebbe sorprenderti è lo spazio di archiviazione: $ 0,50 per GB al mese in aggiunta al primo GB gratuito. Per valori piccoli – configurazione JSON, token, flag – difficilmente toccherai questo limite. Per coloro che intendono archiviare file binari di dimensioni considerevoli in KV (il limite per valore è 25 MB), iniziano a comparire i costi di archiviazione. Per file di grandi dimensioni, R2 a $ 0,015/GB ha più senso.

Cosa KV risolve bene e cosa no

KV è uno strumento di lettura ad alte prestazioni con scrittura occasionale. Quando si sceglie questo modello, si ottiene una latenza inferiore al millisecondo per le letture a caldo, una distribuzione globale automatica senza impostare la replica e un modello di prezzi che favorisce le letture di volumi massicci.

L'errore non è usare KV: usarlo come se fosse un database generico. Nessuno strumento sostituisce la corretta diagnosi del carico di lavoro. Se i tuoi dati cambiano frequentemente per utente, richiedono atomicità o coerenza immediata, KV non fornirà risultati e lo scoprirai in produzione, non in sviluppo.

Leggi anche