Kaj je CDN cache invalidation

Uvod v CDN predpomnjenje

Content Delivery Network (CDN) deluje tako, da hrani kopije vaše vsebine na edge strežnikih po vsem svetu in jih uporabnikom postreže z najbližjega strežnika, namesto da bi vsaka zahteva šla do vašega izvornega strežnika. To dramatično zmanjšuje latenco in pospeši nalaganje spletne strani za uporabnike ne glede na to, kje se nahajajo. Vendar pa predpomnjenje prinaša temeljni izziv - kako zagotoviti, da uporabniki vedno vidijo najnovejšo različico vsebine, ko naredite spremembe na spletni strani.

Cache invalidation je proces odstranjevanja ali zamenjave zastarele vsebine iz CDN predpomnilnika. Phil Karlton je nekoč rekel, da v računalništvu obstajata samo dve težki stvari: poimenovanje stvari in cache invalidation. Ta izjava popolnoma ponazarja, kako kompleksno je upravljanje predpomnilnika, saj lahko vsaka napačna odločitev privede do tega, da uporabniki vidijo zastarelo vsebino ali da se izvorni strežnik po nepotrebnem obremenjuje, ker je predpomnilnik preagresivno očiščen.

Kako deluje CDN predpomnilnik

Ko uporabnik prvič zahteva vir, ki ni v predpomnilniku, CDN zahtevo posreduje izvornemu strežniku, dobi odgovor in shrani kopijo na svojem edge strežniku. Vsaka naslednja zahteva za isti vir z istega edge strežnika se postreže neposredno iz predpomnilnika brez kontaktiranja izvora. Izvorni strežnik nadzira vedenje predpomnilnika prek HTTP glav, kot so Cache-Control, Expires, ETag in Last-Modified.

Ključne HTTP glave za predpomnjenje

• Cache-Control: max-age=3600 - vir je svež naslednjih 3600 sekund (1 uro)
• Cache-Control: s-maxage=86400 - specifično za skupne predpomnilnike (CDN), prednost pred max-age
• Cache-Control: no-cache - predpomnilnik mora pred postrežbo revalidirati z izvorom
• Cache-Control: no-store - vir se nikoli ne sme predpomniti
• ETag - edinstven identifikator različice vira za revalidacijo
• Vary - določa, po katerih glavah se razlikujejo predpomnjene različice

Razumevanje teh glav je ključno, saj določajo pravila, po katerih se CDN odloča, ali postreči predpomnjeno različico ali zahtevati novo od izvornega strežnika. Napačno nastavljene glave so najpogostejši vzrok težav z zastarelo vsebino ali po nepotrebnem pogostimi zahtevami do izvora.

Cache purging - ročno čiščenje predpomnilnika

Cache purging je najbolj neposreden način za odstranjevanje vsebine iz CDN predpomnilnika. Večina CDN ponudnikov ponuja API in dashboard za ročno sprožanje purge operacij. Lahko počistite posamezen URL, skupino URL-jev po vzorcu (wildcard purge) ali celoten predpomnilnik vseh virov. Vsak od teh pristopov ima svoje prednosti in slabosti glede na situacijo.

Vrste purge operacij

