Was ist CDN Cache Invalidation

Einführung in CDN-Caching

Ein Content Delivery Network (CDN) funktioniert, indem es Kopien Ihrer Inhalte auf Edge-Servern weltweit cacht und sie Nutzern vom nächstgelegenen Server bereitstellt, anstatt dass jede Anfrage zu Ihrem Origin-Server gehen muss. Dies reduziert die Latenz drastisch und beschleunigt das Laden der Website für Nutzer, unabhängig von ihrem Standort. Caching bringt jedoch eine grundlegende Herausforderung mit sich - wie stellt man sicher, dass Nutzer immer die neueste Version des Inhalts sehen, wenn Sie Änderungen an der Website vornehmen.

Cache Invalidation ist der Prozess der Entfernung oder Ersetzung veralteter Inhalte aus dem CDN-Cache. Phil Karlton sagte einmal, dass es im Computing nur zwei schwierige Dinge gibt: Dinge benennen und Cache Invalidation. Diese Aussage veranschaulicht perfekt, wie komplex Cache-Management ist, da jede falsche Entscheidung dazu führen kann, dass Nutzer veraltete Inhalte sehen oder dass der Origin-Server unnötig belastet wird, weil der Cache zu aggressiv geleert wird.

Wie der CDN-Cache funktioniert

Wenn ein Nutzer zum ersten Mal eine Ressource anfordert, die nicht im Cache ist, leitet das CDN die Anfrage an den Origin-Server weiter, erhält die Antwort und speichert eine Kopie auf seinem Edge-Server. Jede nachfolgende Anfrage für dieselbe Ressource vom selben Edge-Server wird direkt aus dem Cache bedient, ohne den Origin zu kontaktieren. Der Origin-Server steuert das Cache-Verhalten über HTTP-Header wie Cache-Control, Expires, ETag und Last-Modified.

Wichtige HTTP-Header für Caching

• Cache-Control: max-age=3600 - die Ressource ist die nächsten 3600 Sekunden (1 Stunde) frisch
• Cache-Control: s-maxage=86400 - speziell für Shared Caches (CDN), Priorität gegenüber max-age
• Cache-Control: no-cache - der Cache muss mit dem Origin revalidieren, bevor er bedient
• Cache-Control: no-store - die Ressource darf niemals gecacht werden
• ETag - eindeutiger Versions-Identifikator der Ressource zur Revalidierung
• Vary - bestimmt, nach welchen Headern sich gecachte Versionen unterscheiden

Das Verständnis dieser Header ist entscheidend, da sie die Regeln definieren, nach denen das CDN entscheidet, ob es die gecachte Version bereitstellt oder eine neue vom Origin-Server anfordert. Falsch konfigurierte Header sind die häufigste Ursache für Probleme mit veralteten Inhalten oder unnötig häufigen Anfragen an den Origin.

Cache Purging - manuelle Cache-Bereinigung

Cache Purging ist der direkteste Weg, Inhalte aus dem CDN-Cache zu entfernen. Die meisten CDN-Anbieter bieten API und Dashboard zum manuellen Auslösen von Purge-Operationen. Sie können eine einzelne URL, eine Gruppe von URLs nach Muster (Wildcard Purge) oder den gesamten Cache aller Ressourcen löschen. Jeder dieser Ansätze hat je nach Situation Vor- und Nachteile.

Arten von Purge-Operationen

