Neue Tools für die Produktionssicherheit — Gradual Deployments, Source Maps, Rate Limiting und neue SDKs

In der Developer Week 2024 dreht sich alles um die Production Readiness (also „Einsatzfähigkeit“ bzw. „Marktreife“ Ihres entwickelten Produkts). Am Montag, den 1. April, haben wir bekannt gegeben, dass D1, Queues, Hyperdrive, und Workers Analytics Engine für die Markteinführung bereit und allgemein verfügbar sind. Am Dienstag, den 2. April, gaben wir dasselbe über unsere Inferenzplattform bekannt, Workers AI. Und wir sind noch lange nicht fertig.

Bei der Production Readiness bzw. Marktreife Ihrer Entwicklungen geht es nicht nur um den Umfang und die Zuverlässigkeit der Dienste, mit denen Sie entwickeln. Sie brauchen auch Werkzeuge, um Änderungen sicher und zuverlässig durchzuführen. Sie verlassen sich nicht nur auf das, was Cloudflare bietet, sondern auch darauf, dass Sie das Verhalten von Cloudflare genau steuern und an die Bedürfnisse Ihrer Anwendung anpassen können.

Heute kündigen wir fünf Updates an, die Ihnen mehr Möglichkeiten bieten: Gradual Deployments, Stack Traces mit Source Maps in Tail Workers, eine neue Rate Limiting-API, brandneue API-SDKs und Neuerungen für Durable Objects – alle mit Blick auf geschäftskritische Produktionsdienste. Wir entwickeln unsere eigenen Produkte mit Workers, einschließlich Access, R2, KV, Waiting Room, Vectorize, Queues, Stream und mehr. Wir verlassen uns selbst auf jede dieser neuen Funktionen, um sicherzustellen, dass unsere Produkte bereit für die Produktivsetzung sind – und jetzt freuen wir uns, sie allen zur Verfügung stellen zu können.

Schrittweise Implementierung von Änderungen an Workers und Durable Objects

Die Bereitstellung eines Worker erfolgt nahezu sofort – in wenigen Sekunden ist die Änderung überall live.

Wenn Sie den breiten Einsatz am Markt erreichen, birgt jede Änderung, die Sie vornehmen, ein größeres Risiko, sowohl in Bezug auf das Volumen als auch auf die Erwartungen. Sie müssen Ihr SLA für 99,99 % Verfügbarkeit erfüllen oder haben ein ambitioniertes SLO mit P90-Latenz. Eine fehlerhafte Bereitstellung, die 45 Sekunden lang für 100 % des Datenverkehrs aktiv ist, kann Millionen von fehlgeschlagenen Anfragen bedeuten. Eine geringfügige Codeänderung kann bei einem überlasteten Backend zu einer Flut von Wiederholungsversuchen führen, wenn sie auf einmal eingeführt wird. Dies sind die Arten von Risiken, die wir selbst für unsere eigenen, auf Workers basierenden Dienste in Betracht ziehen und mindern.

Diese Risiken lassen sich durch eine schrittweise Implementierung von Änderungen verringern, die manchmal auch als rollierende oder fortlaufende Bereitstellung („rolling deployment“) bezeichnet wird.

1. Die aktuelle Version Ihrer Anwendung befindet sich im Produktivbetrieb
2. Sie schalten die neue Version Ihrer Anwendung produktiv, leiten aber nur einen kleinen Prozentsatz des Datenverkehrs an diese neue Version weiter und warten, bis sie im Produktivbetrieb langsam „eingesickert“ ist, wobei Sie auf Regressionen und Fehler achten. Wenn etwas Schlimmes passiert, haben Sie es bei einem geringen Prozentsatz frühzeitig erkannt (z. B. 1 %) des Traffic-Aufkommens und können es schnell wieder auf die alte Version zurücksetzen.
3. Sie erhöhen den prozentualen Anteil des Datenverkehrs schrittweise, bis die neue Version 100 % erreicht und dann vollständig eingeführt wird.

