Co je CDN cache invalidation

Úvod do CDN cachování

Content Delivery Network (CDN) funguje tak, že ukládá kopie vašeho obsahu na edge servery po celém světě a doručuje je uživatelům z nejbližšího serveru, místo aby každý požadavek směřoval na váš origin server. To dramaticky snižuje latenci a zrychluje načítání webu pro uživatele bez ohledu na to, kde se nacházejí. Cachování však přináší zásadní výzvu – jak zajistit, aby uživatelé vždy viděli nejnovější verzi obsahu, když na webu provedete změny.

Cache invalidation je proces odstranění nebo nahrazení zastaralého obsahu z CDN cache. Phil Karlton kdysi řekl, že v informatice existují jen dvě těžké věci: pojmenovávání věcí a invalidace cache. Tento výrok dokonale ilustruje, jak složitá správa cache je, protože každé špatné rozhodnutí může vést k tomu, že uživatelé uvidí zastaralý obsah, nebo k tomu, že je origin server zbytečně zatěžovaný, protože je cache mazaná příliš agresivně.

Jak CDN cache funguje

Když uživatel poprvé požádá o zdroj, který není v cache, CDN požadavek přepošle na origin server, získá odpověď a uloží kopii na svůj edge server. Každý další požadavek na stejný zdroj ze stejného edge serveru je obsloužen přímo z cache bez kontaktování originu. Origin server řídí chování cache pomocí HTTP hlaviček jako Cache-Control, Expires, ETag a Last-Modified.

Klíčové HTTP hlavičky pro cachování

• Cache-Control: max-age=3600 – zdroj je čerstvý po dobu následujících 3600 sekund (1 hodina)
• Cache-Control: s-maxage=86400 – specifické pro sdílené cache (CDN), má přednost před max-age
• Cache-Control: no-cache – cache musí před doručením revalidovat s originem
• Cache-Control: no-store – zdroj se nikdy nesmí cachovat
• ETag – unikátní identifikátor verze zdroje pro revalidaci
• Vary – určuje, podle kterých hlaviček se liší cachované verze

Pochopení těchto hlaviček je klíčové, protože definují pravidla, podle nichž se CDN rozhoduje, zda doručit cachovanou verzi, nebo si vyžádat novou z origin serveru. Nesprávně nakonfigurované hlavičky jsou nejčastější příčinou problémů se zastaralým obsahem nebo zbytečně častých požadavků na origin.

Cache purging – ruční mazání cache

Cache purging je nejpřímější způsob, jak odstranit obsah z CDN cache. Většina poskytovatelů CDN nabízí API a dashboard pro ruční spouštění purge operací. Můžete vymazat jednu URL, skupinu URL podle vzoru (wildcard purge) nebo kompletní cache všech zdrojů. Každý přístup má své výhody i nevýhody podle situace.

Typy purge operací

