[gihhyeon]

요약

조회마다 원본 로그를 남기고, 매일 새벽 전날 로그와 집계를 비교해 누락률을 기록하고 집계를 로그 기준으로 보정한다. 실시간 비동기 증가는 그대로 유지한다.

What — 무엇을 바꿨나

• PlaceViewLog(place_view_log) 추가: 상세 조회 시 요청 트랜잭션에서 동기 적재
• 조회 기록(로그 적재 + 비동기 증가)을 승인 검사 뒤로 이동하고, 조회 날짜를 요청 시점에 고정해 비동기 증가에 전달
• ViewCountReconciliationService 추가: 날짜별로 로그와 daily_view_count를 비교해 보정
• ViewCountReconciliationScheduler 추가: 매일 04:00(KST) 실행, 밀린 날짜 처리, Discord 알림, 60일 지난 로그 삭제
• ViewCountReconciliation(view_count_reconciliation) 추가: 날짜별 검증 결과 기록
• ViewCountReconciliationProperties 추가 (app.view-count.reconciliation)
• prod 수동 DDL 스크립트 sql/view_count_reconciliation.sql 추가

Why — 왜 필요한가

지금은 @Async 증가만 있어서 스레드 풀 포화, 비동기 예외, 서버 종료나 크래시 때 카운트가 조용히 유실된다. 원본 데이터가 없으니 얼마나 빠지는지 측정할 수 없고 재집계도 할 수 없다. 또 같은 날 첫 조회가 동시에 들어오면 daily_view_count 행이 중복으로 생긴다.

How — 어떻게 구현했나

• 원본 로그를 기준 데이터로 삼고, 기존 집계는 로그에서 파생된 값으로 본다
• 보정 순서
  1. 로그 건수와 daily 합계(중복 행 포함)를 맛집별로 비교해 delta = 로그 − 집계를 구한다
  2. 해당 날짜 daily 행을 지우고 로그 기준으로 맛집당 1행씩 다시 넣는다 (중복 행도 함께 정리)
  3. 같은 delta를 place.view_count에 반영한다
• 보정 후에는 집계와 로그가 같아져 다시 실행해도 delta가 0이다. 최초 측정값을 지키려고 이미 결과가 있는 날짜는 스케줄러가 건너뛴다
• 검증 이력이 없으면 어제만 처리한다. 로그 도입 전 날짜를 보정하면 집계가 0으로 덮이기 때문이다
• 조회 기록을 승인 검사 뒤로 옮긴 이유: 정상 화면 흐름에서는 미승인 맛집 상세 조회가 없지만, API를 직접 호출하면 비동기 증가는 나가고 로그는 404 롤백으로 사라진다. 이 차이가 매일 과집계 알림으로 잡히지 않도록 로그와 카운트를 같은 지점에서 기록한다
• 보정 서비스와 스케줄러를 분리해 @Transactional self-invocation 문제를 피한다
• 단일 EC2 인스턴스라 분산 락은 넣지 않았다

체크리스트

• 불필요한 주석/코드 제거
• 테스트 추가/갱신 및 통과 (./gradlew build, 66개 통과)
• 공개 계약 영향 확인: 엔드포인트와 응답 형태 변경 없음

관련 이슈

• close [feature] 조회수 원본 로그 적재 및 일별 검증 보정 #176

기타 / 리뷰 포인트

• ⚠️ prod 배포 전에 sql/view_count_reconciliation.sql DDL을 수동으로 적용해야 한다 (ddl-auto: validate라 테이블이 없으면 기동 실패)
• DDL과 엔티티 매핑이 맞는지는 로컬 MySQL validate 기동으로 확인하지 못했다
• 알림 조건: 누락률이 1%를 넘거나 과집계가 1건 이상일 때. 임계치는 설정으로 조정 가능
• 수동 재집계 API는 /admin/** 인증이 정비된 뒤 별도로 다룬다