Jak uruchomić Cloudflare Durable Objects na własnych serwerach za pomocą celld

Ryan Dahl i zespół Deno cicho udostępnili projekt celld jako open source. Jeśli kiedykolwiek zazdrościłeś użytkownikom Cloudflare ich koncepcji Durable Objects, ale nie chciałeś mieć do czynienia z vendor lock-in, to może cię zainteresować.

celld to demon runtime w Rust, który może uruchamiać pakiety Cloudflare Workers i izolowane instancje Durable Objects na własnym sprzęcie. Bez Etcd, bez Raft i bez ciężkich usług koordynacyjnych.

Istota koncepcji

Tradycyjne backendy są zazwyczaj podzielone na bezstanowe mikrousługi i jedną dużą relacyjną bazę danych. Wraz ze wzrostem obciążenia baza danych nieuchronnie staje się głównym wąskim gardłem.

Cloudflare zaproponował inne podejście. Każda aktywna encja aplikacji (na przykład pokój czatowy, koszyk zakupowy czy sesja dokumentu) otrzymuje własny izolat V8 i osobistą bazę danych SQLite. Obiekt budzi się, gdy nadejdzie żądanie, przechowuje stan w pamięci i lokalnym pliku SQLite, a po prostu zasypia, gdy jest bezczynny.

Głównym problemem była zamknięta natura ekosystemu: uruchomienie takiej konfiguracji poza infrastrukturą Cloudflare było praktycznie niemożliwe aż do teraz.

Jak celld działa wewnętrznie

Deweloperzy celld postawili na radykalne uproszczenie. Architektura węzła składa się z czterech komponentów:

1. Osadzony V8 do wykonywania kodu JavaScript i TypeScript z pakietów Wrangler.
2. Lokalny SQLite dla osobnego pliku bazy danych każdego obiektu.
3. Magazyn kompatybilny z S3 (AWS S3, MinIO, Cloudflare R2) jako jedyne źródło prawdy.
4. Transport międzyserwerowy z podpisem HMAC do wymiany danych między węzłami.

Najciekawszym rozwiązaniem jest tutaj porzucenie klasycznych protokołów konsensusu. Węzły klastra nie muszą wybierać lidera ani uruchamiać Consul.

Zamiast tego serwery komunikują się z S3 poprzez atomową operację Compare-And-Swap (CAS). Gdy węzeł chce przejąć własność obiektu, zapisuje plik własności do bucketa S3. Kto pierwszy zaktualizuje rekord przez CAS, ten obsługuje ruch. Jeśli węzeł ulegnie awarii, limit czasu zapisu wygasa, a sąsiedni serwer przejmuje obiekt, pobiera jego świeżą bazę danych SQLite z bucketa i kontynuuje pracę.

Uruchomienie i wdrożenie

Standardowe kompilacje Wrangler działają do budowania projektu, ale potrzebujesz serwera z 5 i samego pliku binarnego 6.

Instalacja odbywa się jednym poleceniem:

0

Przepływ pracy jest podzielony na dwa kroki. Najpierw prześlij build workera do bucketa:

1

Następnie uruchom demona na serwerze:

2

Każdy węzeł w klastrze odczytuje manifest 7 z bucketa. Jeśli chcesz uruchomić dodatkowy serwer, uruchamiasz kolejny proces z tym samym bucketem i podajesz jego adres sieciowy w 8.

Jeśli chodzi o bezpieczeństwo: ruch międzyserwerowy celld nie szyfruje TLS out of the box. Autorzy zalecają umieszczenie wewnętrznych portów węzłów za bezpieczną siecią overlay jak WireGuard lub Tailscale. Wszystkie żądania peer-to-peer są automatycznie podpisywane kluczem HMAC 9, który pierwszy węzeł tworzy automatycznie w buckecie.

Diagnostyka i zarządzanie obciążeniem

Do monitorowania klastra dostępna jest utilita 10. Odpytuje sąsiadów i wyświetla aktualne metryki:

3

Polecenie wyświetli zużycie CPU, pamięć RSS, liczbę aktywnych połączeń WebSocket oraz liczbę aktywnych obiektów na każdym węźle.

Jeśli serwer zaczyna być przeciążony, celld ma mechanizm zrzucania ciśnienia dla aktywnych obiektów. Limity ustawia się przez zmienne środowiskowe:

4

Gdy próg zostanie przekroczony, celld zapisuje nieaktywne obiekty do S3, zwalnia własność i przestaje akceptować nowe encje, dopóki obciążenie nie spadnie do wartości 11. Obiekty z częstymi żądaniami lub otwartymi połączeniami WebSocket nie są dotknięte.

Nietypowe podejście do wkładu w projekt

Jeśli przejdziesz do repozytorium 12 z zamiarem otwarcia Pull Requesta, znajdziesz przycisk wyłączony. Forki są dozwolone, ale PR-y na GitHub są całkowicie wyłączone.

Ryan Dahl tłumaczy to walką ze spamem z agentów AI: przeglądanie ogromnych automatycznie generowanych pull requestów bez kontekstu zabiera zbyt wiele czasu maintainerom. Osoby chcące wysłać patch są proszone o wykonanie 13 i wysłanie pliku e-mailem na osobisty adres 14.

Kto powinien przyjrzeć się temu projektowi

Projekt jest aktywnie rozwijany, a specyfikacje protokołów są przechowywane bezpośrednio w kodzie crate'a Rust 15. Jest zbyt wcześnie, aby wciągać go do krytycznej produkcji, ale eksperymentowanie zdecydowanie warto.

Narzędzie będzie przydatne w następujących przypadkach:

1. Deweloperzy usług wieloosobowych, czatów i niestandardowych CRM-ów.
2. Zespoły planujące odejście od Cloudflare lock-in bez przepisywania kodu.
3. Entuzjaści architektury z osobną bazą danych na klienta-użytkownika.
4. Inżynierowie uczący się o systemach rozproszonych bez Raft i Etcd.