Mit dem heutigen Tag schaffen wir eine erstklassige Möglichkeit, Codeänderungen schrittweise auf Workers und Durable Objects über die Cloudflare API, die Wrangler CLI oder das Workers Dashboard zu implementieren.  Gradual Deployments geht in die Open Beta-Phase – Sie können Gradual Deployments mit jedem Cloudflare-Konto nutzen, der im Workers Free-Tarif ist, und sehr bald werden Sie Gradual Deployments auch mit Cloudflare Accounts im Workers Paid und Enterprise-Tarif nutzen können. Sie werden ein Banner auf dem Workers Dashboard sehen, sobald Ihr Konto Zugang hat.

Wenn Sie zwei Versionen Ihres Workers oder Durable Objects gleichzeitig im Produktivbetrieb laufen lassen, möchten Sie mit Sicherheit in der Lage sein, Ihre Metriken, Ausnahmen und Protokolle nach Version zu filtern. Dies kann Ihnen helfen, Probleme in der Produktivnutzung frühzeitig zu erkennen, wenn die neue Version nur für einen kleinen Prozentsatz des Traffics ausgerollt wird, oder Performance-Metriken zu vergleichen, wenn der Traffic 50/50 aufgeteilt wird. Unsere Plattform bietet jetzt auch Beobachtbarkeit auf Versionsebene:

• Sie können die Analysen im Workers-Dashboard und über die GraphQL Analytics API nach Version filtern.
• Workers Trace Events und Tail Worker-Ereignisse enthalten die Versions-ID Ihrer Worker sowie optionale Felder für Versionsmeldungen und Versionskennzeichen.
• Wenn Sie Wrangler Tail verwenden, um Live-Protokolle anzuzeigen, können Sie Protokolle für eine bestimmte Version anzeigen.
• Sie können vom Code Ihres Workers aus auf Versions-ID, Nachricht und Tag zugreifen, indem Sie die Bindung der Version-Metadaten konfigurieren.

Vielleicht möchten Sie auch sicherstellen, dass jeder Client oder Benutzer nur eine einheitliche Version Ihres Workers sieht. Wir haben Version Affinity hinzugefügt, sodass Anfragen, die mit einer bestimmten Kennung verbunden sind (z. B. Benutzer, Sitzung oder eine andere eindeutige ID), immer von einer einheitlichen Version Ihres Workers verarbeitet werden. Die Sitzungsaffinität gibt Ihnen in Verbindung mit der Ruleset Engine die volle Kontrolle über den Mechanismus und die Kennung (Identifikator), um die Durchgängigkeit zu gewährleisten.

Gradual Deployments geht jetzt in die Open Beta-Phase. Damit wir schon bald die allgemeine Verfügbarkeit erreichen, arbeiten wir daran, folgende Funktionen zu unterstützen:

• Überschreiben von Versionen. Rufen Sie eine bestimmte Version Ihres Workers auf, um ihn zu testen, bevor er für den Live-Traffic eingesetzt wird. So können Sie Blau/Grün-Bereitstellungen („Blue-Green Deployments“) erstellen.
• Cloudflare Pages. Lassen Sie das CI/CD-System in Cloudflare Pages die Bereitstellungen automatisch in Ihrem Namen durchführen.
• Automatische Rollbacks. Führen Sie automatisch ein Rollback durch, wenn die Fehlerrate für eine neue Version Ihres Workers ansteigt.

Wir freuen uns auf Ihr Feedback! Teilen Sie uns Ihre Meinung über dieses Feedback-Formular mit oder melden Sie sich in unserem Entwickler-Discord im Kanal #workers-gradual-deployments-beta.

Stack Traces mit Source Maps in Tail Workers

