피드로 돌아가기
Dev.toBackend
원문 읽기
Hangfire 기반 Job 구조의 한계를 극복한 Durable Execution 기반 Workflow 설계
Am I the only .NET dev who keeps building workflow engines on top of Hangfire?
AI 요약
Context
단순 Background Job 처리를 위해 Hangfire를 사용했으나, 복잡한 비즈니스 프로세스 구현 시 상태 관리와 일관성 유지에 한계 직면. 분산된 Job 간의 인과관계 파악이 어렵고, 외부 API 장애 시 부분적 성공 상태로 인한 데이터 불일치 발생.
Technical Solution
- 단순 Job Enqueue 방식에서 탈피하여 상태 기반의 Durable Workflow-as-Code 아키텍처 지향
- Step-level Persistence를 통한 실행 지점 저장으로 장애 발생 시 마지막 성공 지점부터 Resume 구현
- Polling 기반 상태 확인 대신 External Signal 및 Event-driven 대기 메커니즘 도입
- Durable Timer 구현을 통해 24시간 대기 후 조건부 실행과 같은 장기 프로세스의 선언적 제어
- 개별 Job 단위의 모니터링을 넘어 전체 Workflow Run의 생명주기를 가시화하는 Observability 계층 설계
- SQL Server 및 Postgres 등 기존 인프라를 그대로 활용하는 Low-overhead 런타임 구조 추구
실천 포인트
1. 비즈니스 로직 내에 외부 API 호출이 3개 이상 포함된 경우, 단순 Job 분리가 아닌 상태 머신 기반의 Workflow 도입 검토
2. 재시도 전략 수립 시 단순 Retry가 아닌 Idempotency 보장 여부와 체크포인트 기반의 Resume 가능성 분석
3. 장기 대기 작업(Long-running task) 구현 시 Job ID 저장 및 취소 로직의 복잡도를 측정하여 Durable Timer 도입 고려
4. 분산 환경에서 비즈니스 프로세스의 가시성을 위해 개별 로그가 아닌 Workflow Run ID 기반의 추적 체계 구축