GN⁺: Hatchet – 오픈 소스 분산 작업 큐

분산, 내결함성 작업 큐

• Hatchet은 기존의 관리하기 어려운 큐나 pub/sub 시스템을 대체하여, 실패로부터 복구하고 동시성, 공정성, 속도 제한과 같은 문제를 해결할 수 있는 내구성 있는 작업 부하를 설계할 수 있음.
• 자체적인 작업 큐나 pub/sub 시스템을 관리하는 대신, Hatchet을 사용하여 최소한의 설정이나 인프라로 함수를 일련의 작업자들 사이에서 분배할 수 있음.

Hatchet의 장점

• 초저지연 및 고처리량 스케줄링
  • Hatchet은 25ms 평균 시작 시간의 저지연 큐를 기반으로 구축되어, 실시간 상호작용 능력과 임무 중요 작업에 필요한 신뢰성을 완벽하게 균형잡힌 상태로 제공함.
• 동시성, 공정성, 속도 제한
  • FIFO, LIFO, Round Robin, Priority Queues와 같은 전략을 Hatchet의 내장 전략으로 구현하여 최소한의 설정으로 일반적인 확장 문제를 우회함.
• 설계상의 복원력
  • 맞춤형 재시도 정책과 통합된 오류 처리를 통해 Hatchet은 일시적인 실패로부터 신속하게 작업을 복구할 수 있도록 보장함.

향상된 가시성 및 제어

• 관찰 가능성
  • 모든 실행은 완전히 검색 가능하며, 문제를 신속하게 식별할 수 있음.
• (실용적인) 내구성 있는 실행
  • 이벤트를 재생하고 워크플로우의 특정 단계에서 수동으로 실행을 다시 시작할 수 있음.
• Cron
  • 함수 실행을 반복적으로 스케줄링할 수 있음.
• 일회성 스케줄링
  • 특정 시간과 날짜에 함수 실행을 스케줄링할 수 있음.
• 스파이크 보호
  • 트래픽의 급증을 완화하고 시스템이 처리할 수 있는 것만 실행함.
• 점진적 스트리밍
  • 백그라운드 작업자의 진행 상황에 따라 업데이트를 구독할 수 있음.

예시 사용 사례

• Generative AI를 위한 공정성
  • 바쁜 사용자가 시스템을 압도하지 않도록 Hatchet을 사용하여 작업자에게 요청을 공정하게 분배할 수 있음.
• 문서 색인을 위한 배치 처리
  • Hatchet은 문서, 이미지 및 기타 데이터의 대규모 배치 처리를 처리하고 실패 시 작업 중간부터 이어서 수행할 수 있음.
• 다중 모달 시스템을 위한 워크플로우 오케스트레이션
  • Hatchet은 다중 모달 입력 및 출력을 조정할 수 있으며, 전체 DAG 스타일 실행을 처리할 수 있음.
• 이벤트 기반 처리를 위한 정확성
  • 외부 이벤트나 시스템 내부 이벤트에 반응하고 자동으로 이벤트를 재생할 수 있음.

빠른 시작

• Hatchet은 Python, Typescript, Go용 오픈소스 SDK를 지원함.
• 시작하려면 Hatchet 문서를 참조하거나, 빠른 시작 저장소를 확인할 수 있음.

SDK 저장소

• Hatchet은 기본적으로 Go SDK를 제공함.
• Typescript SDK도 사용할 수 있음.
• SDK와 관련된 문제가 발생하면 해당 저장소에서 이슈를 제출할 수 있음.

관리되는 클라우드 버전의 Hatchet이 있는가?

• 예, 베타 기간 동안 제품을 구축하고 형성하는 데 도움을 주는 일부 회사에 클라우드 버전을 제공하고 있음.

자체 호스팅 버전의 Hatchet이 있는가?

• 예, 자체 호스팅을 위한 오픈소스 도커 컨테이너의 지침은 문서에서 찾을 수 있음.

이것이 대안들과 어떻게 비교되는가? (Celery, BullMQ)

• 왜 또 다른 관리 큐를 만들었는가?
  • 특히 DAG 스타일 실행에 의존하는 전체 트랜잭션 큐잉의 이점을 갖추고자 하였으며, Postgres가 대부분의 큐잉 사례를 대체할 수 있다고 강하게 믿음.
  • 많은 큐들이 Redis를 기반으로 하고 있으며, 주의하지 않으면 OOM으로 인한 데이터 손실이 발생할 수 있지만, PG를 사용하면 이러한 문제를 피할 수 있음.

문제점

• Github 이슈를 통해 발견한 버그를 제출할 수 있음.
• 프로젝트가 초기 단계이기 때문에, 복잡한 기능 요청 전에 Discord에서 먼저 연락을 취하는 것이 좋음.

기여하고 싶다면

• 기여 문서를 참조하고, Discord의 #contributing 채널에서 작업하고 싶은 내용을 알려주면 프로젝트 방향을 형성하고 협업을 쉽게 할 수 있음.

GN⁺의 의견