Production Readiness bedeutet, Fehler und Ausnahmen zu verfolgen und zu versuchen, sie auf null zu reduzieren. Wenn ein Fehler auftritt, sollten Sie sich als erstes den Stack Trace des Fehlers ansehen – die spezifischen Funktionen, die aufgerufen wurden, in welcher Reihenfolge, von welcher Zeile und Datei und mit welchen Argumenten.

Der meiste JavaScript-Code – nicht nur auf Workers, sondern plattformübergreifend – wird zunächst gebündelt, oft transpiliert und dann verkleinert, bevor es zur Produktivsetzung kommt. Dies geschieht im Hintergrund, um kleinere Pakete zur Optimierung der Performance zu erstellen und bei Bedarf von Typescript in Javascript zu konvertieren.

Wenn Sie jemals eine Ausnahme gesehen haben, die einen Stack-Trace wie z.B.: /src/index.js:1:342 ausgibt, bedeutet dies, dass der Fehler beim 342. Zeichen des minimierten Codes Ihrer Funktion aufgetreten ist. Das ist für die Fehlersuche natürlich nicht sehr hilfreich.

Source Maps lösen dieses Problem – sie führen den kompilierten und verkleinerten Code auf den ursprünglichen Code zurück, den Sie geschrieben haben. Source Maps werden mit dem von der JavaScript-Laufzeitumgebung zurückgegebenen Stack-Trace kombiniert, um Ihnen einen für Menschen lesbaren Stack-Trace zu präsentieren. Der folgende Stack-Trace zeigt zum Beispiel, dass der Worker in Zeile 30 der Dateidown.ts einen unerwarteten Nullwert erhalten hat. Dies ist ein nützlicher Ausgangspunkt für die Fehlersuche. Sie können den Stack-Trace weiter nach unten verfolgen, um nachzuvollziehen, welche Funktionen aufgerufen wurden, die zu dem Nullwert geführt haben.

Unexpected input value: null
  at parseBytes (src/down.ts:30:8)
  at down_default (src/down.ts:10:19)
  at Object.fetch (src/index.ts:11:12)

Unser Erfolgsgeheimnis:

1. Wenn Sie upload_source_maps = true in Ihrer wrangler.toml setzen, wird automatisch alle Source-Map-Dateien erzeugen und hochladen, wenn Sie wrangler deploy oder wrangler versions upload ausführen.
2. Wenn Ihr Worker eine nicht abgefangene Ausnahme auslöst, holen wir die Source Map und verwenden sie, um die Stack-Trace der Ausnahme auf Zeilen des ursprünglichen Quellcodes Ihres Workers zurückzuführen.
3. Sie können diesen entschleierten Stack-Trace dann in Echtzeitprotokollen oder in Tail Workers anzeigen.

Ab heute, in der Open Beta, können Sie Source Maps zu Cloudflare hochladen, wenn Sie Ihren Worker bereitstellen – lesen Sie dazu die Dokumentation. Und ab dem 15. April wird die Workers-Laufzeit beginnen, Source Maps zu verwenden, um Stack Traces zu entschleiern. Wir werden eine Benachrichtigung im Cloudflare-Dashboard und auf unserem X-Konto für Cloudflare Developers posten, wenn Stack Traces mit Source Maps verfügbar sind.

Neue Rate Limiting-API in Workers

Eine API kann nur dann produktiv gesetzt werden, wenn sie über eine sinnvolle Durchsatzbegrenzung verfügt. Und je mehr Sie wachsen, desto komplexer und vielfältiger werden die Grenzen, die Sie durchsetzen müssen, um die Bedürfnisse bestimmter Kunden auszugleichen, den Zustand Ihres Dienstes zu schützen oder Grenzen in bestimmten Szenarien durchzusetzen und anzupassen. Die eigene API von Cloudflare steht vor dieser Herausforderung – jedes unserer Dutzende von Produkten, jedes mit vielen API-Endpunkten, muss möglicherweise unterschiedliche Durchsatzbegrenzungen durchsetzen.

