비활성 BookingSlot 자동 정리 스케줄러 구현

[sehan528]

Description

과거 데이터 정리 자동화 / 스케줄러 설계 / Spring Batch vs @scheduled 기술 선택

배경

현재 상황

• 예약되지 않아 사용되지 않는 BookingSlot 데이터가 DB에 지속적으로 누적
• 조회 성능 저하 우려 (전체 슬롯 중 활성 슬롯 비율 감소)
• 운영 데이터 분석 시 노이즈 증가

목표

• 자동 정리 시스템 구현: 비활성 BookingSlot을 주기적으로 안전하게 삭제
• 기술 선택 근거 확립: Spring Batch vs @scheduled 비교 분석
• 운영 안정성 확보: 트래픽 최소 시간대 실행, 페이징 삭제로 Lock 최소화
• 모니터링 체계 구축: 실행 시간, 삭제 건수, 성공/실패 추적
• 확장 경로 확보: 데이터 규모 증가 시 Batch 전환 기준 명시

핵심 의사결정

선택: @scheduled 기반 스케줄러

항목	@scheduled	Spring Batch
데이터 규모	수만 건 ✅	수백만 건 이상
구현 복잡도	낮음 ✅	높음
학습 비용	없음 ✅	높음
실패 복구	수동 (다음 날 재실행) ✅	자동 재시작
운영 부담	낮음 ✅	높음 (별도 서버)

선택 근거:

• 데이터 규모: 월 평균 5,000~10,000건 (Batch는 과도함)
• 실행 환경: 새벽 3시 트래픽 최소 구간 (실패 시 즉각 영향 없음)
• 복잡도: 단순 DELETE 작업 (Chunk 처리, 재시작 불필요)

---

Todo

• 1. Spring Batch vs @scheduled 기술 조사

  • Spring Boot의 WebApplicationType 이해 (SERVLET vs NONE)
  • @scheduled의 스케줄링 기능 확인
  • Spring Batch의 역할 명확화 (스케줄러 ≠ 배치 프레임워크)
  • 각 기술의 적합한 사용 사례 정리
  • 데이터 규모/실행 환경/복잡도 기준 수립

• 2. 기술적 의사결정 문서 작성

  • 설계 진화 과정 3단계 정리 (강결합 → Cascade → 누적 문제)
  • @scheduled 선택 근거 작성
  • 트레이드오프 분석표 작성
  • Spring Batch 전환 기준 명시
  • 면접 대응 Q&A 시나리오 작성

• 3. 삭제 대상 정의 및 쿼리 작성

  • 삭제 조건 명확화
  • Repository 메서드 작성
  • 인덱스 최적화

• 4. 스케줄러 서비스 구현

• 5. 스케줄러 설정

  • @Scheduled 설정
  • 실행 시간대 근거 문서화
  • @EnableScheduling 활성화 확인

• 6. 테스트

  • 테스트 데이터 생성
  • 삭제 로직 검증
  • 성능 측정

---