사장님의 입점신청 요청들은 자동승인 처리가 시작되기까지 최소 3분에서 최대 12분 59초가 걸렸습니다. 이 대기를 10초 이내로 줄인 과정을 기록한 글입니다. 그림 출처: AI 자동생성(https://youmind.com) 세 줄 요약 큐 역할을 하는 DB에 후보를 모았다가 처리하던 2단계 스케줄러(10분 주기)를 걷어내고, 요청 테이블과 처리 상태 테이블을 한 번에 보는 조회와 10초 폴링으로 변경했습니다. 자동승인 대상건 생성 후 처리 […]
The post 사장님 입점신청 자동승인 주기를 10분에서 10초로 first appeared on 우아한형제들 기술블로그. ||
사장님의 입점신청 요청들은 자동승인 처리가 시작되기까지 최소 3분에서 최대 12분 59초가 걸렸습니다. 이 대기를 10초 이내로 줄인 과정을 기록한 글입니다.
그림 출처: AI 자동생성(https://youmind.com)
세 줄 요약
큐 역할을 하는 DB에 후보를 모았다가 처리하던 2단계 스케줄러(10분 주기)를 걷어내고, 요청 테이블과 처리 상태 테이블을 한 번에 보는 조회와 10초 폴링으로 변경했습니다. 자동승인 대상건 생성 후 처리 시작까지 최대 12분 59초 → 10초 이내로 개선했습니다(유입량이 처리 가능량을 넘지 않는다고 가정).
워커(자동승인 스케줄러가 도는 서버) N대 전부가 각각 폴링하고, 동시성은 락 안에서 상태를 확인하고 기록하는 구간이 막습니다. 처리 중간에 멈춘 건은 별도 클렌징 스케줄러가 되살립니다.
10초 폴링으로 주기를 기존의 1/60로 줄이면서도 외부 시스템으로 가는 부하는 변하지 않았습니다.
승인? 자동승인?
가게 사장님이 배달의민족에 입점하려면 계약과 승인 절차를 거쳐야 합니다. 이 요청들을 접수해서 승인까지 관리하는 사내 시스템이 있고, 저희 팀이 그 시스템을 개발하고 운영합니다. 서류가 다 갖춰졌고, 정책상 반려 사유가 없고, 앞 단계가 모두 끝난 요청은 사람이 판단할 것이 없습니다. 이러한 업주계약, 광고계약 요청을 시스템이 대신 승인하는 것이 자동승인입니다.
그런데 자동승인이 빠르지 않았습니다. 요청이 생긴 뒤 처리가 시작되기까지 최소 3분에서 최대 12분 59초가 걸렸고, 그동안 그 건은 담당자 목록에 그냥 밀린 일로 남아 있었습니다. 담당자가 기다리지 않고 직접 처리하면, 자동승인의 지연이 그대로 사람의 일로 넘어갑니다.
자동승인 대상의 대다수가 생성 즉시 자동승인이 가능한 요청들입니다. 반면 만들어질 때는 조건을 다 채우지 못했다가 나중에 갖춰지는 요청은, 조건이 갖춰진 뒤에도 다음 재시도 시각까지 기다립니다.
이 글은 주기를 줄이기 위해 어떤 고민을 했는지에 대한 기록입니다.
기존 구조에서 최소 대기 구간이 존재했던 이유
기존 자동승인은 두 개의 스케줄러로 나뉘어 있었습니다.
enqueue(수집) 스케줄러: 매시 07분부터 10분 간격(07분, 17분, 27분 …)으로 요청건이 저장된 imr 테이블에서 자동승인 후보를 찾아 auto_approve_outbox 테이블에 NEW 상태로 적재
enqueue에 주어진 시간은 다음 process 실행 전까지, 즉 3분
process(처리) 스케줄러: 매시 00분부터 10분 간격(00분, 10분, 20분 …)으로 auto_approve_outbox를 읽어 실제 자동승인 처리
process에 주어진 시간은 다음 enqueue 실행 전까지, 즉 7분. 그리고 이 스케줄러의 실행 간격이 곧 재시도 간격이 되어 재시도 주기는 10분
이름은 아웃박스지만 메시지 발행용 Transactional Outbox는 아닙니다. 스케줄러 하나가 채우고 다른 하나가 비우는 DB 작업 큐입니다. 후보를 모으는 일과 처리하는 일을 분리해 두면 각각을 독립적으로 재시도하고 관측할 수 있습니다.
적재와 처리를 다른 시각에 두는 것 자체는 자연스럽습니다. 문제는 이렇게 벌려 놓은 간격이 그대로 고정된 대기 시간이 된다는 것입니다.
enqueue가 도는 07분에서 다음 process가 도는 10분까지 언제나 3분의 간격이 있습니다. 다음 그림