장시간 비동기 작업을 Kafka 대신 RDB Task Queue로 전환

이 게시물은 전자계약서 시스템의 대용량 엑셀 생성 작업에서 Kafka 기반 비동기 처리로 인해 중복 발송이 발생한 문제를 RDB 기반 Task Queue + Heartbeat 구조로 해결한 과정을 설명합니다.

Kafka 기반 구조의 문제와 핫픽스

• 엑셀 생성이 30분 이상 걸리면서 Kafka의

  max.poll.interval.ms(5분)

  를 초과해 리밸런싱이 발생했고, 동일 메시지가 재할당되어 중복 발송이 발생했습니다.
• 임시로 코루틴으로 작업을 비동기 실행하고 즉시 ACK하는 방식으로 중복은 막았지만, 실패 시 작업 유실 및 배포/장애 시 진행 중 작업 소실 문제가 남았습니다.

RDB 기반 Task Queue + Heartbeat 아키텍처

• 작업을 RDB 테이블로 영구 저장하고(PENDING/IN_PROGRESS/DONE/FAILED), Worker가 1분마다 Heartbeat를 갱신해 장시간 작업도 안전하게 추적합니다.
• 3초 폴링으로 PENDING 작업을 조회한 뒤 Redis 분산 락으로 선점해 중복 처리를 방지하고, 각 Worker는 동시에 최대 2개 작업을 병렬 처리합니다.
• 실패 시 retry_count를 증가시키며 최대 3회까지 PENDING으로 되돌려 재시도하고, 2분 이상 Heartbeat가 없는 IN_PROGRESS 작업은 Fallback 스케줄러가 감지해 PENDING으로 복구합니다(ShedLock으로 단일 실행 보장).

효과와 트레이드오프

• Kafka 플로우 제거로 복잡도가 줄고, DB 단일 소스로 상태를 관리해 디버깅/모니터링이 쉬워졌으며, 배포가 장시간 작업에 영향을 주지 않도록 설계되었습니다.
• 폴링 쿼리로 인한 DB 부하 가능성과 폴링 주기(3초)만큼의 시작 지연이 있으나, 커버링 인덱스 및 요구사항 관점에서 수용 가능하다고 정리합니다.