So führen Sie Cloudflare Durable Objects auf Ihren eigenen Servern mit celld aus

Ryan Dahl und das Deno-Team haben das celld-Projekt still und leise als Open-Source veröffentlicht. Wenn Sie Cloudflare-Nutzer um ihr Durable-Objects-Konzept beneidet haben, sich aber nicht mit Vendor Lock-in herumschlagen wollten, könnte Sie das interessieren.

celld ist eine Rust-Daemon-Runtime, die Cloudflare-Workers-Bundles und isolierte Durable-Objects-Instanzen auf eigener Hardware ausführen kann. Ohne Etcd, ohne Raft und ohne heavyweight Koordinationsdienste.

Das Kernkonzept

Traditionelle Backends sind typischerweise in stateless Microservices und eine einzelne große relationale Datenbank aufgeteilt. Mit steigender Last wird die Datenbank unvermeidlich zum Hauptengpass.

Cloudflare hat einen anderen Ansatz vorgeschlagen. Jede aktive Anwendungseinheit (beispielsweise ein Chatroom, ein Warenkorb oder eine Dokumentsitzung) erhält ihren eigenen V8-Isolate und eine persönliche SQLite-Datenbank. Das Objekt erwacht, wenn eine Anfrage eingeht, hält den Zustand im Speicher und in einer lokalen SQLite-Datei und schläft einfach ein, wenn es inaktiv ist.

Das Hauptproblem war die geschlossene Natur des Ökosystems: Ein solches Setup außerhalb der Cloudflare-Infrastruktur zu betreiben, war bis jetzt praktisch unmöglich.

Wie celld intern funktioniert

Die celld-Entwickler haben auf radikale Vereinfachung gesetzt. Die Knotenarchitektur besteht aus vier Komponenten:

1. Embedded V8 für die Ausführung von JavaScript- und TypeScript-Code aus Wrangler-Bundles.
2. Lokales SQLite für die separate Datenbankdatei jedes Objekts.
3. S3-kompatibler Speicher (AWS S3, MinIO, Cloudflare R2) als einzige Quelle der Wahrheit.
4. Transport zwischen Servern mit HMAC-Signierung für den Datenaustausch zwischen Knoten.

Die interessanteste Lösung hier ist der Verzicht auf klassische Konsensprotokolle. Clusterknoten müssen keinen Leader wählen oder Consul ausführen.

Stattdessen kommunizieren Server über eine atomare Compare-And-Swap-Operation (CAS) mit S3. Wenn ein Knoten die Kontrolle über ein Objekt übernehmen möchte, schreibt er eine Besitzdatei in den S3-Bucket. Wer den Datensatz per CAS zuerst aktualisieren kann, bearbeitet den Datenverkehr. Wenn ein Knoten abstürzt, läuft das Write-Timeout ab und ein benachbarter Server übernimmt das Objekt, lädt seine frische SQLite-Datenbank aus dem Bucket herunter und fährt fort.

Start und Deployment

Standard-Wrangler-Builds funktionieren für das Erstellen des Projekts, aber Sie benötigen einen Server mit 5 und das Binary selbst 6.

Die Installation erfolgt mit einem einzigen Befehl:

0

Der Workflow ist in zwei Schritte unterteilt. Zuerst laden Sie den Worker-Build in den Bucket hoch:

1

Dann starten Sie den Daemon auf dem Server:

2

Jeder Knoten im Cluster liest das Manifest 7 aus dem Bucket. Wenn Sie einen zusätzlichen Server hochfahren müssen, starten Sie einen weiteren Prozess mit demselben Bucket und geben seine Netzwerkadresse in 8 an.

Was die Sicherheit betrifft: Der Server-übergreifende Datenverkehr von celld verschlüsselt TLS nicht standardmäßig. Die Autoren empfehlen, die internen Knotenports hinter einem sicheren Overlay-Netzwerk wie WireGuard oder Tailscale zu platzieren. Alle Peer-Anfragen werden automatisch mit einem HMAC-Schlüssel 9 signiert, den der erste Knoten automatisch im Bucket erstellt.

Diagnose und Lastmanagement

Für die Clusterüberwachung gibt es das 10-Dienstprogramm. Es fragt Nachbarn ab und zeigt aktuelle Metriken:

3

Der Befehl gibt CPU-Verbrauch, RSS-Speicher, die Anzahl aktiver WebSocket-Verbindungen und die Anzahl lebender Objekte auf jedem Knoten aus.

Wenn ein Server überlastet wird, verfügt celld über einen Pressure-Shedding-Mechanismus für aktive Objekte. Limits werden über Umgebungsvariablen gesetzt:

4

Wenn der Schwellenwert überschritten wird, speichert celld inaktive Objekte in S3, gibt den Besitz auf und akzeptiert keine neuen Entitäten, bis die Last auf den Wert von 11 sinkt. Objekte mit häufigen Anfragen oder offenen WebSocket-Verbindungen sind nicht betroffen.

Ein ungewöhnlicher Ansatz für Beiträge

Wenn Sie das 12-Repository besuchen, um einen Pull Request zu öffnen, werden Sie feststellen, dass der Button deaktiviert ist. Forks sind erlaubt, aber PRs auf GitHub sind vollständig deaktiviert.

Ryan Dahl erklärt dies als Kampf gegen Spam von KI-Agenten: Das Prüfen von riesigen automatisch generierten Pull Requests ohne Kontext kostet den Maintainern zu viel Zeit. Diejenigen, die einen Patch senden möchten, werden gebeten, 13 zu erstellen und die Datei an die persönliche Adresse 14 zu mailen.

Für wen lohnt sich ein Blick auf dieses Projekt

Das Projekt befindet sich in aktiver Entwicklung, mit Protokollspezifikationen direkt im Rust-Crate-Code 15 gespeichert. Für kritische Produktion ist es noch zu früh, aber Experimentieren lohnt sich definitiv.

Das Tool ist in folgenden Fällen nützlich:

1. Entwickler von Multiplayer-Diensten, Chats und benutzerdefinierten CRMs.
2. Teams, die planen, Cloudflare-Lock-in zu verlassen, ohne Code umzuschreiben.
3. Liebhaber der Architektur mit einer separaten Datenbank pro Client-Benutzer.
4. Ingenieure, die mehr über verteilte Systeme ohne Raft und Etcd lernen möchten.