Seit 2017 können Sie bei Cloudflare Regeln zur Durchsatzbegrenzung konfigurieren. Aber bis heute konnten Sie dies nur im Cloudflare-Dashboard oder über die Cloudflare-API steuern. Es war nicht möglich, das Verhalten zur Laufzeit zu definieren oder Code in Worker zu schreiben, der direkt mit den Durchsatzbegrenzungen interagiert – Sie konnten nur kontrollieren, ob eine Anfrage im Durchsatz begrenzt ist oder nicht, bevor sie Ihren Worker erreicht.

Heute stellen wir eine neue API in der Open Beta-Phase vor, mit der Sie direkt von Ihrem Worker aus auf die Durchsatzbegrenzungen zugreifen können. Es ist blitzschnell, wird von memcached unterstützt und lässt sich ganz einfach zu Ihrem Worker hinzufügen. In der folgenden Konfiguration wird beispielsweise ein Durchsatzlimit von 100 Anfragen innerhalb eines Zeitraums von 60 Sekunden festgelegt:

[[unsafe.bindings]]
name = "RATE_LIMITER"
type = "ratelimit"
namespace_id = "1001" # An identifier unique to your Cloudflare account

# Limit: the number of tokens allowed within a given period, in a single Cloudflare location
# Period: the duration of the period, in seconds. Must be either 60 or 10
simple = { limit = 100, period = 60 } 

Dann können Sie in Ihrem Worker die Limit-Methode für die RATE_LIMITER-Bindung aufrufen und einen Schlüssel Ihrer Wahl angeben. Mit der obigen Konfiguration gibt dieser Code einen HTTP 429-Antwortstatuscode zurück, wenn innerhalb von 60 Sekunden mehr als 100 Anfragen an einen bestimmten Pfad gestellt werden:

export default {
  async fetch(request, env) {
    const { pathname } = new URL(request.url)

    const { success } = await env.RATE_LIMITER.limit({ key: pathname })
    if (!success) {
      return new Response(`429 Failure – rate limit exceeded for ${pathname}`, { status: 429 })
    }

    return new Response(`Success!`)
  }
}

Nun kann Workers also eine direkte Verbindung zu einem Datenspeicher wie memcached herstellen. Was könnten wir nun noch anbieten? Zähler? Sperren? Einen In-Memory Cache? Rate Limiting ist die erste von vielen Primitiven, die wir in Workers bereitstellen wollen, und die sich mit der Frage befassen, wo ein temporärer gemeinsamer Status, der sich über viele Worker-Isolates erstreckt, gespeichert werden soll. Wenn Sie sich heute darauf verlassen, den Status in den globalen Bereich Ihres Workers zu legen, sollten Sie wissen: wir arbeiten an besseren Primitiven, die speziell für bestimmte Anwendungsfälle entwickelt werden.

Die Rate Limiting-API in Workers befindet sich in der Open Beta-Phase. Setzen Sie jetzt die ersten Schritte, indem Sie die Dokumentationen lesen.

Neue automatisch generierte SDKs für die API von Cloudflare

Production Readiness bedeutet, dass Sie Änderungen nicht mehr durch Anklicken von Schaltflächen in einem Dashboard vornehmen, sondern programmatisch, mit einem Infrastructure-as-Code-Ansatz wie Terraform oder Pulumi oder durch direkten API-Aufruf, entweder selbst oder über ein SDK.

Die Cloudflare-API ist riesig und es kommen ständig neue Funktionen hinzu – im Durchschnitt aktualisieren wir unsere API-Schemata zwischen 20- und 30-mal pro Tag. Bislang wurden unsere API-SDKs jedoch manuell erstellt und gewartet, weshalb wir dies unbedingt zeitnahe automatisieren wollten.

Das haben wir getan, und heute kündigen wir neue Client-SDKs für die Cloudflare-API in drei Sprachen an – Typescript, Python und Go – und weitere Sprachen werden schon bald unterstützt.

