ADR-008. 예측 갱신 실행 주체 (별도 worker 서버 vs backend consumer)

예측 갱신 실행 주체 (별도 worker 서버 vs backend consumer)

상태

승인

후보군

방안	설명
별도 worker 서버	신규 Spring Boot(:8091)가 이벤트 소비·재계산 오케스트레이션 전담
backend Kafka consumer	backend presentation에 ~EventWorker 추가, 같은 프로세스에서 소비
ml Python consumer	ml에 Kafka consumer 추가, 직접 소비·계산·저장

결정

별도 worker 서버(:8091) 를 신설해 이벤트 소비·재계산을 전담한다. worker는 stateless — 입력은 backend read API, 계산은 ml, 영속화는 backend가 담당한다.

시각화

flowchart LR
    subgraph 채택["별도 worker 서버"]
        T1[collected.v1] --> W1[worker :8091]
        W1 --> B1[backend]
        W1 --> M1[ml]
    end
    subgraph 대안["backend consumer"]
        T2[collected.v1] --> B2[backend EventWorker]
        B2 --> M2[ml]
    end

결정 이유

• 사용자 결정 — 이벤트 소비·재계산을 API 서빙 프로세스와 격리하고, 독립적으로 운영·확장한다.
• worker를 stateless로 두면 데이터 소유권은 backend(영속화)·ml(계산)에 남아 기존 컨벤션과 충돌하지 않는다.

검토 대안

방안	기각 이유
backend consumer	새 배포물이 없어 가장 단순하나, 프로세스 격리가 없음 (사용자가 격리 선호)
ml Python consumer	ml stateless 방향 위배, Python 컨슈머 운영 추가

트레이드 오프

구분	내용
득	API 서빙과 배치/이벤트 처리 격리, 독립 배포·확장
실	1일 1회 트리거 대비 배포물·컨슈머그룹·오프셋·DLQ 운영 추가. worker↔backend↔ml 네트워크 홉 증가