분석 동시 실행에 상한을 두지 않는다
| 결정일 | 상태 | 원본 |
|---|---|---|
| 2026-07-31 | active | heymoa-ai/docs/decisions/2026-07-31-no-analysis-concurrency-cap.md |
APP-298에서 큐를 걷어내고 BackgroundTasks로 옮기면서 ANALYSIS_WORKERS가 사라졌다.
다시 넣지 않는다.
왜
상한이 막던 것을 지금은 다른 것이 막는다. 옛 워커 수는 두 가지를 겸했다 — 같은 잡이
두 번 도는 것과, 동시 LLM 요청이 provider rate limit을 넘는 것. 앞의 것은 이제
PgSingleFlight가 advisory lock으로 막는다. 인스턴스가 여럿이어도 동작해서 워커 수보다
낫다.
뒤의 것은 지금 잴 수가 없다. 접수량도 provider 한도도 아직 관측된 값이 없다. 숫자를 모른 채 상한을 넣으면 그 숫자가 근거 없이 굳고, 대개 너무 낮게 잡아서 분석이 한 줄로 선다.
넘쳤을 때 조용하지 않다. rate limit은 429로 오고, 섹션 재시도가 그것을 먹고
(analysis/timeouts.py의 RETRYABLE에 429가 명시돼 있다),
실행 지표 로그의 outcome=error와 재시도 경고에 남는다. 무엇이 문제인지 모르는 채로
느려지는 상황이 아니다.
되돌리는 조건
셋 중 하나면 상한을 다시 넣는다.
| 신호 | 어디서 보나 |
|---|---|
| 429가 섹션 재시도를 다 태우고 실패로 끝난다 | outcome=error + "재시도한 섹션" 경고 |
접수가 몰릴 때 total_ms가 평소의 몇 배가 된다 | 실행 지표 로그의 분포 |
| DB 커넥션 풀이 마른다 | PgSingleFlight가 잠금마다 커넥션 하나를 쥔다 |
되돌릴 때는 워커 수가 아니라 동시 실행 세마포어로 넣는다. 워커 수는 큐가 있을 때 말이 되는 단위이고, 지금은 큐가 없다.
같이 봐야 하는 것
server-ai.md의 미결 3이 rate limit 관계를 "재 본 적 없음"으로 두고 있다. 그것이 재지면
여기 숫자가 정해진다.