Purge jedné URL je nejpřesnější a nejrychlejší metoda, protože cílí přesně na jeden zdroj. Použijte ji při aktualizaci jedné stránky nebo souboru. Wildcard purge smaže všechny zdroje odpovídající určitému vzoru, například /blog/* smaže z cache všechny stránky blogu. To je užitečné při aktualizaci většího počtu stránek, ale když nechcete mazat kompletní cache. Full purge smaže z cache úplně vše a měl by se používat jen v naléhavých situacích, protože dočasně zvyšuje zátěž origin serveru, dokud se cache neobnoví.

Purge operace se obvykle propagují CDN sítí během 1 až 30 sekund podle poskytovatele a velikosti sítě. Síť Cloudflare propaguje purge globálně asi za 30 sekund, zatímco AWS CloudFront může u wildcard invalidací vyžadovat až 15 minut. Toto zpoždění mějte vždy na paměti při nasazování změn do produkce a testování, zda je nová verze viditelná.

Strategie TTL

Time-To-Live (TTL) určuje, jak dlouho CDN považuje cachovaný obsah za čerstvý, než si vyžádá novou verzi z originu. Správné nastavení TTL je balancem mezi výkonem (delší TTL = méně požadavků na origin) a aktuálností obsahu (kratší TTL = změny se projeví rychleji). Neexistuje univerzálně správné TTL, protože závisí na typu obsahu a na tom, jak často se mění.

Doporučené TTL podle typu obsahu

• Statické assety (JS, CSS, fonty) – 1 rok (31536000 s) s verzováním souborů
• Obrázky – 30 dní (2592000 s) s ETag revalidací
• HTML stránky – 5 minut až 1 hodina podle dynamického obsahu
• Odpovědi API – 0 až 60 sekund podle dat
• Favicon a robots.txt – 1 den (86400 s)

Direktiva stale-while-revalidate je vynikající strategií, která CDN umožňuje doručovat uživatelům zastaralý obsah a zároveň si na pozadí vyžádat novou verzi z originu. To znamená, že uživatel nikdy nečeká na origin server, ale při dalším požadavku už uvidí novou verzi. Například Cache-Control: max-age=60, stale-while-revalidate=3600 znamená, že obsah je čerstvý 60 sekund, ale může být doručován z cache po dobu následující hodiny, zatímco se na pozadí obnovuje.

Verzování zdrojů

Verzování zdrojů je nejelegantnější strategií řešení problému cache invalidation, protože zcela eliminuje potřebu explicitních purge operací. Místo změny obsahu souboru na stejné URL získá každá nová verze novou URL, což znamená, že CDN automaticky doručí novou verzi, protože ji považuje za zcela nový zdroj, který ještě není v cache.

Metody verzování

Content hash v názvu souboru je nejoblíbenější metoda. Build nástroje jako Webpack, Vite a Next.js automaticky přidávají content hash do názvu souboru, například style.a1b2c3d4.css. Když se CSS změní, změní se i hash a vygeneruje se nový soubor s novým názvem. Stará verze zůstane v cache, ale nikdo už na ni neodkazuje, protože HTML nyní ukazuje na nový soubor.

Verzování přes query string (style.css?v=1.2.3) je jednodušší přístup, ale méně spolehlivý, protože někteří poskytovatelé CDN při cachování query string ignorují. Použijte jej jen tehdy, když nemůžete změnit název souboru. Verzování přes cestu (/v2/style.css) je další možnost, která spolehlivě funguje u všech poskytovatelů CDN, ale vyžaduje více konfigurace na serveru.

Kdy invalidovat cache

Vědět, kdy invalidovat cache, je stejně důležité jako vědět, jak to udělat. Mezi nejčastější scénáře vyžadující invalidaci patří nasazení nové verze webu na hostingový server, oprava kritické chyby v obsahu, odstranění citlivého obsahu zveřejněného omylem a změna cen nebo dostupnosti produktů v e-shopu. Ve všech těchto případech musí uživatelé vidět aktualizovaný obsah co nejdříve.

Osvědčené postupy invalidace

• Automatizujte – integrujte cache purge do CI/CD pipeline pro automatickou invalidaci při každém nasazení
• Buďte přesní – cílit kdykoli je to možné na konkrétní URL místo full purge
• Používejte verzování – u statických assetů zcela eliminuje potřebu ruční invalidace
• Monitorujte – sledujte cache hit ratio pro odhalení konfiguračních problémů
• Testujte – kontrolujte hlavičky pomocí curl -I a ověřte, že cachování funguje podle očekávání
• Dokumentujte – zaznamenávejte hodnoty TTL a strategii invalidace pro každý typ obsahu

Časté problémy a řešení

Jedním z nejčastějších problémů je takzvaný stale content, kdy uživatelé vidí zastaralý obsah navzdory změnám, které jste provedli na origin serveru. Příčinou je obvykle příliš dlouhé TTL bez invalidačního mechanismu. Řešením je kombinace rozumného TTL s automatizovanými purge operacemi při nasazení. Dalším častým problémem je cache stampede, kdy po vypršení TTL u populárního zdroje současně dorazí na origin server stovky souběžných požadavků. Řešením je request coalescing, kdy CDN odešle na origin jen jeden požadavek a všechny ostatní podrží, dokud nedostane odpověď.

Problém různých verzí obsahu na různých edge serverech (cache inconsistency) vzniká proto, že purge operace se nemůže propagovat na všechny servery současně. Během krátké doby po purge uvidí někteří uživatelé starou a někteří novou verzi. U kritických změn použijte mechanismus verzování URL, který zaručuje konzistenci, protože každý uživatel přistupuje k přesně definované verzi zdroje.