▲

OpenWorkers – Rust로 구현된 셀프호스팅 Cloudflare Workers

 (openworkers.com)
18P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • OpenWorkers는 V8 기반에서 JavaScript를 실행하는 오픈소스 런타임으로, 엣지 컴퓨팅을 자체 인프라에서 구현할 수 있음
  • KV 저장소, PostgreSQL, S3/R2 호환 스토리지, 서비스 바인딩, 환경 변수 및 시크릿을 지원
  • fetch, ReadableStream, crypto.subtle 등 주요 Web API를 포함해 Cloudflare Workers와 높은 호환성 유지
  • V8 Isolate 샌드박스, 크론 스케줄링, Docker Compose 기반 배포 등으로 간단한 셀프호스팅 가능
  • 약 7년간 발전해온 프로젝트로, 벤더 종속 없는 JavaScript 실행 환경을 목표로 함

OpenWorkers 개요

  • OpenWorkers는 Rust로 작성된 Cloudflare Workers 호환 런타임으로, V8 Isolate를 이용해 JavaScript를 실행
    • 엣지 컴퓨팅의 장점을 자체 서버 환경에서도 활용 가능
    • 오픈소스로 공개되어 자유롭게 배포 및 수정 가능

주요 기능

  • 바인딩(Bindings) 기능을 통해 다양한 외부 리소스와 연동
    • KV 스토리지: get, put, delete, list 지원
    • PostgreSQL 데이터베이스 연동
    • S3/R2 호환 스토리지 지원
    • 서비스 바인딩, 환경 변수 및 시크릿 관리 포함
  • Web API 지원
    • fetch, Request, Response, ReadableStream 등 표준 API 제공
    • crypto.subtle, TextEncoder/Decoder, Blob, setTimeout, AbortController 포함

아키텍처

  • 시스템은 nginx 프록시, 대시보드, API, 로그 서비스, 러너(runner) , PostgreSQL, NATS, 스케줄러 등으로 구성
    • 각 러너는 V8 Isolate 내에서 코드를 실행하며, CPU 100ms, 메모리 128MB 제한 적용
    • 5~6 필드 크론 문법을 지원하는 내장 스케줄러 포함
    • Cloudflare Workers와 문법 호환성 유지

셀프호스팅

  • 배포는 단일 PostgreSQL 데이터베이스와 Docker Compose 파일만으로 가능
    • git clone, .env 설정, docker compose up 명령으로 손쉽게 실행
    • 마이그레이션 및 토큰 생성 절차 포함

개발 배경

  • 약 7년간의 개발 과정을 거쳐 완성된 프로젝트
    • 초기에는 vm2로 JS 샌드박싱을 실험, 이후 Cloudflare Workers 모델에 영감을 받아 발전
    • Deno-core를 거쳐 현재는 rusty_v8 기반으로 재작성
  • 목표는 Cloudflare Workers 수준의 개발 경험(DX) 을 제공하면서 벤더 종속을 제거한 자체 서버 실행 환경 구축
  • 향후 실행 기록 및 재생 기능을 통한 결정적 디버깅(deterministic debugging) 기능 추가 예정
