백그라운드 작업을 큐에 넣었으니 한 번만 실행될 것이라고 믿으면 결제, 이메일, 재고 차감에서 중복이 생길 수 있습니다. 메시지는 중복 전달될 수 있고, 작업 완료 뒤 확인 응답이 사라질 수도 있습니다. '정확히 한 번'보다 중복이 와도 결과가 같도록 설계하는 편이 현실적입니다.
전달과 처리를 구분한다
큐가 메시지를 한 번 이상 전달하는 것과 비즈니스 작업이 한 번만 반영되는 것은 다른 약속입니다. 작업자가 DB를 수정한 직후 죽으면 큐는 성공 확인을 받지 못해 같은 메시지를 다시 보낼 수 있습니다. 이 경계를 테스트해야 합니다.
비즈니스 식별자를 멱등 키로 쓴다
메시지 수신 시 새 랜덤 키를 만들면 중복을 구분할 수 없습니다. 주문 ID와 작업 유형처럼 같은 비즈니스 사건에 안정적인 키를 사용합니다. 키의 유효 기간과 재처리 허용 범위를 업무 정책으로 정합니다.
중복 기록과 상태 변경을 함께 묶는다
작업 완료 표시만 먼저 저장하고 실제 재고 차감이 실패하면 처리됐다고 오판합니다. 가능하면 같은 트랜잭션에서 처리 기록과 상태 변경을 반영합니다. 외부 API처럼 한 트랜잭션으로 묶을 수 없는 경우는 외부 멱등 키와 상태 조회를 사용합니다.
실패와 재시도를 운영자가 볼 수 있게 한다
일시 오류는 재시도하되 영구 오류는 무한 반복하지 않습니다. 실패 횟수, 마지막 원인, 다음 재시도 시각을 남기고 정해진 한도 뒤에는 검토 대기열로 보냅니다. 수동 재처리도 같은 멱등 정책을 따라야 합니다.
중복이 실제로 오도록 시험한다
같은 메시지를 연속 두 번 보내고, 처리 직후 작업자를 종료하고, 큐 확인 전에 네트워크를 끊습니다. 결과가 하나만 반영되는지 확인합니다. 정상 경로에서 한 번 실행된 로그만으로 중복 안전성을 증명할 수 없습니다.
현장에 적용할 때의 순서
- 업무 사건에서 멱등 키를 정의한다
- 중복 기록과 상태 변경의 경계를 설계한다
- 중복 전달·확인 응답 손실을 시험한다
주의할 실패: 큐 전달 성공을 비즈니스 반영 성공과 동일시하면 중복 또는 누락이 생긴다.
관찰할 지표: 중복 차단 건수, 재시도 횟수, 수동 재처리 후 불일치를 본다.
적용 전 체크리스트
- 같은 비즈니스 사건에 안정된 멱등 키가 있는가
- 처리 기록과 상태 변경의 원자성을 검토했는가
- 중복 전달과 처리 직후 장애를 시험했는가
참고 자료
Amazon SQS queue types. AWS는 표준 큐의 최소 한 번 전달과 중복 가능성을 명시하고 멱등 처리를 권장합니다. 구체적 트랜잭션 경계는 사용 중인 저장소와 외부 API에 따라 달라집니다.
이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.
#백그라운드작업 #멱등성 #메시지큐 #SQS #재시도 #중복처리 #분산시스템 #워크플로 #이벤트처리 #시스템아키텍처
