하루 하나의 질문에 답하며 자신을 기록하는 모바일 서비스 One Question의 백엔드 API 서버입니다.
Deep Dive
DB Transaction과 Message Queue 사이의 불일치, Claim 방식, 중복 전달과 장애 복구를 고민한 과정은 기술 블로그에 더 자세히 정리했다.
메시지 큐 작업을 안전하게 처리하기 위한 설계 과정 →
AI 분석 API는 한 작업에 수십 초가 소요될 수 있다.
이를 HTTP 요청 안에서 직접 처리하면 요청 타임아웃, 서버 리소스 점유, 외부 AI 장애 전파 같은 문제가 생길 수 있기 때문에 요청 접수와 실제 분석 작업을 분리했다.
| Status | Problem | Approach |
|---|---|---|
| 메시지 생성 | 동일한 분석 요청이 중복 전달되는 경우 | 멱등키로 중복 실행 방지 |
| 동일한 멱등키에 다른 요청이 들어오는 경우 | 요청 해시(Request Hash) 비교 후 다르면 에러 응답 | |
| 메시지 생성에 실패하는 경우 | 트랜잭션 롤백 후 에러 응답, 사용자가 재요청 | |
| PENDING | 여러 서버가 같은 작업을 동시에 가져가는 경우 | ShedLock + CAS 선점으로 한 대만 발행 |
| 메시지 선점에 실패하는 경우 | PENDING 유지, 다음 스케줄러가 다시 조회 | |
| PUBLISHING | SQS에 메시지 전송이 실패하는 경우 | PENDING으로 되돌려 재시도 |
| 메시지 전송 이후 QUEUED로 상태 변경을 실패한 경우 | Claim 만료 후 PENDING으로 복구, 중복 메시지는 Worker CAS로 멱등성 보장 | |
| Claim이 만료된 Server가 다시 동작하는 경우 | Claim ID 검증으로 차단 | |
| QUEUED | QUEUED 상태 변경 전에 메시지가 먼저 도착하는 경우 | 대기 후 재조회, QUEUED 확인되면 선점 |
| Worker가 중단되는 경우 | Visibility Timeout 후 메시지 재전달 | |
| 동일한 메시지가 중복 전달되는 경우 | CAS 선점 성공한 Worker만 메시지 처리 | |
| PROCESSING | 재시도 가능한 오류가 나는 경우 | QUEUED로 되돌리고 Visibility를 짧게 조정 |
| Worker 작업 Timeout이 발생한 경우 | 삭제 없이 종료, Visibility 만료 후 재시도 | |
| 최대 재시도 횟수를 초과한 경우 | 메시지를 DLQ로 격리 | |
| SUCCEEDED | 작업 완료 후, 메시지 삭제에 실패한 경우 | Visibility 만료 후 재시도시, SUCCEEDED 상태 확인 후 메시지만 삭제 |