▲
GN⁺ 4일전  [-]
Hacker News 의견들

  • 엣지 컴퓨팅의 힘을 자체 인프라로 가져온다는 개념이 흥미로움
    하지만 셀프호스팅은 엣지 컴퓨팅의 본질과는 다소 상충된다고 느낌
    Cloudflare 같은 대형 벤더가 전 세계에 300개 이상의 PoP(Point of Presence)를 두고 있기에 가능한 모델임
    물론 더 작고 윤리적인 벤더들을 조합해 비슷한 구조를 만들 수는 있지만, 훨씬 많은 노력과 리스크가 따름

    • 엣지 모델의 이점을 얻기 위해 꼭 300개의 PoP가 필요한지 의문임
      주요 지역에 10개 정도만 있어도 충분하지 않을까 생각함
    • Cloudflare의 독점을 깨기 위해 분산형 호스트 네트워크가 협력하는 모델이 가능할지 궁금함
      안전하고 신뢰성 있게 조율하기가 너무 어렵지 않을까 하는 우려도 있음

  • 샌드박스 솔루션의 문제는 코드가 샌드박스를 탈출하지 못한다는 강력한 보장을 해야 한다는 점임
    이를 입증하려면 다양한 공격 시나리오에 대한 테스트 결과와 상세한 문서가 필요함
    하지만 이런 수준의 문서는 매우 드물고, 실제로 신뢰할 만한 예시를 찾기 어려움
    그래서 나는 대기업이 실제 프로덕션 환경에서 사용하며 보안팀이 유지보수하는 사례가 있는지를 확인함

    • 나도 동의함. AI가 생산성을 높이긴 하지만, 고보안 환경에서 “Claude의 도움으로 rusty_v8 위에 다시 작성했다”는 말은 오히려 걱정스러움
    • Cloudflare Workers 런타임이 안전한 이유 중 하나는 V8 메인라인과의 동기화를 매우 적극적으로 유지하기 때문임
      심지어 Chrome보다 먼저 V8 릴리스를 적용하기도 함
    • V8 isolate는 메모리 격리를 제공하고, CPU(100ms)와 메모리(128MB) 제한을 둠
      각 워커는 별도 프로세스가 아닌 isolate로 실행되어 Cloudflare 모델과 유사함
      하지만 완전히 신뢰할 수 없는 서드파티 코드를 다룰 때는 컨테이너나 VM으로 한 겹 더 격리하는 게 좋음
      이 샌드박싱은 보안보다는 리소스 격리에 초점이 맞춰져 있음
    • 그런 완벽한 보장을 요구하는 건 비현실적이라 생각함
      “우리가 검증했고 안전합니다, 믿어주세요” 수준의 보안 감사로는 충분하지 않음
    • Cloudflare는 사용자 코드가 악의적일 수 있으니 샌드박스 보안이 필수지만,
      셀프호스팅 환경에서는 이미 시스템 접근 권한이 있으므로 샌드박스 탈출을 걱정할 필요가 적음

  • 멋진 프로젝트라고 생각함
    workerd가 오픈소스라면, OpenWorkers의 차별점은 완전한 환경을 제공한다는 점인지 궁금함
    런타임 자체의 차이점이나, 향후 매니지드 서비스 계획이 있는지도 알고 싶음

    • 주요 차이점은 세 가지임
      1️⃣ workerd는 런타임만 제공하지만 OpenWorkers는 대시보드, API, 스케줄러, 로그, 바인딩(KV, S3/R2, Postgres) 까지 포함한 완전한 플랫폼임
      2️⃣ workerd는 C++ 기반, OpenWorkers는 Rust + rusty_v8 기반으로 더 단순하고 해킹하기 쉬움
      3️⃣ 이미 dash.openworkers.com에 매니지드 버전이 있으며, 무료 티어도 있음
      하지만 셀프호스팅이 1급 시민으로 설계되어 있음

  • Cloudflare Workers의 핵심은 함수 단위 과금인데, 셀프호스팅이라면 결국 하드웨어를 미리 확보해야 함

    • 여전히 많은 기업이 자체 데이터센터 서버를 운영함
      모든 걸 외주로 맡길 필요는 없고, 유사한 선택지가 존재하는 건 좋은 일임
      이런 옵션이 도입 장벽을 낮추는 데 도움이 됨

  • 예전에 deno_core를 분리하는 작업을 많이 했는데, raw rusty_v8으로 옮긴 걸 이해함
    deno_core에는 레거시 코드가 많아서 수정 시 테스트가 자주 깨졌음

    • 감사함! deno_core는 여전히 훌륭한 코드베이스라 openworkers-runtime-deno로 유지 중임
      하지만 런타임 내부를 더 세밀하게 제어하기 위해 rusty_v8로 옮겼고,
      나중에 deno 런타임에도 누락된 기능을 다시 추가할 계획임

  • 벤더 종속성 감소를 돕는 프로젝트라면 무조건 찬성임
    클라우드 서비스들이 가격을 현실화하도록 압박받길 바람
    지금은 NAT 같은 기본 기능에도 과도한 요금을 부과함
    물론 클라우드는 편리하지만, DIY 대비 높은 비용이 문제임

    • Cloudflare Workers 런타임은 이미 오픈소스임: cloudflare/workerd
    • 최근 RAM 가격 상승이 셀프호스팅을 더 어렵게 만들까 걱정됨
      대기업들이 자원을 독점하면 개인이 직접 호스팅하기 힘들어질 수 있음
    • NAT 비용이 ‘무료보다 비싸다’는 표현이 흥미로움
      하지만 실제로는 많은 나라에서 직접 운영하는 비용이 더 큼
      설치만으로 끝나는 게 아니라, 유지보수 인력과 모니터링 비용이 상당함

  • 현재 동작하지 않는 기능이나 로드맵을 문서에 명시하면 좋겠음

    • 좋은 제안임! 아직 구현되지 않은 기능은 Durable Objects, WebSockets, HTMLRewriter, cache API임
      다음 우선순위는 디버깅용 실행 기록/재생 기능이며, 문서에 로드맵 섹션을 추가할 예정임

  • ASCII 아키텍처 다이어그램이 Pixel + Firefox에서 깨져 보임
    텍스트 기반 다이어그램은 매력적이지만, 실제로는 이미지로 컴파일된 버전을 게시하는 게 더 실용적임

    • 제보 고마움! 모바일용으로 단순화된 ASCII 버전을 추가해 수정함
    • 내 iPhone 11 Safari에서는 완벽히 렌더링됨

  • 기술적으로나 구조적으로나 훌륭한 제품 아이디어임
    특히 대형 벤더의 오픈소스 프로젝트를 역으로 오픈소스로 되갚는 모델이 마음에 듦
    즉, 그들이 오픈소스를 가져다 상업화하는 대신, 우리는 그들의 모델을 오픈소스로 되돌리는 방식임 — 바로 이런 접근이 옳다고 생각함

  • “클라우드를 우리 컴퓨터에 직접 호스팅하면 어떨까?”라는 흐름이 다시 돌아온 것 같음
    최근 이런 셀프호스팅 트렌드가 여러 곳에서 보임
    관련된 발표 영상도 흥미로움

    • 하지만 그건 더 이상 ‘클라우드’라고 부르기 어렵다고 생각함
      클라우드의 핵심은 탄력성(elasticity) 임
      필요에 따라 인스턴스를 늘리고 줄이며, 사용한 만큼만 비용을 내는 구조임
      셀프호스팅은 배포 도구는 편리하지만, 결국 서버 전체 비용을 감당해야 함
      부하가 일정하거나 예측 가능한 경우엔 괜찮지만, 그렇지 않다면 비효율적임
      (비유하자면 버스를 타는 것과 밴을 소유하는 것의 차이임)
    • FaaS(Function-as-a-Service)의 가치는 ‘클라우드’라는 단어보다 이벤트 중심 프레임워크 제공에 있음
      개발자는 이벤트 핸들러 구현에 집중할 수 있고, 큐나 내구성 있는 실행을 포함하면 더 강력해짐
      결국 FaaS는 보일러플레이트 코드를 추상화해주는 고수준 도구임
답변달기