배경

응답 데이터를 기반으로 통계를 집계하는 과정에서, 데이터 누락 및 중복 상황 발생.

특히 트랜잭션 커밋 지연 상황에서 스케줄러가 데이터를 조회하면, 커밋되지 않은 데이터 누락 문제가 발생하거나, 조회 범위를 조정할 경우 중복 처리 문제가 나타났다.

이에 따라, 스케줄링 기반 접근을 개선하거나 이벤트 기반 처리 방식을 도입하는 방안을 검토하였다.

문제사항 및 고려사항

(1) 스케줄링 기반 방식

• 구현 방식:
  • 정해진 주기(10초)로 스케줄러가 DB에서 데이터를 조회 및 집계.
  • READ UNCOMMITTED + 조회 범위 조정으로 데이터 누락 방지.
  • 중복 발생 시, 중복 제거 로직을 추가하여 보완.
• 문제사항:
  1. 트랜잭션 미완료 데이터 조회 위험 (Dirty Read).
  2. 조회 주기와 커밋 타이밍 불일치로 인한 데이터 누락/중복 발생.
  3. 주기 단위 처리 → 실시간성 부족.
  4. 주기 단위 반복 조회로 DB 부하 가능성 증가.
• 고려사항:
  • 데이터 정합성을 100% 보장하기 어려움.
  • 실시간성 요구사항이 강한 서비스에는 부적합.

(2) 이벤트 기반 방식

• 구현 방식:
  • 응답서비스가 응답을 처리하고 응답 이벤트를 발행.
  • 메시지 큐(RabbitMQ) 에 해당 이벤트 적재.
  • 통계 도메인이 해당 메세지 큐를 소비하여 즉시 통계 집계 로직 실행.
• 장점:
  1. 데이터 발생 시점에 바로 처리 → 실시간성 확보.
  2. 커밋된 데이터를 기반으로 처리 → 데이터 정합성 보장.
  3. 불필요한 주기성 DB 조회 제거 → 성능 및 자원 효율성 향상.
  4. 장애 상황에서도 메시지 재처리(DLQ) 가능.
• 고려사항:
  • 이벤트 기반 아키텍처 도입에 따른 시스템 복잡성 증가.
  • 스케줄링 기반 방식대비 건당 처리시간 증가(네트워크 트래픽 및 건별 처리)

결론 및 최종 선택 근거

• 스케줄링 기반:
  • 초기에 선택하여 적용하였지만, 데이터 누락문제 발생.
  • READ UNCOMMITTED 사용 및 범위 조정으로 누락 문제를 해결하려 하였지만, 데이터 중복 문제 발생
  • 실시간성 요구사항을 충족하지 못함.
  • 응답 건당 처리 속도는 빠름.
• 이벤트 기반:
  • 데이터가 발생하는 즉시 처리 가능 → 실시간성 충족.
  • 커밋 이후 이벤트 발생 처리 → 데이터 정합성 확보.
  • 메시지 큐 및 DLQ를 통한 확장성, 장애 복원력 보장.