Single URL Purge ist die präziseste und schnellste Methode, da sie genau eine Ressource anvisiert. Verwenden Sie sie, wenn Sie eine Seite oder Datei aktualisieren. Wildcard Purge löscht alle Ressourcen, die einem bestimmten Muster entsprechen, beispielsweise /blog/* löscht alle Blog-Seiten aus dem Cache. Dies ist nützlich, wenn Sie mehrere Seiten aktualisieren, aber nicht den gesamten Cache leeren möchten. Full Purge löscht absolut alles aus dem Cache und sollte nur in Notsituationen verwendet werden, da es die Origin-Server-Last vorübergehend erhöht, während der Cache neu aufgebaut wird.

Purge-Operationen werden normalerweise je nach Anbieter und Netzwerkgröße in 1 bis 30 Sekunden über das CDN-Netzwerk verbreitet. Das Cloudflare-Netzwerk Purge wird global in etwa 30 Sekunden verbreitet, während AWS CloudFront bis zu 15 Minuten für Wildcard-Invalidierungen benötigen kann. Berücksichtigen Sie immer diese Verzögerung, wenn Sie Änderungen in der Produktion vornehmen und testen, ob die neue Version sichtbar ist.

TTL-Strategien

Time-To-Live (TTL) bestimmt, wie lange das CDN gecachten Inhalt als frisch betrachtet, bevor es eine neue Version vom Origin anfordert. Die richtige TTL-Einstellung ist ein Gleichgewicht zwischen Leistung (längere TTL = weniger Anfragen an Origin) und Inhaltsfrische (kürzere TTL = Änderungen werden schneller sichtbar). Es gibt keine universell richtige TTL, da sie vom Inhaltstyp und der Änderungshäufigkeit abhängt.

Empfohlene TTL nach Inhaltstyp

• Statische Assets (JS, CSS, Schriftarten) - 1 Jahr (31536000s) mit Dateiversionierung
• Bilder - 30 Tage (2592000s) mit ETag-Revalidierung
• HTML-Seiten - 5 Minuten bis 1 Stunde, abhängig von der Dynamik
• API-Antworten - 0 bis 60 Sekunden, abhängig von den Daten
• Favicon und robots.txt - 1 Tag (86400s)

Die Stale-while-revalidate-Direktive ist eine ausgezeichnete Strategie, die es dem CDN ermöglicht, Nutzern veralteten Inhalt zu liefern, während gleichzeitig im Hintergrund eine neue Version vom Origin angefordert wird. Das bedeutet, dass der Nutzer niemals auf den Origin-Server wartet, aber bei der nächsten Anfrage die neue Version sieht. Beispielsweise bedeutet Cache-Control: max-age=60, stale-while-revalidate=3600, dass der Inhalt 60 Sekunden frisch ist, aber für die nächste Stunde aus dem Cache bedient werden kann, während er im Hintergrund aktualisiert wird.

Ressourcen-Versionierung

Ressourcen-Versionierung ist die eleganteste Strategie zur Lösung des Cache-Invalidation-Problems, da sie die Notwendigkeit expliziter Purge-Operationen vollständig eliminiert. Anstatt den Inhalt einer Datei unter derselben URL zu ändern, erhält jede neue Version eine neue URL, was bedeutet, dass das CDN automatisch die neue Version bereitstellt, da es sie als völlig neue Ressource behandelt, die noch nicht im Cache ist.

Versionierungsmethoden

Content-Hash im Dateinamen ist die beliebteste Methode. Build-Tools wie Webpack, Vite und Next.js fügen automatisch den Content-Hash zum Dateinamen hinzu, beispielsweise style.a1b2c3d4.css. Wenn sich das CSS ändert, ändert sich der Hash und eine neue Datei mit neuem Namen wird generiert. Die alte Version bleibt im Cache, aber niemand referenziert sie mehr, da HTML nun auf die neue Datei verweist.

Query-String-Versionierung (style.css?v=1.2.3) ist ein einfacherer Ansatz, aber weniger zuverlässig, da einige CDN-Anbieter Query-Strings beim Caching ignorieren. Verwenden Sie ihn nur, wenn Sie keine Möglichkeit haben, den Dateinamen zu ändern. Pfad-Versionierung (/v2/style.css) ist eine weitere Option, die zuverlässig mit allen CDN-Anbietern funktioniert, aber mehr Konfiguration auf dem Server erfordert.

Wann den Cache invalidieren

Zu wissen, wann der Cache invalidiert werden muss, ist genauso wichtig wie zu wissen, wie es geht. Die häufigsten Szenarien, die eine Invalidierung erfordern, umfassen das Deployment einer neuen Website-Version auf dem Hosting-Server, die Korrektur eines kritischen Inhaltsfehlers, das Entfernen versehentlich veröffentlichter sensibler Inhalte und Änderungen bei Preis oder Verfügbarkeit von Produkten in einem E-Commerce-Shop. In all diesen Fällen müssen Nutzer den aktualisierten Inhalt so schnell wie möglich sehen.

Best Practices für Invalidierung

• Automatisieren - integrieren Sie Cache Purge in die CI/CD-Pipeline für automatische Invalidierung bei jedem Deployment
• Seien Sie präzise - zielen Sie wann immer möglich auf konkrete URLs anstelle eines Full Purge
• Verwenden Sie Versionierung - für statische Assets eliminiert dies vollständig die Notwendigkeit manueller Invalidierung
• Überwachen Sie - verfolgen Sie die Cache-Hit-Ratio, um Konfigurationsprobleme zu erkennen
• Testen Sie - überprüfen Sie Header mit curl -I, um zu bestätigen, dass Caching wie erwartet funktioniert
• Dokumentieren Sie - notieren Sie TTL-Werte und Invalidierungsstrategie für jeden Inhaltstyp

Häufige Probleme und Lösungen

Eines der häufigsten Probleme ist sogenannter Stale Content, bei dem Nutzer veralteten Inhalt sehen, obwohl Sie Änderungen am Origin-Server vorgenommen haben. Die Ursache ist meist eine zu lange TTL ohne Invalidierungsmechanismus. Die Lösung ist eine Kombination aus vernünftiger TTL mit automatisierten Purge-Operationen beim Deployment. Ein weiteres häufiges Problem ist Cache Stampede, bei dem nach Ablauf der TTL für eine beliebte Ressource Hunderte gleichzeitiger Anfragen den Origin-Server treffen. Die Lösung ist Request Coalescing, bei dem das CDN nur eine Anfrage an den Origin sendet und alle anderen Anfragen zurückhält, bis es eine Antwort erhält.

Das Problem unterschiedlicher Inhaltsversionen auf verschiedenen Edge-Servern (Cache-Inkonsistenz) entsteht, weil eine Purge-Operation nicht gleichzeitig auf alle Server verbreitet werden kann. Während einer kurzen Zeit nach dem Purge sehen einige Nutzer die alte und einige die neue Version. Verwenden Sie für kritische Änderungen einen Mechanismus mit URL-Versionierung, der Konsistenz garantiert, da jeder Nutzer auf eine genau definierte Ressourcenversion zugreift.