[FEATURE] 크롤러 우선순위 동적 분배 — 3-tier resolver chain 진화 (메타)

[juhy0987]

배경

라이브 분석에서 fetcher pool 활용도 측정:

Pool	Workers	Peak Busy	Utilization
normal	6	6/6	100% (saturated)
chromedp	2	2/2	100% (saturated)
high	3	0	0% (idle)
low	2	0	0% (idle)

원인: `SourcePriorityResolver` / `RuleBasedPriorityResolver` 둘 다 등록 룰 0개 → 모든 job 이 `DefaultPriorityResolver` 의 Normal 로 흘러감. high (3) + low (2) = 5 worker idle.

본 메타 이슈는 priority 결정을 정적 카테고리 → 동적 score → 운영자 override 의 3단계로 진화시켜 high/low pool 을 의미 있게 활용하고, 호스트 별 특성에 따라 자동 분배를 가능하게 한다.

3-tier semantic

Tier	의미	카테고리 / 후보
High	시의성 + 사회적 영향 高	실시간 뉴스 / 정치 / 경제 / 시사 / 사회
Normal	일반 갱신 + retry	일반 카테고리 (스포츠/문화/IT/연예/생활/국제), 커뮤니티 article, retry 작업, 신규 host 첫 cycle
Low	광범위 탐색 / discovery	사이트맵, category hub traverse, pagination 깊은 페이지, 백필

단계별 진화 (Sub-issues)

Sub A — CategoryBased + Retry (즉시 가치)

정적 카테고리 + Target.Type 기반 분류. 운영자 매핑 0개 의존하지 않고 3개 tier 모두 활용 시작.

`RetryPriorityResolver` 도 함께 추가 — RetryCount>0 → Normal 강제 (reparse cycle 안정성).

Sub B — Host signal scoring (Normal ↔ High 동적)

Low 후보는 CategoryBased 가 담당. scoring 은 High vs Normal 만 결정.

Signal: freshness / impact / cost / reliability + host 신뢰도.

구현 영역: signal 수집 인프라, `host_scoring_state` 테이블, Redis cache, 5분 주기 scorer goroutine, `DynamicScorePriorityResolver`.

Weight 는 cluster-wide env (per-host 는 Sub C 에서).

Sub C — Per-host hyperparameter + time-bound override

• per-host signal weight — host 마다 weight 다르게 책정
• `fetcher_rules.priority_config` JSONB 신규 컬럼
• 운영자 explicit base_priority override
• `override_until` (time-bound)
• env-only 운영 인터페이스

Resolver chain 최종 구상

```

1. ExplicitPriorityResolver (job.Priority 명시 시 — 기존)
2. RetryPriorityResolver NEW (RetryCount>0 → Normal — Sub A)
3. OverridePriorityResolver NEW (fetcher_rules.priority_config.base_priority — Sub C)
4. CategoryBasedResolver NEW (Target.Type / host category — Sub A)
5. DynamicScorePriorityResolver NEW (host_scoring_state → High vs Normal — Sub B)
6. SourcePriorityResolver (기존, backward compat)
7. RuleBasedPriorityResolver (기존, backward compat)
8. DefaultPriorityResolver (Low fallback — cold-start, Sub A 도입과 함께 Normal → Low 로 변경)
   ```

운영 결정 (사용자 확정)

1. 시스템 자체 작업 (refinement / stale relearn) → 다른 루트로 처리 중 → priority 분리 X
2. Weight 운영 인터페이스 → env-only
3. Cold-start → Low (DefaultPriorityResolver fallback 변경)
4. Manual override → time-bound 지원
5. Signal weight → per-host 책정

완료 조건 (전체)

• Sub A 머지 — high/low pool 활용 시작
• Sub B 머지 — host signal 기반 동적 High↔Normal
• Sub C 머지 — 운영자 override + time-bound + per-host weight
• 라이브 cycle 검증 — 4 pool (high/normal/low/chromedp) 모두 의미 있는 utilization

참고

• 현재 resolver chain: cmd/issuetracker/main.go:108-110
• Resolver 인터페이스: internal/processor/fetcher/worker/resolver.go
• 라이브 분포 (직전 19분): priority=2 (Normal) 227건 / High 1 / Low 1

[juhy0987]

⚠ Prerequisite 추가 — Sub A 재설계

작업 진행 중 발견: `scheduler.JobEmitter` 가 publisher 의 PriorityResolver chain 을 우회하고 `entry.Priority` 로 직접 Kafka 발행 → 본 메타의 의도 (resolver chain 진화) 가 시드 / retry / upgrade 경로에서 무효화.

해결: Publisher 모듈을 Kafka 발행 단일 책임 hub 로 통합하는 prerequisite 메타 #385 신규 등록. Sub 1~6 머지 후 본 메타의 resolver chain 작업이 모든 발행 경로에 일관 적용됨.

Sub A (#381) 처리

• 직전 PR [FEAT#381] CategoryBased + Retry priority resolver — 3-tier 활용 시작 (#380 Sub A) #384 (CategoryBased + Retry resolver) 의 변경점은 폐기 (현재 `JobEmitter` 우회 문제로 의도 미달)
• Sub A 재작성 — [FEATURE] Publisher 통합 모듈화 + Kafka I/O 단일 책임 분리 (메타) #385 머지 후 publisher facade 위에서 새 PR 생성
• 기존 issue [FEATURE] CategoryBased + Retry priority resolver — 정적 카테고리 기반 3-tier 활용 (#380 Sub A) #381 close, 재작성 시점에 신규 sub-issue 등록 예정

Sub B (#382) / Sub C (#383)

• 그대로 유지 — [FEATURE] Publisher 통합 모듈화 + Kafka I/O 단일 책임 분리 (메타) #385 머지 후 publisher 위에서 진행

새 진행 순서

1. [FEATURE] Publisher 통합 모듈화 + Kafka I/O 단일 책임 분리 (메타) #385 (publisher 통합 메타) Sub 1~6 머지 ← 현재 작업 대상
2. 본 메타의 Sub A 재작성 + 머지
3. 본 메타의 Sub B ([FEATURE] Host signal scoring 기반 동적 High↔Normal priority 결정 (#380 Sub B) #382) 진행
4. 본 메타의 Sub C ([FEATURE] Per-host hyperparameter + time-bound priority override (#380 Sub C) #383) 진행