Jedes SDK wird automatisch mit Stainless API generiert, basierend auf den OpenAPI-Schemata, die die Struktur und die Fähigkeiten jedes unserer API-Endpunkte definieren. Das bedeutet, dass diese API-SDKs automatisch neu generiert und neue Versionen veröffentlicht werden, wenn wir der Cloudflare-API neue Funktionen für alle Cloudflare-Produkte hinzufügen, um sicherzustellen, dass sie korrekt und aktuell sind.

Sie können die SDKs installieren, indem Sie einen der folgenden Befehle ausführen:

// Typescript
npm install cloudflare

// Python
pip install --pre cloudflare

// Go
go get -u github.com/cloudflare/cloudflare-go/v2

Wenn Sie Terraform oder Pulumi nutzt, verwendet der Terraform Provider von Cloudflare im Hintergrund derzeit das bestehende, nicht automatisierte Go SDK. Wenn Sie terraform apply ausführen, bestimmt der Cloudflare Terraform Provider, welche API-Aufrufe in welcher Reihenfolge zu tätigen sind, und führt diese unter Verwendung des Go SDK aus.

Das neue, automatisch generierte Go-SDK ebnet den Weg zu einer umfassenderen Terraform-Unterstützung für alle Cloudflare-Produkte und bietet eine Basis von Tools, von denen man sicher sein kann, dass sie sowohl korrekt als auch auf dem neuesten Stand der API-Änderungen sind. Wir arbeiten an einer Zukunft, in der jedes Mal, wenn ein Produktteam bei Cloudflare eine neue Funktion entwickelt, die über die Cloudflare-API zugänglich ist, diese automatisch von den SDKs unterstützt wird. Im Laufe des Jahres 2024 erwarten Sie weitere Neuigkeiten zu diesem Thema.

Namespace-Analytics in Durable Object und WebSocket Hibernation allgemein verfügbar

Viele unserer eigenen Produkte, darunter Waiting Room, R2 und Queues, sowie Plattformen wie PartyKit, werden mit Durable Objects entwickelt. Weltweit eingesetzt, einschließlich der neu hinzugefügten Unterstützung für Ozeanien, können Sie sich Durable Objects wie singuläre Workers vorstellen, die einen einzigen Koordinationspunkt bereitstellen und den Status beibehalten können. Sie eignen sich perfekt für Anwendungen, die eine Echtzeit-Benutzerkoordination erfordern, wie z. B. interaktive Chats oder kollaborative Bearbeitung. Sehen Sie sich an, was Atlassian diesbezüglich zu sagen hat:

Eine unserer neuen Funktionen sind Confluence-Whiteboards, die eine freie Möglichkeit bieten, unstrukturierte Tätigkeiten wie Brainstorming und frühe Planung zu erfassen, bevor die Teams sie formeller dokumentieren. Das Team prüfte viele Optionen für die Zusammenarbeit in Echtzeit und entschied sich schließlich für Durable Objects von Cloudflare. Durable Objects haben sich als fantastische Lösung für dieses Problemfeld erwiesen, mit einer einzigartigen Kombination von Funktionalitäten, die es uns ermöglicht haben, unsere Infrastruktur stark zu vereinfachen und leicht auf eine große Anzahl von Benutzern zu skalieren. -Atlassian

Bisher haben wir im Dashboard keine zugehörigen analytischen Trends angezeigt, wodurch es schwierig war, die Nutzungsmuster und Fehlerraten innerhalb eines Durable Objects-Namespace zu verstehen, es sei denn, Sie haben die GraphQL Analytics-API direkt verwendet.  Das Dashboard für Durable Objects wurde nun überarbeitet und ermöglicht es Ihnen, Metriken aufzuschlüsseln so detailliert wie nötig zu analysieren.

Vom ersten Tag an hat Durable Objects WebSockets unterstützt, sodass sich viele Clients direkt mit einem Durable Object verbinden können, um Nachrichten zu senden und zu empfangen.

