▲

Hatchet – Postgres에 기반한 작업 오케스트레이션 플랫폼

 (github.com/hatchet-dev)
11P by GN⁺ 13일전 | ★ favorite | 댓글 2개
  • Postgres 기반의 대규모 백그라운드 작업 처리 플랫폼 오픈소스
  • 분산 작업 큐(Distributed Task Queue) 및 워크플로 오케스트레이션 플랫폼
  • 복잡한 작업 워크플로, 실패 복구, 스케줄링, 이벤트 기반 트리거, 실시간 모니터링까지 지원
  • Python, Go, TypeScript SDK 제공
  • MIT 라이선스, 셀프 호스팅 및 클라우드 버전 제공

주요 기능 요약

  • 큐 관리

    • Postgres 기반 내구성 있는 큐 시스템
      • 키 기반 큐잉 (공정한 작업 분배 구현)
      • 속도 제한(Rate limiting)
      • Sticky Assignment 및 Worker Affinity
    • 작업 분배, 재시도, 실패 알림 자동 처리
    • Python / TypeScript / Go 예제 제공

  • 작업 오케스트레이션

    • DAG 기반 워크플로 구성
      • 조건 기반 실행 (예: sleep, 이벤트 기반 트리거, 부모 작업의 출력값 기반 조건 실행 등)
      • 복잡한 분기 로직 처리 가능
    • 작업 간 의존성 정의, 다중 작업 병렬 실행
    • Durable task로 중간 결과 저장 및 복구 지원
      • 내구성 있는 함수 실행: 실패 시 중간 상태를 캐시하고 재실행으로 복원
      • Durable Sleep과 Durable Events도 지원

  • 흐름 제어 (Flow Control)

    • 사용자 단위 동시성 제한
    • 글로벌 및 동적 속도 제한 (Rate Limiting)
    • 전략적 작업 분산을 통한 시스템 안정성 확보

  • 작업 스케줄링

    • Cron 작업, 예약 실행, durable sleep 지원
    • 예: 매일 자정 실행, 특정 시간 예약, 지정 시간 대기 등

  • 작업 라우팅

    • Sticky Assignment: 동일 워커에 작업 고정
    • Worker Affinity: 최적의 워커 선택 로직 적용

  • 이벤트 기반 트리거

    • 외부 이벤트 수신 후 작업 실행 가능
    • 이벤트/슬립 조건 병합 가능

  • 실시간 웹 UI

    • 실시간 대시보드 및 모니터링
    • 작업 로그 보기, 알림 설정 (Slack/이메일)

Hatchet를 언제 사용하면 좋을까?

  • ✅ DAG 기반 워크플로 구성이 필요할 때
  • ✅ 작업 실패 시 재시도 및 상태 보존이 중요할 때
  • ✅ 사용자가 많은 애플리케이션의 작업 분산 처리
  • ❌ 빠르게 셋업 가능한 간단한 큐만 필요할 때 (Celery/BullMQ 등 추천)
  • ❌ 다양한 데이터 커넥터와 통합이 중요할 때 (Airflow/Prefect 등 추천)

비교: Hatchet vs 다른 솔루션들

  • Hatchet vs Temporal

    • Hatchet은 큐 + DAG + Durable Execution 모두 지원
    • Temporal은 Durable Execution에 최적화
    • Hatchet은 셀프 호스팅이 간편 (Postgres만 필요)

  • Hatchet vs BullMQ / Celery

    • Hatchet은 작업 이력 저장 + UI 시각화 + 오케스트레이션 내장
    • BullMQ/Celery는 경량 큐 라이브러리지만 모니터링 기능 부족

  • Hatchet vs Airflow / Prefect

    • Hatchet은 고속 실행, 낮은 레이턴시, 자체 워커 관리
    • Airflow/Prefect는 데이터 파이프라인 중심으로, 통합 커넥터에 강점

요약

  • Hatchet은 Postgres만으로 동작하는 현대적인 분산 작업 처리 플랫폼
  • Durable, Observable, Composable한 작업 시스템을 단일 도구로 구현 가능
  • 클라우드/셀프 호스팅 모두 지원되며, Python/Go/TypeScript로 쉽게 통합 가능
▲
halfenif 11일전  [-]

2시간 동안 테스트 해 보고 작성함.

  • MQ를 구축하고 있기 때문에 postgres기반의 무언가 새로운건가 싶어 테스트 해봤으나, 토끼가 필요한 것을 보고 약간 실망했음
  • k8s관점이 아니기 때문에 docker-compose.yaml을 podman(+Arch)에 올렸음
  • postgres를 별도로 사용하고 싶었기 때문에 좀더 설정을 해야 했으나 최종 "SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER: Invalid certificate verification context"을 만나면서 중단했음
  • 중간에 무언가 잘못되면 postgres database를 drop하고 새로 시작해야 했음
  • API Key를 매번 만들어야 하는데, Web 화면상에서 Key가 전체 보이지 않기 때문에 개발자도구를 사용해서 추출해야 했음.
