[PRODUCT-285] [Refactor] SLO에 영향을 미치는 쿼리 개선 작업

[lvalentine6]

🏷️ 상위 작업 (Ticket Number)

PRODUCT-119

🚀 구현 내용

• /api/shop 연관 API들이 정의된 SLO를 준수하지 못하여 에러 버짓이 소모되고 있습니다.
  • 연관 SLO.2 P95 레이턴시 API 500ms 이하
  • 현재 /api/shop 연관 API 레이턴시 평균 800ms
• 해당 API들을 분석하고 쿼리를 개선하여 SLO를 준수할 수 있도록 수정합니다.
• 개선 완료 후 Datadog APM 기반으로 /api/shop/* P95 응답 시간을 재측정하여, 500ms 이하 달성을 검증합니다.

📅 마감일

25.10.31

[lvalentine6]

추가 분석 및 대응 계획

EntityGraph + Pageable 조합으로 인해 발생한 인메모리 페이징 문제가 확인되었습니다.
현재 구조에서는 JPA가 전체 데이터를 메모리로 가져온 뒤 페이징을 적용하기 때문에,
/api/shop, /api/store, /api/cheer API의 쿼리 응답 지연으로 이어지고 있습니다.

EntityGraph를 유지한 채 DB 레벨에서 페이징을 적용하려면
서비스 로직 단에서 쿼리 분리(Query Split) 또는 커스텀 QueryDSL 작성이 필요합니다.
이는 구조적 변경 범위가 커 단기적으로는 @BatchSize를 통해 Lazy 로딩 시 N+1 문제를 완화하고
SLO 영향을 최소화하는 방향으로 접근합니다.

적용 후 Datadog APM 기반으로 응답 시간 및 에러 버짓 소모량을 모니터링하면서,
향후 트래픽 패턴과 SLO 추이를 기반으로 쿼리 분리 및 DSL 기반 최적화 여부를 재검토할 예정입니다.

[lvalentine6]

이슈 작업 완료

• /api/shop, /api/store, /api/cheer API의 EntityGraph를 제거하고 Batch Fetch를 적용했습니다.
• 실제 Prod 데이터 분석 결과, 연관 데이터 개수가 대부분 10개 이하로 나타났습니다.
  → 최적 배치 크기는 10이지만, 향후 데이터 증가를 고려해 30으로 설정했습니다.
• 아래는 배치 크기에 따른 테스트 결과입니다.

구분	배치 미적용	배치 크기 10	배치 크기 30
쿼리 실행 방식	N+1 문제 발생	Batch Fetch 적용	Batch Fetch 적용
총 실행 쿼리 수	41개	5개	5개
평균 레이턴시	약 45ms	약 20.5ms	약 23.5ms

• dev 환경에 배포를 완료하였고 현재까지 예상한대로 정상적으로 작동하고 있어 1~2일 후 prod 적용 예정입니다.
• 이슈를 완료 처리 합니다.