분석 잡 큐는 브로커 없이 DB row로 쓴다
맥락
회의가 끝나면 server가 분석 잡을 만들고 heymoa-ai에 디스패치한다. 실패한 잡을 다시 돌릴 장치가 필요한데, SQS·Kafka 같은 브로커를 하나 더 띄울지가 갈림길이었다. 브로커를 들이면 운영할 인프라가 하나 늘어난다. EC2 두 대 + RDS 하나로 버티는 형상도 그 자리에서 깨진다.
결정
- 브로커를 도입하지 않는다.
analysis_jobs테이블의 row 자체가 큐다. - 스케줄러(워치독)가 정체된 row를 주워 재디스패치한다.
- 이 결정은 AI가
analysisId에 대해 멱등이라는 성질에 기댄다. 재디스패치가 안전한 이유가 그것이다. 그 성질이 깨지면 이 결정도 같이 깨진다.
대안
대안 1 — SQS·Kafka 등 메시지 브로커 도입. 가시성 타임아웃·재시도·DLQ를 관리형으로 얻는다. 기각한 이유: AI가 이미 멱등이라 재디스패치는 그 자체로 안전하다. 브로커가 주는 것이 이미 DB에 있다. 인프라 한 개를 통째로 더 운영할 이유가 없었다.
결과
- 운영할 컴포넌트는 그대로다.
- 큐의 성질은 전부 우리가 직접 적어야 한다. 가시성 타임아웃도 재시도 상한도 관리형으로 오지 않는다. 워치독 설계(재시도 1회 상한)가 이 결정에 딸려 온 이유다.
- 잡을 줍는 주기는 스케줄러 주기가 정한다. 재디스패치가 브로커처럼 즉시 일어나지는 않는다.
- 큐 부하가 그대로 운영 DB 부하가 된다.