Ein zweiter Auslieferungsweg schützt vor dem Totalausfall, bringt aber Komplexität, langsamer aufwärmende Caches und mögliche Zusatzlast für den Origin mit. Was Teams auf CDN-Ebene vor dem Event entscheiden sollten.
Ein einziger Softwarefehler bei einem CDN-Anbieter kann viele Websites gleichzeitig lahmlegen. Hängt die gesamte Auslieferung eines Events an einem Anbieter, ist sie von dessen Ausfall unmittelbar betroffen. GlobalDots erinnert in einem Blogbeitrag von 2022 an den 8. Juni 2021: Eine Änderung bei einem Fastly-Kunden löste laut Beitrag einen neuen Softwarefehler aus, der binnen fünf Minuten 85 Prozent des Netzwerks lahmlegte. Nach rund einer Stunde war der Dienst wieder da.
Für Betriebsteams, die ein großes Event vorbereiten, ergibt sich daraus eine Planungsfrage, die vor dem Start beantwortet sein muss: Wohin läuft der Verkehr, wenn ein CDN ausfällt oder überlastet ist, und wer oder was entscheidet das? Drei Anbieterveröffentlichungen von GlobalDots, CacheFly und IO River geben darauf im Kern ähnliche Antworten: mehrere Auslieferungswege, DNS-basierte Umschaltung, vorab festgelegte Regeln und Monitoring als Auslöser. Die Texte behandeln Web-Auslieferung allgemein und nicht Live-Video. Als Planungsrahmen für die CDN-Ebene taugen sie trotzdem.
Regeln festlegen, bevor der Ausfall eintritt
CacheFly beschreibt das Risiko nüchtern: Fällt das einzige CDN aus oder bricht seine Leistung ein, kann der gesamte Betrieb unterbrochen werden. Als Gegenmittel nennt der Anbieter Multi-CDN, bei dem der Verkehr bei Problemen automatisch auf ein anderes CDN umgeleitet wird. Umgesetzt wird das über die DNS-Konfiguration, den Origin-Server als zentrale Inhaltsquelle und die Cache-Control-Einstellungen.
IO River nennt den Baustein genauer: Ein Traffic Director, meist ein DNS-Dienst, entscheidet pro Anfrage, welches CDN antwortet. Er kann sich an Geografie, Leistung oder Last orientieren, außerdem an Latenz, CDN-Gesundheit und eigenen Geschäftsregeln wie Kostenkontrollen. Der Anbieter rät ausdrücklich, diese Regeln vorab festzulegen. Ein nützlicher Hinweis steckt im Glossar außerdem: CDNs können auch langsamer werden, ohne vollständig auszufallen. Das beschriebene Failover greift entsprechend bei einem langsamen wie bei einem ausgefallenen CDN.
Monitoring entscheidet, ob die Umschaltung greift
Ein Failover ist nur so gut wie das Signal, das es auslöst. CacheFly nennt Echtzeit-Monitoring und -Analysen als Auslöser für das Umleiten. IO River empfiehlt Real-User-Monitoring und synthetische Tests, um Probleme zu erkennen, bevor sich Nutzer melden. GlobalDots beschreibt in seinem Backup-Konzept einen weiteren Schritt: Das Monitoring klärt zuerst, ob der Fehler auf der eigenen Seite oder beim CDN liegt. Bei einem Problem auf CDN-Seite schaltet das DNS automatisch auf die Backup-Plattform, nach stabiler Verbindung wieder zurück.
Der Backup-Pfad ist nicht gratis
Wer einen zweiten Weg hat, muss ihn auch betriebsbereit halten. GlobalDots lässt in seinem Konzept im Normalbetrieb ein Prozent des Verkehrs über den Backup-Anbieter laufen, damit dessen Caches aktuell bleiben und im Ernstfall die Last tragen können. Das ist ein Herstellerkonzept und keine Pflichtregel. Es zeigt aber die Logik: Die Caches des Backups sollen schon gefüllt sein, bevor sie gebraucht werden.
IO River benennt die Folgen für das Caching deutlich. Verteilt sich derselbe Inhalt auf mehrere CDNs, wärmt jeder Cache langsamer auf, und die Trefferquote kann sinken. Das Glossar empfiehlt klare regionale Aufteilungen oder Routing-Regeln, damit wichtige Inhalte dort „heiß“ bleiben, wo sie gebraucht werden. Dazu kommen einheitliche Cache-Keys, weil verschiedene CDNs Query-Strings, Cookies und Header unterschiedlich behandeln können. Kurze TTLs über mehrere CDNs können außerdem den Origin belasten. Origin-Shields sollen die meisten Cache-Misses abfangen, bevor sie ihn erreichen. Wer die Umschaltung plant, sollte deshalb auch den Origin im Blick behalten.
Hinzu kommt die Komplexität. CacheFly nennt als Herausforderungen den Aufwand für die Verwaltung mehrerer CDNs, laufende Kosten und den Bedarf an technischem Know-how. Konfigurationsfehler können demnach selbst zu Leistungsproblemen oder Ausfällen führen. IO River beschreibt einen schrittweisen Aufbau: Schon einfaches Geo-Routing oder eine 50/50-Aufteilung ergebe ein stärkeres Setup als ein einzelnes CDN, intelligentere Werkzeuge und automatisches Failover lassen sich später ergänzen. Für ein Event mit festem Termin heißt das, rechtzeitig zu entscheiden, welcher Automatisierungsgrad bis dahin stabil läuft.
Die Quellen sind Anbieterveröffentlichungen. Als Checkliste für die Planung taugen sie, Messwerte für das eigene Setup liefern sie nicht. Am Ende steht eine Frage, die jedes Team vor dem Event beantworten sollte: Stehen die Routing-Regeln fest, ist der zweite Pfad mit echtem Verkehr warm, und hält der Origin die zusätzlichen Anfragen bei einer Umschaltung aus?
Quellen: GlobalDots — The Costly Toll a CDN Outage Crisis Has on eCommerce …; CacheFly — How Multi-CDN Strategies Boost Performance and Cost …; IO River — What is Multi-CDN?