배치 모니터링과 청크 전환 시그널
상태
승인
후보군
| 방안 | 설명 |
|---|
| DB 로그 + Discord + Micrometer 메트릭 | run 결과를 marketflow_collect_log에 기록, 실패 시 Discord 알림, 행수·소요·재시도를 OTel 메트릭으로 export해 Grafana 대시보드·임계 알람 |
| Spring Batch JobRepository | Batch 메타 테이블로 실행 이력·재시작 관리 |
| 로그만 (별도 계측 없음) | 애플리케이션 로그에 남기고 수동 확인 |
결정
@Scheduled 배치는 단순 유지하되, 모니터링을 3층으로 구성한다.
- 실행 이력:
marketflow_collect_log에 run별·통계별 상태·행수·소요·에러 기록 (관측 스택 비의존).
- 즉시 알림: 실패·부분 실패 시
DiscordNotificationGateway로 통지.
- 전환 시그널 메트릭: Micrometer 메트릭(행수·소요·upsert·재시도) → OTel agent 자동 export → Grafana 대시보드·임계 알람.
임계 지속 초과 시 Spring Batch(청크·restart·partition) 도입을 트리거한다.
결정 이유
- 현재 일량(하루 5~10콜, ~14,000행)은 Batch 청크가 불필요하다(ADR-002 후속). 그러나 언제 전환해야 하는지 판단할 객관 지표가 필요하다.
- DB 로그는 Collector·Grafana가 죽어도 동작하는 가장 신뢰성 있는 실행 이력이다. 마감 후 배치라 실패를 사람이 실시간으로 못 보므로 Discord 알림이 필수다.
- 메트릭은 기존 옵저버빌리티 스택(OTel→Grafana, OTel Java agent 자동계측)에 그대로 올라탄다. 신규 계측 인프라가 없다.
전환 임계(초안)
| 메트릭 | 임계 |
|---|
| 단일 통계 수집 행수 | > 50,000행 지속 |
| 배치 전체 소요 / 단일 통계 | > 5분 / > 2분 |
| 벌크 upsert 소요 | > 30초 |
| JVM heap | 수집 중 사용률 급증·OOM 근접 |
| 부분 실패·KRX 429 재시도 | 빈발 (재처리·restart 가치 발생) |
검토 대안
| 방안 | 기각 이유 |
|---|
| Spring Batch JobRepository | 전환 판단 전부터 Batch를 도입하는 셈 — 지금은 과투자 (ADR-002) |
| 로그만 | 추세·임계 관측 불가, 전환 시점을 객관적으로 판단 못 함 |
트레이드 오프
| 구분 | 내용 |
|---|
| 득 | 단순 배치 유지 + 신뢰성 있는 이력·알림 + 객관적 전환 시그널, 기존 관측 스택 재사용 |
| 실 | collect_log 테이블·메트릭 emission 코드 추가, Grafana 대시보드/알람은 STK-OBS 완료에 의존 |