Šta je CDN cache invalidation

Uvod u CDN keširanje

Content Delivery Network (CDN) radi tako što kešira kopije vašeg sadržaja na edge serverima širom svijeta i servira ih korisnicima sa najbližeg servera umjesto da svaki zahtev ide do vašeg origin servera. Ovo dramatično smanjuje latenciju i ubrzava učitavanje sajta za korisnike bez obzira gdje se nalaze. Međutim, keširanje donosi fundamentalni izazov - kako osigurati da korisnici uvijek vide najnoviju verziju sadržaja kada napravite izmjene na sajtu.

Cache invalidation je proces uklanjanja ili zamjene zastarelog sadržaja iz CDN keša. Phil Karlton je jednom rekao da postoje samo dvije teške stvari u računarstvu: imenovanje stvari i cache invalidation. Ova izjava savršeno ilustruje koliko je upravljanje kešom kompleksno jer svaka pogrešna odluka može rezultirati time da korisnici vide zastareli sadržaj ili da se origin server nepotrebno opterećuje jer je keš preagresivno cistit.

Kako CDN keš funkcioniše

Kada korisnik prvi put zatraži resurs koji nije u kešu, CDN prosleđuje zahtev origin serveru, dobija odgovor i čuva kopiju na svom edge serveru. Svaki sljedeći zahtev za isti resurs sa istog edge servera se servira direktno iz keša bez kontaktiranja origina. Origin server kontroliše ponašanje keša putem HTTP hedere kao što su Cache-Control, Expires, ETag i Last-Modified.

Ključni HTTP hederi za keširanje

• Cache-Control: max-age=3600 - resurs je svjež narednih 3600 sekundi (1 sat)
• Cache-Control: s-maxage=86400 - specifično za shared keseve (CDN), prioritet nad max-age
• Cache-Control: no-cache - keš mora revalidirati sa originom pre serviranja
• Cache-Control: no-store - resurs se nikada ne smije keširati
• ETag - jedinstveni identifikator verzije resursa za revalidaciju
• Vary - određuje po kojim hederima se razlikuju keširane verzije

Razumijevanje ovih hedera je ključno jer oni definišu pravila po kojima CDN odlučuje da li da servira keširanu verziju ili da zatraži novu od origin servera. Pogrešno podešeni hederi su najčešći uzrok problema sa zastarelim sadržajem ili nepotrebno čestim zahtevima ka originu.

Cache purging - ručno čišćenje keša

Cache purging je najdirektniji način za uklanjanje sadržaja iz CDN keša. Većina CDN provajdera nudi API i dashboard za ručno pokretanje purge operacija. Možete očistiti pojedinačni URL, grupu URL-ova po paternu (wildcard purge) ili kompletan keš svih resursa. Svaki od ovih pristupa ima svoje prednosti i mane u zavisnosti od situacije.

Tipovi purge operacija

