Š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 svijeta i servira ih korisnicima sa najbližeg servera umjesto da svaki zahtjev 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 izmene na sajtu.

Cache invalidation je proces uklanjanja ili zamjene 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 funkcionira

Kada korisnik prvi put zatrazi resurs koji nije u kesu, CDN prosleđuje zahtjev origin serveru, dobija odgovor i čuva kopiju na svom edge serveru. Svaki sljedeći zahtjev 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 prije serviranja
• Cache-Control: no-store - resurs se nikada ne smije 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 zahtjevima 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 datoteka. Wildcard purge brise sve resurse koji odgovaraju određenom paternu, na primjer /blog/* brise sve blog stranice iz kesa. Ovo je korisno kada ažurirate veći broj stranica ali ne želite 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 zahtijevati do 15 minuta za wildcard invalidacije. Uvek imajte na umu ovo kasnjenje 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 svezim prije nego što zatrazi novu verziju od origina. Pravilno podešavanje TTL-a je balans između performansi (duži TTL = manje zahtijeva ka originu) i svezine sadržaja (kraci TTL = brže se vide promjene). Ne postoji univerzalno pravilan TTL jer on ovisi o 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 datoteka
• 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ćuje CDN-u da servira zastareli sadržaj korisnicima dok istovremeno u pozadini zahtijeva novu verziju od origina. Ovo znači da korisnik nikada ne ceka na origin server ali će vidjeti novu verziju već pri sljedećem zahtjevu. Na primjer 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 rješavanje cache invalidation problema jer potpuno eliminise potrebu za eksplicitnim purge operacijama. Umesto da menjate sadržaj datoteke 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 datoteke je najpopularnija metoda. Build alati kao što su Webpack, Vite i Next.js automatski dodaju hash sadržaja u ime datoteke, na primjer style.a1b2c3d4.css. Kada se CSS promijeni, hash se menja i generiše se novi datoteka sa novim imenom. Stara verzija ostaje u kesu ali je niko više ne referencira jer HTML sada ukazuje na novi datoteka.

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 datoteke. Putanja verzionisanje (/v2/style.css) je još jedna opcija koja radi pouzdano sa svim CDN provajderima ali zahtijeva 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 zahtijevaju 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 prije vidjeti 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 umjesto 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 - provjerite hedere sa curl -I da biste potvrdili da keširanje radi kako očekujete
• Dokumentujte - zabelezite TTL vrijednosti i strategiju invalidacije za svaki tip sadržaja

Cesti problemi i rješenja

Jedan od najčešćih problema je takozvani stale content gdje korisnici vide zastareli sadržaj uprkos tome što ste napravili izmene na origin serveru. Uzrok je obično predugacak TTL bez mehanizma za invalidaciju. Rješ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 zahtijeva istovremeno pogode origin server. Rješenje je request coalescing gdje CDN šalje samo jedan zahtjev ka originu a sve ostale zahtjeve 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 se propagira na sve servere istovremeno. Tokom kratkog perioda nakon purge-a neki korisnici će vidjeti 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.