Šta je CDN cache invalidation

Uvod u CDN keširanje

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

Cache invalidation je proces uklanjanja ili zamene zastarelog sadržaja iz CDN kesa. Phil Karlton je jednom rekao da postoje samo dve teške stvari u računarstvu: imenovanje stvari i cache invalidation. Ova izjava savršeno ilustruje koliko je upravljanje kesom 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 kes preagresivno cistit.

Kako CDN kes funkcioniše

Kada korisnik prvi put zatrazi resurs koji nije u kesu, CDN prosleđuje zahtev origin serveru, dobija odgovor i čuva kopiju na svom edge serveru. Svaki sledeći zahtev za isti resurs sa istog edge servera se servira direktno iz kesa bez kontaktiranja origina. Origin server kontrolise ponašanje kesa 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 svez narednih 3600 sekundi (1 sat)
• Cache-Control: s-maxage=86400 - specifično za shared keseve (CDN), prioritet nad max-age
• Cache-Control: no-cache - kes mora revalidirati sa originom pre serviranja
• Cache-Control: no-store - resurs se nikada ne sme kesirati
• ETag - jedinstveni identifikator verzije resursa za revalidaciju
• Vary - određuje po kojim hederima se razlikuju kesirane verzije

Razumevanje ovih hedera je ključno jer oni definisu pravila po kojima CDN odlucuje da li da servira kesiranu verziju ili da zatrazi novu od origin servera. Pogrešno podešeni hederi su najčešći uzrok problema sa zastarelim sadržajem ili nepotrebno cestim zahtevima ka originu.

Cache purging - ručno čišćenje kesa

Cache purging je najdirektniji način za uklanjanje sadržaja iz CDN kesa. 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 kes 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 brise sve resurse koji odgovaraju određenom paternu, na primer /blog/* brise sve blog stranice iz kesa. Ovo je korisno kada ažurirate veći broj stranica ali ne želite da očistite kompletan kes. Full purge brise apsolutno sve iz kesa i treba ga koristiti samo u hitnim situacijama jer privremeno povećava opterećenje origin servera dok se kes 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. Uvek imajte na umu ovo kasnjenje kada radite promene 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 svezim pre nego što zatrazi 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 (kraci TTL = brže se vide promene). 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 ceka na origin server ali će videti novu verziju već pri sledećem zahtevu. Na primer Cache-Control: max-age=60, stale-while-revalidate=3600 znači da je sadržaj svez 60 sekundi, ali može biti serviran iz kesa narednih sat vremena dok se u pozadini osvezava.

Verzionisanje resursa

Verzionisanje resursa je najelegantnija strategija za rešavanje cache invalidation problema jer potpuno eliminise potrebu za eksplicitnim purge operacijama. Umesto 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 kesu.

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 primer style.a1b2c3d4.css. Kada se CSS promeni, hash se menja i generiše se novi fajl sa novim imenom. Stara verzija ostaje u kesu 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 kes

Znanje kada treba invalidirati kes 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 promenu cene ili dostupnosti proizvoda u e-commerce prodavnici. U svim ovim slučajevima korisnici moraju što pre videti azuriran sadržaj.

Best practices za invalidaciju

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

Cesti problemi i rešenja

Jedan od najčešćih problema je takozvani stale content gde korisnici vide zastareli sadržaj uprkos tome što ste napravili izmene 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 gde po isteku TTL-a za popularan resurs, stotine konkurentnih zahteva istovremeno pogode origin server. Rešenje je request coalescing gde 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 promene koristite mehanizam sa verzionisanjem u URL-u koji garantuje konzistentnost jer svaki korisnik pristupa tačno definisanoj verziji resursa.