Manchmal öffnen Client-Anwendungen jedoch eine WebSocket-Verbindung und...machen dann irgendwann gar nichts mehr. Denken Sie an den Browser-Tab, den Sie in den letzten 5 Stunden in Ihrem Browser geöffnet hatten, aber nicht mehr angesehen haben. Wenn er WebSockets zum Senden und Empfangen von Nachrichten verwendet, hat er praktisch eine langlebige TCP-Verbindung, die für nichts verwendet wird. Wenn diese Verbindung zu einem Durable Object besteht, muss das Durable Object weiterlaufen und darauf warten, dass etwas passiert. Das verbraucht Speicherplatz und kostet Sie Geld.

Wir haben WebSocket Hibernation eingeführt, um dieses Problem zu lösen, und heute geben wir bekannt, dass diese Funktion die Beta-Phase verlassen hat und nun allgemein verfügbar ist. Mit WebSocket Hibernation legen Sie eine automatische Antwort fest, die während des Ruhezustands verwendet wird, und serialisieren den Status so, dass er den Ruhezustand überdauert. Dadurch erhält Cloudflare die Eingaben, die wir benötigen, um offene WebSocket-Verbindungen von Clients aufrechtzuerhalten, während das Durable Object in den Ruhezustand versetzt wird, sodass es nicht aktiv ausgeführt und Ihnen keine Leerlaufzeit in Rechnung gestellt wird. Dadurch ist Ihr Status immer dann im Speicher verfügbar, wenn Sie ihn tatsächlich benötigen, und wird nicht unnötig aufbewahrt, wenn er nicht benötigt wird. Solange sich Ihr Durable Object im Ruhezustand befindet, werden Ihnen keine Kosten für die Dauer in Rechnung gestellt, selbst wenn noch aktive Clients über einen WebSocket verbunden sind.

Außerdem haben wir Feedback von Entwicklern und Entwicklerinnen zu den Kosten eingehender WebSocket-Nachrichten an Durable Objects erhalten, die kleinere, häufigere Nachrichten für die Echtzeitkommunikation bevorzugen. Ab heute werden eingehende WebSocket-Nachrichten mit dem Äquivalent von 1/20 einer Anfrage berechnet (im Gegensatz zu 1 Nachricht als Äquivalent für 1 Anfrage, wie es bisher war). Nachfolgend ein Preisbeispiel:

Bereit zur Produktivsetzung, ohne die Komplexität des Produktivstarts

Damit Sie Ihre Entwicklungen auf den Cloud-Plattformen produktiv schalten konnten, mussten Sie bislang die Geschwindigkeit der Veröffentlichung drosseln. Hierfür mussten Sie meist ein Flickwerk an unzusammenhängenden Tools zusammenfügen oder ganze Teams für die Arbeit an internen Plattformen zusammenstellen. Sie mussten Ihre eigenen produktiven Ebenen auf Plattformen nachrüsten, die Ihnen Steine in den Weg legten.

Die Entwicklungsplattform von Cloudflare ist ausgereift und bereit für den Produktivbetrieb. Sie wurde als integrierte Plattform konzipiert, auf der Produkte intuitiv miteinander eingesetzt werden können. Es gibt keine überflüssigen Möglichkeiten zur Kombination von Tools, deren gemeinsame Verwendung nur über eine mühsame Kompatibilitätsmatrix erschlossen werden könnte. Jedes dieser Updates stellt dies unter Beweis, indem neue Funktionen in alle Produkte und Teile der Cloudflare-Plattform integriert werden.

Darum möchten wir von Ihnen nicht nur wissen, was Sie als Nächstes sehen möchten, sondern auch, welche Aspekte unserer Plattform wir Ihrer Ansicht nach noch einfacher gestalten bzw. in welchen Bereichen unsere Tools noch besser gemeinsam eingesetzt werden könnten. Wir freuen uns auf Ihr Input – jederzeit gerne im Cloudflare Developers-Discord.