Deno celld, Durable Objects를 내 서버에서 돌려요

Deno celld, Durable Objects를 내 서버에서 돌려요

IT & AI 뉴스 썸네일

Cloudflare Durable Objects의 실행 모델을 자체 인프라로 옮길 수 있는 선택지가 생겼어요. Deno가 공개한 celld는 Worker 코드와 객체별 SQLite 데이터를 사용자가 관리하는 서버와 오브젝트 스토리지에서 실행해요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
실행 환경	V8에서 Wrangler 번들을 실행해요	기존 Worker 프로젝트를 옮길 때 바꿔야 할 범위를 줄였어요
상태 저장	객체마다 전용 SQLite 데이터베이스를 둬요	사용자·문서·채팅방처럼 상태 단위를 작게 나눌 수 있어요
분산 구조	공유 버킷으로 소유권과 상태를 조정해요	별도 컨트롤 플레인이나 합의 서버 없이 노드를 늘릴 수 있어요
운영 범위	TLS·인증·인그레스는 운영자가 맡아요	알파 단계라 공개 서비스에 바로 넣기 전 점검이 필요해요

1. Cloudflare의 상태 모델을 자체 인프라로 옮겨요

celld는 Cloudflare Workers와 Durable Objects를 자체 서버에서 실행하는 Apache 2.0 오픈소스 데몬이에요. 각 노드는 V8을 내장하고 Wrangler 번들을 실행해요. Module Worker의 `fetch`, Service Binding, Durable Object, 정적 자산 같은 기능을 지원해 기존 프로젝트의 구조를 상당 부분 유지할 수 있어요. 2

객체 하나가 작은 서버이자 데이터베이스예요

celld는 이름이 붙은 Durable Object 하나를 `cell`로 다뤄요. 각 cell에는 전용 SQLite 데이터베이스와 한 명의 writer가 있어요. 사용자, 공동 문서, 채팅방처럼 상태의 경계를 cell 단위로 잡으면 하나의 공유 데이터베이스에 쓰기 요청이 몰리는 상황을 줄일 수 있어요.

728x90

cell을 맡은 노드는 SQLite 상태를 S3 호환 버킷이나 Google Cloud Storage에 계속 복제해요. 사용하지 않는 cell은 비활성 상태로 내려가고, 요청이 다시 오면 다른 노드가 버킷에서 데이터를 복원해 실행을 이어가요. 저장 버킷이 지속 상태의 기준점이고 실행 노드는 교체할 수 있는 구조예요. 2

공유 버킷이 노드 사이의 조정도 맡아요

여러 노드는 같은 버킷의 배포 파일, cell 상태, 소유권 레코드를 읽어요. 오브젝트 스토리지의 조건부 쓰기를 이용해 한 시점에 한 노드만 특정 cell을 맡도록 조정해요. 중앙 배치 제어기, 고정된 멤버십 목록, 별도 합의 서비스가 없어요.

노드를 추가할 때도 가입용 서비스를 거치지 않아요. 같은 버킷을 바라보도록 실행하면 돼요. 다만 새 노드가 들어왔다고 기존 cell을 자동으로 고르게 재배치하지는 않아요. 소유자가 없거나 반환된 cell에 트래픽이 들어올 때 여유가 있는 노드가 가져가요. 3

Cloudflare 전체를 복제하지는 않아요

현재 범위에는 Durable Object의 Alarm, WebSocket, RPC가 들어가요. D1과 Workflows 지원은 향후 계획에 포함돼 있어요. KV, R2, Workers AI, Vectorize, Hyperdrive처럼 별도 관리형 서비스는 celld가 대신하지 않아요. Cloudflare 플랫폼 전체의 로컬판으로 보면 지원 범위를 잘못 잡기 쉬워요. 1

운영 경계도 분명해요. 한 fleet은 애플리케이션 배포 하나만 실행하고 멀티테넌트 스케줄러나 관리형 인그레스를 제공하지 않아요. 로컬 파일시스템 모드도 없어서 개발 환경에서도 조건부 쓰기를 지원하는 실제 버킷이나 호환 스토리지가 필요해요. Windows용 바이너리와 Intel Mac용 사전 빌드도 아직 없어요. 3

왜 중요한가요

Durable Objects의 장점은 상태와 연산을 같은 객체 경계에 두는 데 있어요. celld를 쓰면 이 모델을 유지하면서 실행 머신과 저장소 계정을 직접 고를 수 있어요. 규제나 비용 때문에 특정 클라우드 계정에 상태를 묶기 어려운 팀, S3 호환 스토리지를 중심으로 인프라를 운영하는 팀이 검토할 만해요. 2

대신 관리형 서비스가 맡던 운영 책임도 팀으로 넘어와요. celld는 공개 TLS와 사용자 인증을 처리하지 않아요. 내부 listener의 운영 API에도 자체 인증이 없어서 방화벽이나 WireGuard·Tailscale 같은 사설 네트워크로 접근을 제한해야 해요. 버킷에는 배포 상태와 cell 데이터뿐 아니라 노드 소유권, 공유 인증 비밀도 들어가므로 버킷 자격 증명이 사실상 fleet 관리자 권한이에요. 4

아직 알파 버전이고 적대적인 멀티테넌트 환경에는 안전하지 않다고 프로젝트가 명시해요. 공개 서비스에 도입하려면 호환되는 Worker API를 먼저 확인하고, TLS 종료·인그레스·인증·버킷 권한·장애 복구를 직접 설계해야 해요. 작은 내부 서비스나 검증 환경에서 현재 제약을 확인한 뒤 범위를 넓히는 편이 현실적이에요. 3

참고 자료

1. celld - 셀프호스팅 가능한 분산 Durable Objects — GeekNews
2. denoland/celld — GitHub
3. celld Limitations — Deno
4. celld Security — Deno