Context
데이터 수집과 외부 연동 작업이 서버 중심으로 실행되면서 확장성과 운영 제어가 모두 제한되고 있었다. 실행 위치가 서버에 묶여 있었고, 같은 요청이 반복 유입될 때 중복 작업을 제어할 기준도 필요했다.
Decision
외부 연동 작업은 Redis로 요청과 상태를 제어한 뒤 SQS에 적재하고, 실제 실행은 Lambda가 담당하는 구조로 전환한다.
Alternatives
기존 DB queue 구조를 유지하고 상태 동기화 로직만 보강한다
Pros
- 현재 구조를 크게 바꾸지 않아도 된다
- 추가 인프라 도입 범위가 작다
Cons
- 실행 경로가 여전히 분산된 상태로 남는다
- API 서버와 작업 실행의 결합이 충분히 해소되지 않는다
Kafka와 별도 worker 서버를 도입해 작업 플랫폼을 구성한다
Pros
- 확장성과 유연성이 높다
- 이벤트 스트리밍 기반으로 다양한 후속 처리 확장이 가능하다
Cons
- 현재 요구사항 대비 운영 복잡도와 비용이 크다
- 도입과 학습 비용이 높아 전환 속도가 느려질 수 있다
API 서버 내부 비동기 처리로만 대응한다
Pros
- 도입 속도가 빠르다
- 구조 변경 범위가 작다
Cons
- 서버 리소스 경합 문제가 그대로 남는다
- 실행 책임 분리가 되지 않아 장애 전파 범위가 크다
Reasoning
핵심은 작업 실행을 서버에서 분리하고, 메시지 단위로 통일하는 것이었다. SQS와 Lambda는 실행 경로를 단순하게 만들었고, Redis는 중복 요청과 상태를 앞단에서 제어하는 역할을 맡았다.
핵심은 비동기 기술 도입보다 실행 책임을 다시 정리하는 데 있었다.
- API 서버는 요청을 접수하고 메시지를 발행한다.
- 중복 제어와 상태 관리는 enqueue 전에 Redis 레이어에서 끝낸다.
- 실제 실행은 큐를 구독하는 실행 주체가 담당한다.
- 실패한 데이터 수집 작업은 자동 복구하지 않되, 재처리 대상은 정책적으로 제한한다.