Issue BH: [Infra] 성능 U5 — 유휴에도 분당 505 쿼리, 배포·클라우드 워커에 행별 예외 격리 누락(버그)

[Danto7632]

스케줄러·워커 감사 결과. 버그 1건(5-2)이 포함되어 있다.

확정 사실

유휴(사용자 0명·작업 0건) 상태에서 ≈505 쿼리/분:

• 1초 폴링 워커 4종이 각각 2 SELECT·2 tx → 8 tx/s = 480/분
  AgentRunWorker.java:58 · DeploymentRunWorker.java:22 · CloudConnectionVerificationWorker.java:22 · WebhookDeliveryWorker.java:22
• 15~60초 폴러·스윕 14종 ≈ 25/분

#	위치	문제
5-1	1초 워커 4종	일이 없어도 매초 recover SELECT + claim SELECT
5-2	DeploymentRunWorker · CloudConnectionVerificationWorker 의 executeQueued	버그: 행별 try/catch 가 없다. TaskRejectedException(실행기 포화) 하나가 루프를 끊어, 같은 배치에서 이미 claim 된 2번째 행이 IN_PROGRESS 인 채 리스 만료(2분)까지 방치된다. #55 에서 AgentRunWorker 만 고쳐진 형태가 그대로 남았다
5-3	WebhookDeliveryWorker.processDelivery	스케줄러 스레드에서 동기 처리 — 핸들러가 GitHub 을 호출한다
5-4	StuckDeploymentRecoveryWorker.java:47,76	멈춘 배포 1건당 매분 GitHub 호출, abandon(120분)까지 최대 120회. runId 가 없으면 per_page=30 목록 조회
5-5	DomainVerificationWorker.java:42, 92-95	배치 20건 × (Cloudflare + GitHub + HTTPS 프로브)를 스케줄러 스레드에서 직렬. 커스텀 도메인은 60초 고정 × 1440분 = 건당 최대 1,440회
5-7	StuckApprovalSweeper.java:30	60초 — 자바독이 "정상이면 항상 0건" 이라고 적은 회귀망
5-8	DeploymentRunWorker.renewLeases:31	레지스트리가 비어도 0행 매칭 UPDATE 를 무조건 실행(AgentRunWorker 는 skip 한다)
5-9	ChatTrashCleanupScheduler.java:16	엔티티 전체 로드 후 deleteById N회
5-10	DockerGarbageSweeper.java:49	prune 3회가 스케줄러 스레드 점유

할 일

• 5-2 먼저 — 행별 try/catch + releaseClaim(AgentRunWorker 패턴 복제)
• 1초 워커 4종: recover 를 claim 쿼리에 접어 1쿼리로 + 적응형 백오프(일 있으면 1s, 없으면 ×2, 상한 30s). 공통 베이스 클래스로 묶는다
• WebhookDeliveryWorker 처리를 전용 executor 로 위임
• StuckDeploymentRecoveryWorker 조회 실패 횟수 지수 백오프(1→2→5→10분)
• DomainVerificationWorker executor 위임 + 생성 후 경과시간별 간격(10분까지 1분 → 1시간 이후 10분)
• StuckApprovalSweeper 5분, renewLeases skip, ChatTrashCleanupScheduler 벌크 delete, DockerGarbageSweeper 비동기

의존: #335(U0)의 spring.task.scheduling.pool.size 가 먼저 들어가야 위임 효과가 온전하다.
주의: 워커의 claim 은 행 단위 조건부 UPDATE 로 다중 인스턴스 안전이 이미 확보돼 있다 — 이 성질을 깨지 말 것.

기대

유휴 505/분 → 30/분 이하. 태스크 투입 시 첫 claim 지연은 1초 이내 유지.

계획 원문: .agent-team/00-plan/perf-cost-plan.md U5

[Danto7632]

실측 정정 — 유휴 쿼리는 추정 505/분이 아니라 2245/분 이었다

로컬에 CI 와 같은 MySQL 8.0 을 띄우고 develop 6960436 을 dev 프로파일로 기동해, 사용자 0명·작업 0건 상태에서 60초 동안 SHOW GLOBAL STATUS LIKE 'Questions' 델타를 쟀다.

2245 쿼리 / 60초 = 2245/분 = 37.4/초 — 이슈 본문의 코드기반 추정(505/분)의 4.4배다.

어디서 오는가 (60초 상위 다이제스트)