Single URL purge je najprecizniji i najbrži metod jer cilja tačno jedan resurs. Koristite ga kada ažurirate jednu stranicu ili fajl. Wildcard purge briše sve resurse koji odgovaraju određenom paternu, na primjer /blog/* briše sve blog stranice iz keša. Ovo je korisno kada ažurirate veći broj stranica ali ne želite da očistite kompletan keš. Full purge briše apsolutno sve iz keša i treba ga koristiti samo u hitnim situacijama jer privremeno povećava opterećenje origin servera dok se keš ponovo gradi.

Purge operacije se obično propagiraju kroz CDN mrežu za 1 do 30 sekundi u zavisnosti od provajdera i veličine mreže. Cloudflare mreža purge se propagira za oko 30 sekundi globalno, dok AWS CloudFront može zahtevati do 15 minuta za wildcard invalidacije. Uvijek imajte na umu ovo kašnjenje kada radite promjene na produkciji i testirate da li je nova verzija vidljiva.

TTL strategije

Time-To-Live (TTL) određuje koliko dugo CDN smatra keširani sadržaj svježim pre nego što zatraži novu verziju od origina. Pravilno podešavanje TTL-a je balans između performansi (duži TTL = manje zahteva ka originu) i svezine sadržaja (kraći TTL = brže se vide promjene). Ne postoji univerzalno pravilan TTL jer on zavisi od tipa sadržaja i koliko često se menja.

Preporučeni TTL po tipu sadržaja

• Statični asseti (JS, CSS, fontovi) - 1 godina (31536000s) uz verzionisanje fajlova
• Slike - 30 dana (2592000s) sa ETag revalidacijom
• HTML stranice - 5 minuta do 1 sat u zavisnosti od dinamičnosti
• API odgovori - 0 do 60 sekundi u zavisnosti od podataka
• Favicon i robots.txt - 1 dan (86400s)

Stale-while-revalidate direktiva je odlična strategija koja omogućava CDN-u da servira zastareli sadržaj korisnicima dok istovremeno u pozadini zahteva novu verziju od origina. Ovo znači da korisnik nikada ne čeka na origin server ali će videti novu verziju već pri sljedećem zahtevu. Na primjer Cache-Control: max-age=60, stale-while-revalidate=3600 znači da je sadržaj svjež 60 sekundi, ali može biti serviran iz keša narednih sat vremena dok se u pozadini osvježava.

Verzionisanje resursa

Verzionisanje resursa je najelegantnija strategija za rešavanje cache invalidation problema jer potpuno eliminiše potrebu za eksplicitnim purge operacijama. Umjesto da menjate sadržaj fajla na istom URL-u, svaka nova verzija dobija novi URL što znači da CDN automatski servira novu verziju jer je tretira kao potpuno novi resurs koji još nije u kešu.

Metode verzionisanja

Content hash u imenu fajla je najpopularnija metoda. Build alati kao što su Webpack, Vite i Next.js automatski dodaju hash sadržaja u ime fajla, na primjer style.a1b2c3d4.css. Kada se CSS promijeni, hash se menja i generiše se novi fajl sa novim imenom. Stara verzija ostaje u kešu ali je niko više ne referencira jer HTML sada ukazuje na novi fajl.

Query string verzionisanje (style.css?v=1.2.3) je jednostavniji pristup ali manje pouzdan jer neki CDN provajderi ignorisu query stringove pri kesiravanju. Koristite ga samo ako nemate mogućnost da menjate ime fajla. Putanja verzionisanje (/v2/style.css) je još jedna opcija koja radi pouzdano sa svim CDN provajderima ali zahteva više konfiguracije na serveru.

Kada invalidirati keš

Znanje kada treba invalidirati keš je jednako važno kao i znanje kako to uraditi. Najčešći scenariji koji zahtevaju invalidaciju uključuju deploy nove verzije sajta na hosting serveru, ispravku kritične greške u sadržaju, uklanjanje osetljivog sadržaja koji je greskom objavljen i promjenu cijene ili dostupnosti proizvoda u e-commerce prodavnici. U svim ovim slučajevima korisnici moraju što pre videti ažuriran sadržaj.

Best practices za invalidaciju

• Automatizujte - integrišite cache purge u CI/CD pipeline za automatsku invalidaciju pri svakom deploy-u
• Budite precizni - ciljajte konkretne URL-ove umjesto full purge kad god je moguće
• Koristite verzionisanje - za statične asete potpuno eliminiše potrebu za ručnom invalidacijom
• Monitorisite - pratite cache hit ratio da biste otkrili probleme sa konfiguracijom
• Testirajte - provjerite hedere sa curl -I da biste potvrdili da keširanje radi kako očekujete
• Dokumentujte - zabilježite TTL vrijednosti i strategiju invalidacije za svaki tip sadržaja

Cesti problemi i rešenja

Jedan od najčešćih problema je takozvani stale content gdje korisnici vide zastareli sadržaj uprkos tome što ste napravili izmjene na origin serveru. Uzrok je obično predugacak TTL bez mehanizma za invalidaciju. Rešenje je kombinacija razumnog TTL-a sa automatizovanim purge operacijama pri deploy-u. Drugi česti problem je cache stampede gdje po isteku TTL-a za popularan resurs, stotine konkurentnih zahteva istovremeno pogode origin server. Rešenje je request coalescing gdje CDN šalje samo jedan zahtev ka originu a sve ostale zahteve zadržava dok ne dobije odgovor.

Problem sa različitim verzijama sadržaja na različitim edge serverima (cache inconsistency) nastaje jer purge operacija ne može da se propagira na sve servere istovremeno. Tokom kratkog perioda nakon purge-a neki korisnici će videti staru a neki novu verziju. Za kritične promjene koristite mehanizam sa verzionisanjem u URL-u koji garantuje konzistentnost jer svaki korisnik pristupa tačno definisanoj verziji resursa.