시나리오 : 공지사항 페이지 (목록 조회) 성능 테스트

부하 테스트 사용 툴: ngrinder, scouter

1. JPA N+1 문제 해결 및 조회 API 성능 최적화

1. 배경

• 전체 조회 api 에서 5000개의 데이터를 한번에 보여주는 상황
• 문제 상황: '폐기물 기록 전체 조회' API에서 심각한 성능 저하 현상 발생.
  • nGrinder를 이용한 부하 테스트 결과, 초기 TPS(초당 처리량)가 1.3에 불과하여 대규모 트래픽 처리 및 서비스 확장성에 큰 제약이 있음을 확인.

2. 원인 분석

• Hibernate가 발생시키는 SQL 로그 분석 결과, 목록 조회를 위한 기본 쿼리(1) 실행 후, 조회된 데이터 수(N)만큼 연관된 하위 엔티티(User, Profile, WasteItem)를 조회하는 추가 쿼리가 발생하는 N+1 문제임을 파악.
• 하나의 API 요청에 수백 개 이상의 불필요한 쿼리가 실행되어 DB와 애플리케이션에 과도한 부하를 유발하는 것이 근본 원인.

3. 해결 과정 및 기술적 결정

• 1단계: Fetch Join과 Batch Size를 이용한 N+1 완화

  • 적용 :
    • @ManyToOne, @OneToOne 관계(User, Profile)에는 Fetch Join을 적용하여 즉시 로딩으로 쿼리 수 감소.
    • @OneToMany 관계(WasteItems)에는 @BatchSize를 적용하여 지연 로딩 시 IN 절을 통한 일괄 처리로 N+1 쿼리 완화.
  • 결과: TPS가 1.3에서 4.1로 약 3배 개선되었으나, 여전히 엔티티를 조회함에 따른 영속성 컨텍스트 관리 오버헤드와 불필요한 컬럼 조회 문제가 남아있음을 인지.

• 2단계: DTO 직접 조회를 통한 근본적인 성능 최적화

  • 전략: 엔티티를 조회한 후 DTO로 변환하는 기존 방식에서 탈피, **QueryDSL의 Projections**를 사용하여 조회 결과를 DTO로 직접 매핑하는 방식으로 리팩토링을 진행.
  • 기술적 결정 이유:
    • SELECT 절 최적화: SQL 레벨에서 API에 필요한 컬럼만 정확히 지정하여 조회함으로써 네트워크 트래픽과 DB 부하를 최소화. (기존에는 응답 DTO에서 ToMany 리스트를 호출)
    • 영속성 컨텍스트 부하 제거: 엔티티를 거치지 않아 영속성 컨텍스트의 스냅샷 생성 및 변경 감지 오버헤드를 원천적으로 제거.
    • N+1 문제 완전 해결: DTO에 없는 컬렉션 필드에 대한 접근 가능성을 차단하여 불필요한 지연 로딩 발생 가능성을 근본적으로 해결.