Deno 큐

 (deno.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Deno Queues는 Deno KV 위에 올라간 서버리스 분산 큐로, 오래 걸리는 작업을 비동기로 넘기거나 미래 시점 실행을 예약할 수 있게 함
  • 개발자는 .enqueue() 로 메시지를 넣고 .listenQueue() 로 처리하면 되며, 별도 큐 인프라를 설정하거나 유지하지 않아도 됨
  • 로컬에서는 SQLite, Deno Deploy에서는 FoundationDB를 사용하고, Deploy는 메시지 처리 시점에 V8 isolate를 온디맨드로 띄워 실행함
  • 전달 방식은 at-least-once delivery라서 장애나 재시도 상황에서는 같은 메시지가 여러 번 처리될 수 있음
  • 별도 큐 과금은 없지만 enqueue는 KV 쓰기, 메시지 수신은 KV 쓰기와 Deno Deploy 요청으로 계산되므로 중복 처리와 비용 구조를 함께 고려해야 함

Deno Queues가 맡는 일

  • Deno Queues는 Deno KV 기반 큐 기능으로, 애플리케이션의 일부 처리를 비동기 작업으로 넘기거나 나중에 실행할 작업을 예약할 수 있음
  • Deno는 클라우드 소프트웨어 개발에서 반복 설정과 인프라 구성을 줄이고, 개발자가 더 빠르게 설계·개선·출시할 수 있는 기본 요소를 제공하는 것을 목표로 함
  • Deno KV는 FoundationDB 기반 지속성 옵션이며, 현재 오픈 베타 상태임
  • Queues는 Deno KV 위에서 확장 가능한 메시징과 백그라운드 처리 관리를 제공함

기본 API와 실행 방식

  • Deno Queues의 핵심 API는 두 가지임
    • .enqueue(): 새 메시지를 큐에 넣고 즉시 또는 미래 시점에 전달되도록 함
    • .listenQueue(): 큐에서 새 메시지를 받아 처리하는 핸들러로 사용함
  • 기본 흐름은 Deno.openKv()로 KV를 열고, listenQueue에서 Slack 메시지를 전송하며, enqueue에 { delay: 60000 }을 지정해 60초 뒤 처리되도록 하는 방식임
  • 실행 환경에 따라 저장소가 달라짐
    • 로컬 실행 시 SQLite 사용
    • Deno Deploy 실행 시 FoundationDB 사용
  • Deno Deploy에서는 메시지 처리 가능 시점에 V8 isolate를 온디맨드로 실행하고 메시지를 디스패치함
  • 애플리케이션 코드는 listenQueue 핸들러로 새 메시지를 받으면 되고, 나머지 실행 관리는 Deno Deploy가 맡음

전달 보장과 재시도

  • Deno Queues는 at-least-once delivery를 보장함
  • 대부분의 enqueue 메시지는 listenQueue 핸들러를 한 번만 호출하지만, 일부 실패 상황에서는 전달 보장을 위해 같은 핸들러가 여러 번 호출될 수 있음
  • 따라서 애플리케이션은 중복 메시지 처리를 안전하게 다뤄야 함
  • listenQueue 핸들러가 예외를 던지면 런타임이 호출을 자동으로 재시도함
  • 재시도는 성공하거나 최대 재시도 횟수에 도달할 때까지 이어지며, 현재 기본 최대값은 5회임
  • 최대 재시도 횟수에 도달한 메시지는 삭제됨

KV atomic transaction과 함께 쓰기

  • Deno Queues는 KV atomic transactions와 결합할 수 있음
  • 메시지를 KV 트랜잭션의 일부로 enqueue하면 전체 트랜잭션이 성공할 때에만 메시지가 큐에 들어감
  • 예시 흐름은 Bob과 Liz의 잔액을 확인하고 갱신한 뒤, 두 사람에게 알림 메시지를 enqueue함
    • check(bob, liz)로 상태를 확인함
    • Bob 잔액을 줄이고 Liz 잔액을 늘림
    • enqueue로 Liz와 Bob에게 각각 알림 메시지를 추가함
    • commit()이 성공해야 전체 변경과 enqueue가 반영됨
  • listenQueue 핸들러 안에서도 Deno KV 상태를 갱신할 수 있음
  • 메시지별 업데이트를 한 번만 수행하려면 nonce를 저장하고 삭제하는 방식으로 중복 처리 방지 흐름을 구성할 수 있음
    • enqueue 시 nonce를 함께 저장함
    • 처리 시 nonce가 없으면 바로 반환함
    • 처리 성공 시 nonce를 삭제하고 카운터와 잔액 상태를 함께 갱신함

큐가 어울리는 사용 사례

  • 큐는 서버가 비동기 처리를 넘기고 미래 작업을 예약할 수 있게 해 애플리케이션 확장에 유용함

  • 예약 이메일 알림

    • 사용자가 시작한 작업이 오래 걸리거나 완료 응답을 기다릴 필요가 없을 때 큐로 작업을 넘겨 서버나 앱의 응답성을 유지할 수 있음
    • 예시에서는 welcome_email 메시지를 즉시 enqueue하고, survey_email 메시지는 { delay: 259200000 }으로 지연 실행함

  • 신뢰성 있는 웹훅 처리

    • 웹훅 요청을 바로 처리하지 않고 큐에 넣으면 응답과 실제 처리를 분리할 수 있음
    • Oak와 Queues를 함께 사용해 /webhook POST 요청을 받으면 요청 본문을 큐에 넣고 HTTP 200을 반환함
    • 실제 웹훅 처리는 listenQueue에서 processWebHook으로 비동기 수행함

  • Slack·Discord 봇

    • Queues는 Discord나 Slack 봇 구축에도 사용할 수 있음
    • Slack reminder app 예시는 Deno Queues로 간단한 Slack 리마인더 앱을 만드는 사례임
    • Discord bot 예시는 Deno Queues로 giveaway를 만들고 사용자가 한 번의 클릭으로 참여할 수 있게 함
    • 더 많은 큐 사용 예시는 docs.deno.com에서 확인할 수 있음

과금 방식

  • Deno Queues에는 별도 전용 과금 항목이 없음
  • 비용은 Deno KV 작업과 Deno Deploy 요청 기준으로 계산됨
    • 메시지 enqueue: 각 enqueue 동작은 KV 쓰기 작업 1건에 해당함
    • 메시지 수신: 수신된 메시지마다 KV 쓰기 1건과 요청 요금 1건이 발생함
  • 사용한 작업만 비용으로 청구되는 구조임

문서와 로드맵

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 방금 로컬 SQLite 버전 내부를 파고들어 메모를 정리했음: https://til.simonwillison.net/deno/deno-kv#user-content-deno...
    가장 흥미로운 부분은 아마 이 기능에 쓰는 스키마임:
    CREATE TABLE queue ( ts integer not null, id text not null, data blob not null, backoff_schedule text not null, keys_if_undelivered blob not null, primary key (ts, id) );
    CREATE TABLE queue_running( deadline integer not null, id text not null, data blob not null, backoff_schedule text not null, keys_if_undelivered blob not null, primary key (deadline, id) );
    CREATE INDEX kv_expiration_ms_idx on kv (expiration_ms);

    • 거의 같은 필드를 가진 테이블 2개를 만들고 행을 옮기는 건 보통 나쁜 관행 아닌가 싶음
      인덱스가 바로 그런 용도로 설계된 것 아닌가?
    • “오픈소스 비즈니스 모델” 관점에서 특히 흥미로운 점은, Deno가 프레임워크 핵심 기능에 자기 SaaS 플랫폼만이 전역 규모 업그레이드로 잘 제공할 수 있는 기능을 넣고 있다는 부분임
      꽤 새롭지만 조금 불안하기도 함. 당연히 상업화는 해야겠지만 완전히 닫힌 방식일 필요는 없었고, 확장 계층에는 BSL이나 PolyForm 같은 다른 라이선스를 쓸 수도 있었을 것 같음

  • Deno가 여기서 노리는 방향은 꽤 미래지향적이라고 봄
    올해 처음 Go를 쓰고 있는데, 언어의 일부는 C와 매우 비슷함. C와 다른 것들, 예를 들어 가비지 컬렉션 덕분에 함수에서 스택 할당 포인터처럼 보이는 값을 반환할 수 있는 점 외에도 map[string]string 같은 내장 기능이 자연스럽게 들어가 있음. 2023년 이후 새 언어를 만든다면 맵 타입을 다루는 내장 문법이 없다는 건 거의 말이 안 되는 수준이라고 느꼈음
    그래서 웹 서버 중심 생태계가 우리가 자주 쓰는 원시 기능들에 대한 라이브러리, 어쩌면 언젠가는 언어 문법까지 갖추는 건 논리적으로 보임. 분산 웹 서버에서 캐시용 키-값 저장소, 잠금 메커니즘, 임시 큐조차 없었던 마지막 프로젝트가 기억나지 않음. 키-값 저장소 없는 분산 시스템은 맵 타입 없는 프로그래밍 언어와 어렴풋이 닮았고, 정말 스위스 아미 나이프 같은 기술임
    잠재적 문제는 Deno가 이 길을 혼자 가고 있다는 점임. 현재 Deno가 추가하는 새 기능들이 경쟁 플랫폼에서도 제공될지 확신하기 어렵고, API를 오픈소스로 공개하더라도 Deno 네임스페이스에 있으니 AWS에서 FoundationDB 대신 Redis로 바꾸고 싶을 때 그냥 동작할지는 모르겠음
    그래서 Deno를 피하고 싶다는 느낌이 듦. 문법과 노출 기능은 정말 매력적이지만, 종속된 뒤 여러 클라우드 인프라에 배포 가능하게 만들려고 코드를 크게 수술해야 할까 걱정됨. 많은 고객이 이걸 요구함. 예를 들어 언젠가 Oracle이나 Salesforce에 팔고 싶은데 온프레미스 실행을 요구한다면, 그쪽에서 쓸 수 있는 키-값 저장소를 Deno 패키지 기능에 맞게 어떻게 적용할지 내가 떠안게 됨
    양날의 검임. Deno가 이 비전을 더 넓은 층에 밀어붙이는 데 성공할 수도 있지만, 당분간은 조심스럽게 볼 것 같음

    • 이 경우에는 원격 연결 프로토콜인 KV Connect도 문서화되어 있음: https://github.com/denoland/deno/tree/main/ext/kv#kv-connect
      이 프로토콜을 순수 TypeScript로 구현한 kv-connect-kit을 살짝 써봤는데, 어떤 JavaScript 런타임에서도 KV 클라이언트 API를 제공함. Deno 네임스페이스가 전혀 없는 Cloudflare Workers도 포함됨
      GitHub: https://github.com/skymethod/kv-connect-kit / npm: https://www.npmjs.com/package/kv-connect-kit / deno/x: https://deno.land/x/kv_connect_kit / 데모: https://keyspace.deno.dev/
      프로토콜은 설명대로 동작하는 것 같고, 다른 백엔드를 작성하는 것도 꽤 간단해 보임
    • 동의하지 않음. 언어 런타임을 특정 호스팅 서비스에 묶인 특정 KV 인터페이스와 결합하는 건 미래지향의 반대임
      기술 업계는 공급업체 종속 스택에서 벗어나기 위해 꽤 진전해 왔는데, 이건 오히려 그런 시절을 떠올리게 함
      Deno.KV가 런타임 일부로 포함되는 것과 파일 맨 위에 import KV를 추가하는 것의 실질적 차이가 뭔지 모르겠음. 후자는 Deno든 어디든 원하는 곳에서 가져올 수 있음
      그리고 Deno 팀이 자기 언어 말고 다른 언어용 바인딩을 제공할 가능성은 얼마나 될까? Google이 Go에 Google Cloud 전용 원시 기능을 네이티브로 넣기 시작해도 미래지향적이라고 부를 건가?
    • Deno를 좋아하지만 같은 이유로 도입에는 조심스럽게 됨. Deno가 이기려면 호스팅 경쟁자들도 완전히 지원해야 할 것 같음
      동시에 자체 호스팅도 업계 선두와 같거나 더 좋아야 함. 다른 길로는 자체 호스팅을 접고, 호스팅 파트너 어댑터 위에 얇은 마진을 붙인 멀티클라우드 솔루션을 제공할 수도 있음. 그러면 Deno가 호스팅 제공자로 직접 경쟁할 필요는 없어짐
    • Deno는 이걸로 다른 JS/TS SaaS와 경쟁하려는 것뿐임. Vercel/NextJS에도 KV 서비스가 있고, Cloudflare에도 있으며, 다른 경우에는 Firebase가 있음
      이건 미래지향이라기보다 Deno를 SaaS로 수익화하는 것에 가깝다고 봄. 요즘 JavaScript 세계에서 누구나 “클라우드” 제품으로 하는 일, 즉 프레임워크를 붙여 AWS를 재판매하는 흐름임. 그래서 가격표가 붙어 있는 것임
      Deno의 KV가 FoundationDB에 의존한다면 다른 데이터베이스용 어댑터를 적극적으로 만들 가능성도 낮아 보임. 데이터베이스 기술을 바꾸는 건 늘 큰일이고, 각각 용도와 성능 특성이 다르기 때문임
    • GC allowing one to return what look like stack allocated pointers from functions는 가비지 컬렉션 때문이라기보다 탈출 분석과 SSA 덕분이라고 봄

  • “퍼블릭 클라우드 인프라를 활용하려면 보일러플레이트 코드와 복잡한 설정을 뒤져야 해서 개발자의 시간과 에너지를 많이 잡아먹는다”는 논리는 잘 납득이 안 됨
    결국 우리는 안정적이어야 하는 인프라를 만드는 중임. 검증된 기술인 SQS 큐를 설정하는 데 30분 쓰는 게, Deno가 “SQLite / FoundationDB 위에” 만든 장난감 큐를 전적으로 믿는 것보다 나빠 보이지 않음. 30분 설정 비용과 좋아진 “개발자 경험”이 정말 그 위험을 감수할 만큼 가치가 있나? 애초에 큐를 얼마나 자주 설정하나?

    • 이건 내가 어떤 사람인지에 따라 달라진다고 봄
      취미 프로그래머로서는 AWS나 Google 같은 큰 제공자를 잘 쓰지 않는데, 꽤 복잡해 보이기 때문임. 익숙하면 그렇게 나쁘지 않을 수도 있음
      또 각 프로젝트를 GitHub의 독립 저장소로 두고 싶음. 이상적으로는 웹 앱을 다른 누구나 별도 도메인으로 자기 독립 웹 앱처럼 쉽게 띄울 수 있어야 함. 남의 데이터까지 책임지고 싶지 않기 때문임
      이건 어느 정도 Sandstorm 사용 사례와 비슷함. “로컬에서 시험해 보고, 실제로 쓰려면 Deno Deploy 계정을 만들라”는 설치 안내는 꽤 합리적으로 들림
    • 많은 사람은 AWS나 SQS 경험이 없고, 경험이 있는 사람도 여전히 신경 써야 함. Deno는 배터리 포함 접근을 택해서 개발자가 뭔가를 가져와 바로 쓸 수 있게 함
      클라우드용으로 동등한 라이브러리를 누군가 제공한다면 분명 채택할 사람들이 있을 것임. Deno의 경우 자기 생태계 개발자들이 겪는 공통 문제를 찾아내고, 괜찮은 해법을 묶어 해결하려는 것 같음
    • 과격하게 말하면, 이제는 큐를 직접 쓰지 않는 편이 낫다고 봄. 생 HTTP/2를 쓰거나 스레드를 직접 관리하는 것과 비슷함
      큐를 추상화해 주는 워크플로 엔진을 쓰면 작업, 스케줄, 상태, 재시도를 관리하지 않고 “그냥 코드 작성”이 가능함
      https://www.inngest.com/blog/how-durable-workflow-engines-wo...
      단, 나는 워크플로 엔진 작성자라 편향이 있음
    • 그 논리라면 새로 나오는 건 기본적으로 “장난감 프로젝트”이고 AWS만 검증됐으니 아무도 새 제품을 출시하면 안 된다는 뜻이 됨
    • 그게 장난감 큐인지 어떻게 아나?

  • “최소 한 번 전달 의미론”과 “사용자 코드”를 다뤄본 예전 경험상, 사용자는 최소 한 번 전달을 제대로 이해하지 못함
    메시지를 재전달하는 순간 사용자 불만과 장애가 쏟아짐
    불가능에 가까운 일을 해내서 정확히 한 번 전달 의미론을 발명하든지, 아니면 사용자가 한 번만 전달된다고 의존하지 못하게 모든 메시지의 0.1%를 항상 재전달해야 한다고 봄

    • 초기 SQS가 사실상 이랬음. 의도적이었는지는 모르겠지만, 덕분에 재전달을 존중해야 한다는 걸 금방 배웠음
    • 메시지가 멱등적이어야 한다면, 보내는 쪽에서 이를 보장하는 통합 테스트를 꼭 만드는 걸 추천함

  • 현재 Deno Deploy를 쓰고 있는데, 혼자 만드는 프로젝트 기준으로 성능이 훌륭하고 정말 단순함
    큰 팀에서 AWS 개발을 해본 입장에서, 설정을 생각하지 않고도 쉽게 띄울 수 있게 복잡성에서 벗어나는 흐름이 반가움. DNS도 아주 간단했고 자동 SSL 인증서도 정말 좋았음. 이 제품이 지향하는 바에 대해서는 불만이 전혀 없고, 로드맵도 기대됨

  • 내가 놓친 게 아니라면 Deno.openKv() 인스턴스마다 큐가 하나만 있는 것처럼 보임
    로컬 버전에서는 매번 다른 SQLite 파일 경로로 Deno.openKv("db-2.db")를 호출하면 여러 큐를 만들 수 있겠지만, 꽤 흔한 요구치에 비해 오버헤드가 커 보임
    아마 Deno의 아키텍처 스타일일 수도 있음. 복잡한 앱을 Deno로 만들 때는 여러 스크립트가 함께 동작하고, 각각 자기 KV 저장소와 큐를 갖는 마이크로서비스식 구조를 기대하는 걸까?

    • 맞음. 현재는 단일 큐만 있음
      핵심 개발자 중 한 명이 Discord에서 확인해 줬음: https://discord.com/channels/684898665143206084/115671428253...
      인용하면: “맞습니다. 현재는 단일 큐만 지원합니다. 다만 단일 큐에서 여러 타입의 메시지를 다중화할 수는 있습니다.”

  • 가격은 어떻게 됨?
    Deno는 일종의 Node.js 대체재라고 생각했는데, 내가 뭘 놓치고 있나? 이걸 로컬이나 셀프호스팅으로 비용 없이 쓸 수 있나?

    • 이건 Deno KV 나머지와 같은 방식임. 오픈소스 버전은 SQLite를 쓰지만, Deno의 클라우드 제품에 배포하면 대신 독점적인 FoundationDB를 쓰게 됨
      “Queues are built on Deno KV”라서 로컬에서는 SQLite를 쓰고, Deno Deploy에서는 최대 가용성과 처리량을 위해 FoundationDB를 쓴다는 설명임
      이 패턴에 대해서는 여기 조금 더 적어둠: https://til.simonwillison.net/deno/deno-kv
    • 글에 따르면 개발 중 로컬에서는 SQLite를 쓰고, Deno에 배포하면 클라우드 제공 기능의 일부가 됨

  • 혹시 개발자들이 본다면, 현재 훌륭한 KV 사용성에서 접근 제어 쪽은 나중에 고통이 생길 것 같음
    해법이 그냥 “사용자 공간에서 직접 구현하고 버그를 만들지 말라”인지, 아니면 계획된 게 있는지 궁금함

    • 사용자 수준 접근 제어, 예를 들어 인증된 사용자용 ACL 같은 걸 말하는 건지, 아니면 다른 건지 궁금함. 더 긴 생각을 공유해 주면 이 우려를 계속 염두에 두도록 하겠음

  • 최근 Jupyter 지원과 이번 큐 기능은 기대됨. 정말 멋진 것들임
    하지만 Deno로 서버를 작성해서 내 서버에서 프로덕션에 올리지는 않을 것 같음. 서버리스는 좋아하지 않음
    Deno와 Bun의 비즈니스 모델은 서버리스, 즉 Deno Deploy를 중심으로 만들어져 있음. 그리고 Deno Deploy는 또 다른 런타임
    KV와 큐에서 그 점이 분명함. 로컬이나 셀프호스팅에서는 다른 기술 위에 얹힌 간신히 동작하는 버전을 갖게 됨
    즉, Deno 고객 대부분이 쓰는 것과 다른 버전의 Deno를 셀프호스팅하게 된다는 뜻임
    자기 하드웨어에서 서버를 돌리려고 Deno를 쓰는 사람이 얼마나 될까? 그 수가 적다면 차라리 Node를 쓰겠음

  • Deno는 정말 흥미로움. 실현 가능한 비즈니스 모델, 좋은 사용성, 쓸데없는 설정 잡무가 없다는 점이 훌륭함

    • Deno에 기대를 가져보려 했지만 잘 모르겠음. 이미 과거에 수없이 했던 것과 뭐가 다른지 보이지 않음
      Deno 자체는 본질적으로 Node.js에 자동 TypeScript 컴파일을 더한 것임. 원래라면 설정 파일 하나가 더 필요했을 뿐임. 프로젝트가 나왔을 때는 지저분한 NPM 생태계에서 벗어난다는 점을 크게 내세웠지만, 결국 돌아서서 NPM 지원을 추가해야 했고 그 차별점도 사라졌음
      Deno Deploy는 이미 수십 개 있는 Lambda류 서비스와 같음. KV 저장소와 이제 큐는 Redis, LevelDB, RocksDB, Dynamo, SQS 또는 수많은 유사 옵션과 동등함. 아직 Deno를 나머지와 실제로 구분해 주는 기능을 하나도 못 봤음
      언어 런타임, 컴퓨트 호스팅, 데이터 저장소를 한 회사가 모두 맡는 걸 선호한다면 매력이 있을 수도 있음. 하지만 개인적으로는 피하고 싶고, 특히 그 회사에 그 분야의 실적이 없다면 더 그렇음
    • Deno에 실현 가능한 비즈니스 모델이 있다고 믿는 이유가 뭔가?
답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.