문장	횟수	비중
SET autocommit = ?	1501	67%
COMMIT	717	32%
agent_runs recover(lease 만료)	79
agent_runs claim(next_run_at)	79
deployment_histories recover/claim	79 × 2
cloud_connection_verification_jobs recover/claim	79 × 2
webhook_deliveries recover/claim	78 × 2
SET SESSION TRANSACTION READ ONLY	52

비용의 99%(2218/2245)가 SELECT 자체가 아니라 트랜잭션 의례다. 폴링 1회를 각각 별도 트랜잭션으로 감싸기 때문에 왕복이 SET autocommit=0 → SELECT → COMMIT → SET autocommit=1 로 4배가 된다. 워커 4종 × recover/claim 2회 = 폴링당 8 트랜잭션이고, 그것이 초당 반복된다.

이 사실이 바꾸는 것

1. 적응형 백오프의 효과가 추정보다 크다. SELECT 뿐 아니라 의례까지 같은 비율로 줄어든다. 폴링을 30배 줄이면 2245/분 → 약 75/분(추정).
2. recover + claim 을 한 트랜잭션으로 합치는 것이 단독으로도 큰 효과다 — 의례가 절반이 된다. 본문 5-1 의 "recover 를 claim 쿼리에 접기" 가 이것이다. 백오프보다 먼저 해도 즉시 효과가 있다.
3. 폴링 경로에서 트랜잭션을 아예 없애는 것을 검토할 값어치가 있다. claim 은 조건부 UPDATE 한 문장이라 autocommit 으로 충분한 경우가 많다. 다만 recover→claim 의 원자성이 필요한지 먼저 확인해야 한다.

재현

scratchpad/measure-idle.sh <워크트리> <스키마suffix> 60

기준선 전문은 .agent-team/00-plan/ 옆 스크래치패드 baseline.md. 테스트 기준선은 1418 통과 / 실패 0 / 스킵 12.

[Danto7632]

정정 — 앞 코멘트의 2245/분은 오염된 측정이었다. 정본은 1904/분

앞서 올린 수치는 테스트를 돌린 뒤의 스키마에서 쟀다. 거기엔 PENDING 상태의 웹훅 배달 행이 남아 있었고, 워커가 그걸 계속 재처리하며 실패하고 있었다(webhook payload 필드가 없습니다: repository.full_name 25회). 유휴가 유휴가 아니었다.

신규 스키마에서 다시 잰 값:

대상	유휴 쿼리/분
develop 6960436 — 정본 기준선	1904
(참고) 오염된 첫 측정	2245

앞 코멘트의 나머지 분석은 그대로 유효하다. 트랜잭션 의례가 비용의 대부분이라는 것, 그래서 recover+claim 합치기와 적응형 백오프의 효과가 추정보다 크다는 것은 오염분과 무관한 구조적 사실이다(1904 중에서도 SET autocommit + COMMIT 이 대부분).

측정 시 주의 (다음 사람용)

반드시 새 스키마에서 잴 것. qp_u* 처럼 테스트를 돌린 스키마에는 워커가 집어갈 행이 남는다.

scratchpad/measure-idle.sh <워크트리> <한번도_안쓴_스키마suffix> 60

참고 — U0(#335) 적용 후는 1996/분으로 늘었다

회귀가 아니다. 스케줄러 스레드가 1→6 이 되면서, 서로를 밀어내 제때 못 돌던 잡들이 각자 예정대로 돌기 시작한 결과다. 즉 1904 는 "부하가 낮아서" 가 아니라 "일부 잡이 굶고 있어서" 나온 숫자이기도 했다. 이 단위(U5)가 줄여야 할 대상은 그 위에서의 폴링 빈도다.

[Danto7632]

PR #350 으로 해소. base 가 develop 이라 수동으로 닫는다.

유휴 쿼리 1904 → 74/분 (−96%), 신규 스키마 2개 + 리드 독립 측정으로 3회 확인. 워커가 죽은 게 아니라 덜 도는 것도 다이제스트로 확인했다(4종 각각 60초에 정확히 2회 폴링).

함께: 배포·클라우드 워커에서 실행기 포화 시 TaskRejectedException 이 루프를 끊어 같은 배치의 다음 작업이 IN_PROGRESS 인 채 2분 방치되던 버그를 고쳤다(#55 에서 AgentRunWorker 만 고쳐진 형태가 남아 있었다).

남은 74 의 절반 이상은 provisioning/** 이고 #344 구역이다.