Single URL purge je najnatančnejša in najhitrejša metoda, saj cilja natančno en vir. Uporabite ga, ko posodabljate eno stran ali datoteko. Wildcard purge briše vse vire, ki ustrezajo določenemu vzorcu, na primer /blog/* briše vse blog strani iz predpomnilnika. To je uporabno, ko posodabljate večje število strani, vendar ne želite počistiti celotnega predpomnilnika. Full purge briše absolutno vse iz predpomnilnika in ga je treba uporabljati samo v nujnih primerih, saj začasno povečuje obremenitev izvornega strežnika, medtem ko se predpomnilnik znova gradi.

Purge operacije se običajno razširijo skozi CDN omrežje v 1 do 30 sekundah, odvisno od ponudnika in velikosti omrežja. Cloudflare omrežje purge se razširi v približno 30 sekundah globalno, medtem ko AWS CloudFront lahko zahteva do 15 minut za wildcard invalidacije. Vedno imejte v mislih to zakasnitev, ko delate spremembe na produkciji in testirate, ali je nova različica vidna.

TTL strategije

Time-To-Live (TTL) določa, kako dolgo CDN šteje predpomnjeno vsebino za svežo, preden zahteva novo različico od izvora. Pravilna nastavitev TTL je ravnovesje med zmogljivostjo (daljši TTL = manj zahtev do izvora) in svežino vsebine (krajši TTL = hitreje se vidijo spremembe). Ne obstaja univerzalno pravilen TTL, saj je odvisen od vrste vsebine in kako pogosto se spreminja.

Priporočen TTL po vrsti vsebine

• Statična sredstva (JS, CSS, pisave) - 1 leto (31536000s) z verzioniranjem datotek
• Slike - 30 dni (2592000s) z ETag revalidacijo
• HTML strani - 5 minut do 1 ura, odvisno od dinamičnosti
• API odgovori - 0 do 60 sekund, odvisno od podatkov
• Favicon in robots.txt - 1 dan (86400s)

Direktiva stale-while-revalidate je odlična strategija, ki CDN omogoča, da uporabnikom postreže zastarelo vsebino, medtem ko v ozadju hkrati zahteva novo različico od izvora. To pomeni, da uporabnik nikoli ne čaka na izvorni strežnik, vendar bo novo različico videl že ob naslednji zahtevi. Na primer Cache-Control: max-age=60, stale-while-revalidate=3600 pomeni, da je vsebina sveža 60 sekund, vendar se lahko postreže iz predpomnilnika naslednjo uro, medtem ko se v ozadju osvežuje.

Verzioniranje virov

Verzioniranje virov je najbolj elegantna strategija za reševanje cache invalidation težave, saj popolnoma odpravi potrebo po eksplicitnih purge operacijah. Namesto spreminjanja vsebine datoteke na istem URL-ju vsaka nova različica dobi nov URL, kar pomeni, da CDN samodejno postreže novo različico, saj jo obravnava kot popolnoma nov vir, ki še ni v predpomnilniku.

Metode verzioniranja

Content hash v imenu datoteke je najpopularnejša metoda. Build orodja, kot so Webpack, Vite in Next.js, samodejno dodajajo hash vsebine v ime datoteke, na primer style.a1b2c3d4.css. Ko se CSS spremeni, se hash spremeni in generira se nova datoteka z novim imenom. Stara različica ostane v predpomnilniku, vendar je nihče več ne referencira, saj HTML zdaj kaže na novo datoteko.

Verzioniranje query stringa (style.css?v=1.2.3) je preprostejši pristop, vendar manj zanesljiv, saj nekateri CDN ponudniki query stringe pri predpomnjenju ignorirajo. Uporabljajte ga samo, če nimate možnosti spreminjanja imena datoteke. Verzioniranje poti (/v2/style.css) je še ena možnost, ki zanesljivo deluje z vsemi CDN ponudniki, vendar zahteva več konfiguracije na strežniku.

Kdaj invalidirati predpomnilnik

Vedeti, kdaj je treba invalidirati predpomnilnik, je enako pomembno kot vedeti, kako to storiti. Najpogostejši scenariji, ki zahtevajo invalidacijo, vključujejo deploy nove različice spletne strani na hosting strežnik, popravek kritične napake v vsebini, odstranitev občutljive vsebine, ki je bila pomotoma objavljena, in spremembo cene ali razpoložljivosti izdelka v e-commerce trgovini. V vseh teh primerih morajo uporabniki čim prej videti posodobljeno vsebino.

Najboljše prakse za invalidacijo

• Avtomatizirajte - integrirajte cache purge v CI/CD pipeline za samodejno invalidacijo ob vsakem deployu
• Bodite natančni - ciljajte konkretne URL-je namesto full purge, kadarkoli je mogoče
• Uporabljajte verzioniranje - za statična sredstva popolnoma odpravi potrebo po ročni invalidaciji
• Spremljajte - spremljajte cache hit ratio, da odkrijete težave s konfiguracijo
• Testirajte - z curl -I preverite glave, da potrdite, da predpomnjenje deluje, kot pričakujete
• Dokumentirajte - zabeležite vrednosti TTL in strategijo invalidacije za vsako vrsto vsebine

Pogoste težave in rešitve

Ena najpogostejših težav je tako imenovana stale content, kjer uporabniki vidijo zastarelo vsebino kljub temu, da ste naredili spremembe na izvornem strežniku. Vzrok je običajno predolg TTL brez mehanizma za invalidacijo. Rešitev je kombinacija razumnega TTL z avtomatiziranimi purge operacijami ob deployu. Druga pogosta težava je cache stampede, kjer po izteku TTL za priljubljen vir stotine sočasnih zahtev hkrati zadenejo izvorni strežnik. Rešitev je request coalescing, kjer CDN pošlje samo eno zahtevo do izvora, vse ostale zahteve pa zadrži, dokler ne dobi odgovora.

Težava z različnimi različicami vsebine na različnih edge strežnikih (cache inconsistency) nastane, ker se purge operacija ne more razširiti na vse strežnike hkrati. V kratkem obdobju po purgu bodo nekateri uporabniki videli staro, drugi pa novo različico. Za kritične spremembe uporabljajte mehanizem z verzioniranjem v URL-ju, ki zagotavlja doslednost, saj vsak uporabnik dostopa do natančno določene različice vira.