• Hatchet은 분산 시스템에서 작업 큐 관리의 복잡성을 줄이고, 고가용성과 내결함성을 제공하는 솔루션으로, 특히 대규모 데이터 처리 및 실시간 서비스에 유용할 것으로 보임.
• 이 기술이 현재 시장에서 사용되는 다른 큐 시스템과 비교하여 Postgres를 사용함으로써 얻는 안정성과 확장성은 주목할 만한 장점임.
• Hatchet을 도입할 때 고려해야 할 사항으로는 기존 인프라와의 호환성, 데이터 마이그레이션, 그리고 팀의 기술적 역량이 있음.
• Hatchet이 제공하는 고급 가시성 및 제어 기능은 시스템의 성능 모니터링과 문제 해결을 용이하게 하여 개발자와 운영팀의 작업 부담을 줄일 수 있음.
• Hatchet이 아직 베타 단계에 있으므로, 안정성과 기능성 측면에서 충분한 검증이 필요하며, 대규모 시스템에 적용하기 전에 충분한 테스트가 필요함.

[neo]

Hacker News 의견

• 한 사용자는 Postgres를 기반으로 한 작업 큐와 다양한 언어로 작업하는 워커(worker), 그리고 적절한 내장 관찰 기능을 갖춘 제품을 3년 동안 찾고 있었다고 말함. 이 사용자는 6개월마다 시장을 확인하고 대안을 평가했지만 항상 실망했다고 함. 그러나 RabbitMQ 같은 추가 의존성은 피하고 싶어서 Postgres 기반 큐를 선호한다고 언급함. 현재는 graphile-worker를 사용하고 있지만, 여전히 충족되지 않는 요구사항이 있다고 함.
• 다른 사용자는 이 제품이 Y Combinator에 지원받고 있음을 지적하며, 이 회사가 "오픈 코어" 모델을 따를지 아니면 다른 수익 창출 방법을 모색할지 궁금해함.
• 또 다른 사용자는 pub/sub 시스템의 푸시 구독 기능을 좋아한다고 언급하며, 예를 들어 GCP pub/sub에서는 이벤트를 큐에서 끌어오는 대신 HTTP 엔드포인트로 푸시하는 구독자를 가질 수 있다고 설명함. 이 방식은 클라우드 런이나 람다와 같은 런타임을 사용하여 HTTP 요청에 기반해 스케일링하고 제로까지 스케일링할 수 있다는 장점이 있다고 함. 워커의 자동 스케일링 설정이 더 복잡할 수 있으며, RabbitMQ에서 큐 깊이 메트릭을 기반으로 KEDA 자동 스케일링을 설정할 수도 있지만, 이는 복잡성을 추가한다고 함. 사용자는 HTTP 연결을 유지하는 데몬이 작업을 푸시할 수 있는 모델을 지원할 계획이 있는지 물음.
• 한 사용자는 모든 함수가 컨텍스트를 인수로 받는 이유를 설명해달라고 요청함. 이는 함수를 작성할 때 많은 보일러플레이트 코드를 작성해야 한다고 느낀다고 함.
• 다른 사용자는 분산 DAG 처리 시스템을 구현할 때 이 아이디어가 있었다면 좋았을 것이라고 말하며, 시도해보고 싶어함.
• 한 사용자는 클라우드 제공 서비스의 가격을 공개하는지, 자체 호스팅 옵션에 대해 쿠버네티스 오퍼레이터를 만들 계획이 있는지 물음. 또한 MIT 라이선스를 사용함으로써 아마존이 향후 아마존 해쳇 서비스를 만들 수 있다는 우려를 표함.
• 또 다른 사용자는 DAG 기반 작업 러너를 위한 작업 큐를 작성하고 있으며, PostgreSQL, SQLite, 메모리 내부 등을 사용하여 작업 그래프가 재시도, 시간 초과, 직렬화된 리소스 등을 고려하지 않고 실행되도록 하고 싶어함. 이 사용자는 해당 접근 방식에 관심이 있음.
• 한 사용자는 클라이언트(웹 브라우저)가 작업의 진행 상황을 완료까지 들을 수 있는 작업 큐가 필요하다고 말함. Deno 큐의 단순함과 접근성을 좋아하지만, 클라이언트에서 작업 상태를 구독하는 방법을 직접 구현해야 한다고 함. Postgres 기반으로 가능할지 궁금해하며, 문서 링크를 통해 가능함을 확인함.
• 다른 사용자는 과거 직장에서 무제한의 작업을 스케줄링해야 하는 문제를 겪었다고 언급함. 예를 들어, 환자가 6개월 후에 예약을 잡으면, 그 기간 동안 약속을 상기시키는 일련의 알림을 스케줄링해야 함. 이 사용자는 데이터베이스 큐에 레코드를 입력하고 몇 초마다 폴링하는 방식으로 시작했지만, 폴링으로 인한 IO 비용이 이상적이지 않아 분산 시스템을 사용하지 않고 이를 해결하고자 했음. Redis로 전환했지만, 여러 디스패처를 다루는 복잡성, OOM 문제, 즉시 큐로 작업을 이동시키기 위한 보조 작업을 실행해야 하는 등의 문제가 있었음. PG로 전환하고 SKIP LOCKED 등을 사용하는 방법을 고려했지만, 직장을 옮겼음. Hatchet이 이러한 유스케이스에 적합한지 궁금해함.
• 마지막으로 한 사용자는 Hatchet이 Temporal/Cadence/Conductor와 어떻게 비교되는지, Hatchet도 내구성 있는 실행을 지원하는지 물음.