답변달기
▲
GN⁺ 13일전  [-]
Hacker News 의견

  • 다른 pg 기반의 Python 작업 실행기인 Procrastinate나 Chancy와 비교했을 때 어떤 점이 다른지 궁금함

  • 매우 흥미로운 내용임

    • FOR UPDATE SKIP LOCKED가 25k 쿼리/초로 확장되지 않는다고 했을 때, 어느 시점에서 한계에 도달했는지 궁금함
    • 버퍼링된 읽기와 쓰기, 모든 대량 테이블을 ID 열로 전환하는 것에 대해 궁금함
    • 이러한 점들이 FOR UPDATE SKIP LOCKED를 필요에 맞게 확장하는 해결책의 일부였는지 궁금함

  • 큐 작업(작업을 큐에 넣고 완료로 표시하는 것)이 내 비즈니스 로직과 동일한 트랜잭션에서 발생하는지 궁금함

    • 데이터베이스 기반 큐의 핵심 기능이라고 생각함
    • 재시도에 대한 논리를 단순화함
    • 작업 수행 시에도 동일한 문제가 발생할 수 있음
    • 이 시점에서는 SQS를 사용하는 것이 나을 수도 있음

  • 이벤트/워크플로우 기반 애플리케이션을 설계 중인데, 이 솔루션이 매우 유망해 보임

    • Temporal도 고려했지만 완벽한 적합성은 느끼지 못했음
    • 오픈 소스 라이선스가 애플리케이션 설계에 대한 자신감을 줌
    • CEL과 같은 조건문을 찾고 있었음

  • Hatchet 아키텍처의 여섯 가지 개선 사항 덕분에 모든 차원에서 성능이 향상됨

    • 시간 시리즈 테이블의 범위 기반 파티셔닝
    • 작업 이벤트의 해시 기반 파티셔닝
    • 모니터링 테이블과 큐의 분리
    • 버퍼링된 읽기와 쓰기
    • 모든 대량 테이블을 ID 열로 전환
    • Postgres 트리거의 적극적인 사용
    • 매뉴얼을 읽으면 놀라운 일을 할 수 있음

  • README는 다크 모드를 사용하는 사용자가 더 많다고 가정함

    • 로고가 흰색이라 다크 모드가 없으면 보이지 않음
    • GitHub의 통계를 보면 흥미로울 것임

  • Postgres를 메시지 큐로 사용할 때 큰 페이로드(50MB 이상)를 처리하는 문제에 직면함

    • 해결책은 비로그 테이블과 정기적인 전체 진공 사용이었음
    • Postgres 전문가가 아니지만, 이 문제를 해결했는지 궁금함

  • 문서를 15분 동안 검토한 후 피드백을 제공함

    • 라이트 모드, 오픈 소스, 로깅, DX 인터페이스가 좋음
    • Hello World 예제를 실제 시나리오로 대체하는 것이 좋을 것임
    • 다단계 작업을 포함하는 워크플로우의 코드가 직관적이지 않음
    • Hatchet의 사고방식, 패턴, 용어에 익숙해져야 함
    • 고객에게 쉽게 만들기 위한 노력이 부족해 보임
    • 엔지니어링 게시물은 의미가 있지만, 고객은 클라우드 인프라에 관심이 없음
    • 워크플로우 시장에서 많은 옵션이 있기 때문에 마지막으로 재작성하거나 피벗할 가능성이 높음
    • 자동화 여정을 집중하고, 사람들이 쉽게 가져와서 구성할 수 있도록 해야 함
    • 워크플로우를 JSON으로 직렬화하기 어려움
    • Hatchet 워크플로우를 다른 회사로 쉽게 이동할 수 있도록 해야 함

  • v1 출시를 축하함

    • Hatchet을 거의 1년 동안 사용해 왔고, 6개월 전에 프로덕션에 배포함
    • 오픈 소스 지원과 빠른 시작이 훌륭함
    • 시스템에 투입된 엔지니어링 작업이 눈에 띔

  • 첫인상은 좋음, 출시를 축하함

    • 몇 가지 질문이 있음
    • 영구적인 작업을 지원하는지 궁금함
    • 작업 입력과 출력이 어디에 저장되는지 궁금함
    • PostgreSQL 인스턴스의 크기와 I/O 메트릭을 기반으로 시스템이 초당 처리할 수 있는 작업 수를 추정할 수 있는지 궁금함
    • 다양한 도구를 평가 중이며, Hatchet이 어떤 느낌인지 알고 싶음
    • 최소한의 보일러플레이트로 작업할 수 있는 도구를 찾고 있음
답변달기