조회 모델(Read Model)의 가시성 처리 전략: 실시간 반영 vs 자정 배치의 Trade-off와 하이브리드 아키텍처 구축

• 분야: MSA, CQRS Pattern, Read Model Optimization, Performance Tuning, Hybrid Visibility Strategy
• 관련 파일: ProductViewCommandService.java, ProductViewRepository.java, StockEventConsumer.java, DailyStockResetEvent.java

---

1. 발단: 조회 서비스(Catalog)의 '가시성 보장'과 'I/O 부하'의 딜레마

CQRS 패턴에 따라 카탈로그 서비스는 오더/인벤토리의 도메인 이벤트를 구독하여 조회 전용 데이터셋(MongoDB)을 실시간으로 동기화하고 있었음. 하지만 대규모 트래픽 시나리오를 고려했을 때, 시스템의 구조적 병목 예상이 감지됨

• 기존 구조의 병목: 상품 정보 수정, 품절, 자정 재고 초기화 등의 이벤트가 발생할 때마다 몽고DB에 실시간 Write(CUD) 연산이 쏟아짐

→ 이로 인해 Read 전용 데이터베이스여야 할 몽고DB의 I/O 자원이 대량의 Write 트래픽에 점유당하면서, 정작 메인 화면을 조회하는 고객들의 조회 성능이 저하되는 역설적인 현상이 발생함.

2. 문제 인식 및 대안별 Trade-off 분석

이를 해결하기 위해 카탈로그의 가시성 업데이트 주기를 조정하는 세 가지 아키텍처 대안을 검토함.

아키텍처 대안	구현 특징	장점	치명적인 단점 (Trade-off)
대안 A: 실시간 전단지 (기존 상태)	이벤트를 받는 즉시 몽고DB 상태(isVisible, status)를 무조건 실시간 수정 및 반영	데이터 정합성이 거의 실시간으로 유지됨	대규모 트래픽 시 주문/재고 서비스의 이벤트 폭주로 몽고DB Write 병목 ⇒ 조회 성능 저하
대안 B: 고정 전단지st	실시간 이벤트 수신을 완전히 배제하고, 자정 배치 스케줄러를 통해서만 일괄 업데이트	카탈로그 서비스가 극도로 가벼워지며 최고의 조회 성능 확보	낮 11시에 품절된 상품이 밤 11시 59분까지 메인에 노출됨. 고객이 결제창까지 가야 튕김
대안 C: 하이브리드 전략 (최종 채택)	1. 상태값 변경(기간 만료 등): 자정 배치로 무겁게 갱신 2. 품절/복구: 이벤트 수신하되 캐시 무효화로 Read 부하 컷	Read 부하를 최소화하면서 고객에게 품절 데이터 파편화를 보여주지 않음	명령(Command)과 조회(Query) 파이프라인의 복잡도 증가

 

3. 해결 과정: 하이브리드 가시성 전략을 위한 몽고DB 배치 쿼리 최적화

대안 C(하이브리드 전략)를 위해 먼저, 자정 배치가 돌 때 몽고DB의 수만 건 문서 전체를 풀 스캔(findAll())하여 재고를 리셋하던 기존의 무거운 로직을 수정했음. 숨김(HIDDEN) 처리된 휴면 상품까지 전부 메모리에 올려 OOM을 유발하던 코드를 걷어냄.

1) 특정 상태 타겟팅 쿼리 메서드 추가 (ProductViewRepository.java)

// [Before] 기존 전체 조회 스캔
Page<ProductView> findAll(Pageable pageable);

// [After] 인덱스 기반 특정 상태 타겟팅 쿼리로 개선
Page<ProductView> findByStatusIn(List<String> statuses, Pageable pageable);

2) 배치 처리 범위 축소 및 미사용 필드 소거 (ProductViewCommandService.java)

자정 재고 초기화 시, 메인 화면 노출과 밀접한 ACTIVE, SOLDOUT 상태의 도큐먼트만 핀포인트로 해싱하여 Chunk 단위(100건)로 안전하게 끊어 처리하도록 로직을 리팩터링했음.

public void resetDailyStock(DailyStockResetEvent event) {
    List<String> targetStatuses = List.of("ACTIVE", "SOLDOUT");
    PageRequest pageRequest = PageRequest.of(0, 100);
    Page<ProductView> page;

    do {
        page = productViewRepository.findByStatusIn(targetStatuses, pageRequest); // 최적화 쿼리 호출!
        // ... 안전한 묶음 저장(saveAll) 진행
        pageRequest = pageRequest.next();
    } while (page.hasNext());
}

4. 최종 성과

• I/O 및 네트워크 비용 절감: 불필요한 미사용 필드(updatedOptionCount)를 DTO에서 제거하여 카프카 네트워크 페이로드 대역폭 최적화
• 풀 스캔 차단: 자정 재고 리셋 스케줄러 구동 시 수천/수만 건의 휴면 도큐먼트를 무시하고 필요한 데이터만 조회함으로써 배치 IOPS 성능 대폭 향상 및 OOM 원천 차단