Cloudflare schloss am 12. August die Migration seines Blogs zu EmDash ab, einem Content-Management-System, das für die Zusammenarbeit mit Astro und Cloudflare entwickelt wurde. Das Projekt beschränkte sich nicht auf eine Neugestaltung der Benutzeroberfläche. Das Unternehmen nutzte seinen Blog als „Kunden null“, um die neue Plattform unter realem Produktionsverkehr zu testen, mit Schwerpunkt auf Skalierbarkeit, Reaktionsgeschwindigkeit und der sicheren Ablösung des alten Systems.
Cloudflare zufolge brachte die Migration Anforderungen zutage, die mit der Größe und Komplexität des Blogs zusammenhängen, und ermöglichte dem Team, EmDash vor einer breiteren Einführung zu verbessern. Da die Ergebnisse und Messwerte vom Unternehmen selbst stammen, stellen sie eine von einer einzelnen Partei veröffentlichte Betriebserfahrung dar und keinen unabhängigen Plattformtest.
Die Plattform vor dem Leistungstest testen
Das Team begann mit einer praktischen Frage: Funktioniert EmDash tatsächlich mit den Anforderungen von Cloudflare? Dazu testete es grundlegende Abläufe wie das Erstellen, Veröffentlichen, Zurückziehen und Planen von Beiträgen, das Hinzufügen von Medien sowie die Suche nach Inhaltsentitäten und die Verwaltung von Autorennamen.
Die größten Lücken zeigten sich beim Umgang mit großen Mengen an Medien und Inhalten sowie bei Details der Übersetzung, der Suchmaschinenoptimierung und der Content-Security-Policy (CSP). Auch der Verwaltungseditor benötigte Verbesserungen, um benutzerdefinierte HTML-Blöcke leichter zu finden, Fehler im Inhaltseditor zu behandeln und die Formatierungsleiste beim Bearbeiten langer Beiträge sichtbar zu halten.
Geplante Beiträge waren das wichtigste entdeckte Problem, da sie bis zur EmDash-Version 0.19.0 nicht funktionierten. Dieser Punkt verdeutlicht den Wert vollständiger Betriebstests vor der Einführung eines neuen Systems, da der Fehler bei einem Test zum Erstellen oder sofortigen Veröffentlichen von Inhalten möglicherweise nicht aufgetreten wäre.
Lasttests mit schwankendem Datenverkehr
Der übliche Datenverkehr auf Cloudflare Blog lag bei etwa 75 Anfragen pro Sekunde, konnte jedoch mehr als 5.000 Anfragen pro Sekunde erreichen, entweder zeitgleich mit der Verbreitung eines neuen Beitrags oder aufgrund von Spitzen, die nicht an einen bestimmten Veröffentlichungszeitpunkt gebunden waren. Daher entwickelte das Team Tests mit dem Open-Source-Tool k6. Diese umfassten eine schrittweise Erhöhung der Last auf das Dreifache des Ausgangswerts, einen Test, der innerhalb von zehn Minuten von null auf 100 Anfragen pro Sekunde anstieg, sowie einen sofortigen Burst-Test mit 7.000 Anfragen pro Sekunde über eine Minute.
Die Fehlerkriterien basierten auf drei Indikatoren: HTTP-Fehler der Klasse 5xx durften nicht mehr als 0,01 % ausmachen, die Antwortzeit von 95 % der Anfragen durfte 500 Millisekunden nicht überschreiten, und die Antwortzeit von 99 % der Anfragen durfte höchstens eine Sekunde betragen. Diese Grenzen verwandelten die Frage „Ist die Plattform schnell?“ in messbare Betriebsbedingungen.
Mehrschichtige Architektur und klarer Fallback-Pfad
Cloudflare entschied sich, EmDash auf einem Cloudflare Worker hinter dem Workers Cache zu betreiben. Dabei kam der neue Objektspeicher von EmDash auf Basis von Workers KV sowie die Integration von Hyperdrive mit PlanetScale zum Einsatz. Den Unternehmensdaten zufolge ermöglichten die Cache-Schichten, 99,5 % der statischen Dateien aus dem Cache bereitzustellen; insgesamt wurden etwa 70 % der Anfragen aus dem Cache bedient, wodurch die Datenbank entlastet wurde.
Um einen Dienst-Ausfall während der Migration zu verhindern, erstellte das Team einen Proxy Worker, der Anfragen zwischen dem alten Blog und der neuen Website verteilte. Er bestimmte die Testversion anhand eines Cookies und konnte Anfragen bei Auftreten von 500-Fehlern auf der neuen Website an das alte System zurückleiten. Außerdem verwendete das Team eine direkte Verbindung zwischen Workern über die Dienstbindung NEW_BLOG, um die Weiterleitung über einen öffentlichen Domainnamen sowie DNS- und TLS-Vorgänge und eine externe HTTP-Verbindung zu vermeiden.
Die schrittweise Einführung begann mit 1 % des Datenverkehrs, stieg anschließend auf 5 % und 15 % und erreichte am Ende des Tages 100 %. Dadurch konnten der reale Datenverkehr überwacht und Randfälle entdeckt werden, ohne die Mehrheit der Leser einer instabilen Änderung auszusetzen.
Was änderte sich in der Praxis?
Cloudflare zufolge bewahrte die neue Architektur im Vergleich zur vorherigen Plattform eine stabilere Antwortzeit und erzielte bei der Verarbeitung von bis zu 850 Anfragen pro Sekunde Leistungsgewinne bei begrenzten Fehlern. Während der Agents Week wurden innerhalb von neun Tagen 18 Blogbeiträge veröffentlicht und nahezu 3 Millionen Aufrufe erzielt. Der neue Worker verarbeitete dabei bis zu 450 Anfragen pro Sekunde ohne erkennbare Probleme. Außerdem absorbierte der integrierte DDoS-Schutz laut Unternehmen am 10. August einen Angriff mit 28.000 Anfragen pro Sekunde.
Die Änderung umfasste auch die Benutzeroberfläche, die nach den Mustern des Kumo-Designsystems neu aufgebaut wurde und nativ einen hellen und einen dunklen Modus unterstützt, abhängig von den Systemeinstellungen sowie über einen manuellen Umschalter. Die Einladung zum E-Mail-Abonnement wurde an das Ende des Artikels verschoben. Außerdem wurden ein Inhaltsverzeichnis „Auf dieser Seite“ und eine Option „Online diskutieren“ zur Verbesserung der Navigation und Beteiligung hinzugefügt.
Die neuen EmDash-Schnittstellen und die Suchendpunkte für künstliche Intelligenz ermöglichten es, innerhalb weniger Stunden einen MCP-Server für den Cloudflare-Blog zu erstellen, mit Werkzeugen zum Suchen, Auflisten und Abrufen von Beiträgen sowie zum Auflisten von Tags. Der MCP-Server von EmDash ermöglicht Autoren laut Quelle außerdem, Inhalte ohne zusätzliche Kosten zu durchsuchen, zu erstellen, zu bearbeiten, zu veröffentlichen, zu planen und Dateien zu entfernen.
Die Bearbeitungserfahrung selbst ist noch nicht vollständig ausgereift. Cloudflare verzeichnete weiterhin kleinere Probleme und Fehler im Zusammenhang mit geplanten Beiträgen, meldete diese an das EmDash-Team und erwartete ihre Behebung vor der Birthday Week. Der Fall belegt daher nicht, dass die Plattform frei von Einschränkungen ist. Er zeigt jedoch eine anwendbare Vorgehensweise: Inhaltsabläufe vor der Leistung testen, klare Fehlerschwellen festlegen, einen Fallback-Pfad einrichten und die Einführung anschließend schrittweise ausweiten, statt die Migration auf einmal vollständig durchzuführen.