[셀럽잇] 쿼리는 못말려 - (1) N + 1 문제 해결

 

 

 

 

🤔 서론

진행중인 셀럽잇 프로젝트가 운영 직전단계까지 진입했는데요, 정말 사용자들에게 서비스를 제공하기 전에 심각하게 문제가 될 수 있는 부분들에 대해서는 수정이 되어야 안전하게 배포할 수 있다고 판단했습니다.

 

그리고, 여러 문제들 중 가장 먼저 눈에 들어온 문제는 바로 쿼리였습니다.

 

저희는 쿼리의 발생 횟수를 로깅하는 기능을 만들었고, 이를 통해 쿼리가 특정 횟수 이상으로 발생하면 경로 로그를 찍어주도록 하였습니다.

 

4차 데모데이 때, 그러니까 우테코 크루들을 대상으로 서비스를 사용하도록 공개했을 당시 서버의 로그를 확인해보니 쿼리가 130번까지 찍혀있는 것을 확인했습니다.

(진짜 순간 잘못본건가 싶은...)

 

기본 20~30번은 우습고 90번, 100번이 넘어가는 쿼리들이 밥먹듯이 발생했는데요, 그때 당시에는 사용자가 많지 않기도 하고 데이터도 많이 없었기에 성능상 문제가 되지는 않았습니다.

 

하지만 실제 배포를 하게 된다면 많은 사용자가 사용할 것이고, 한 명의 사용자가 한 번 요청할 때마다 쿼리가 100번이 넘게 발생한다면 문제가 발생할 것이 틀림없을 것이라 생각했습니다.

 

또한 데이터가 늘어남에 따라 성능도 기하급수적으로 안좋아질 것이라 판단하여, 해당 문제를 해결하려 합니다.

 

 

 

 

 

 

 

🤔 테스트 상황 가정

테스트 상황은 다음과 같이 가정하겠습니다.

• 서비스의 1차적 최종 목표인 모든 셀럽 영상에 대한 데이터가 존재하는 상황

 

 

 

모든 셀럽 영상에 대한 데이터가 존재하는 경우의 데이터 수는 다음과 같습니다.

셀럽: 50명
음식점 수: 20000개
동영상 수: 20000개
음식점 당 이미지 수: 5개
하나의 회원이 평균 100개 정도의 음식점에 대해 좋아요 누름

(2만개인거 어떻게 알았을까요? ㅎㅎ....🥲)

 

 

 

테스트 환경은 다음과 같습니다.

데이터베이스: EC2에 설치, Mysql 사용
애플리케이션: 로컬에서 실행 (Mac m1 pro)

 

 

 

 

 

 

 

 

 

🤔 현재 코드의 성능

이제 주요 API별로 쿼리의 발생 횟수를 정리해 보도록 하겠습니다.

 

 

🐳 음식점 전체 조회 api

(해당 API의 기본 페이지 사이즈는 18개입니다.)

(비인증)

 

 

(인증 - 100개의 음식점에 대해 좋아요를 누른 경우)

 

 

 

 

 

🐳 음식점 상세 조회 api

(비인증)

 

 

(인증)

 

 

 

 

 

 

 

🐳 음식점의 주변 음식점 조회 api

(해당 API의 기본 페이지 사이즈는 4개입니다.)

(비인증)

 

 

(인증 - 100개의 음식점에 대해 좋아요를 누른 경우)

 

 

 

 

 

API	쿼리 개수	소요시간(단위: ms)
음식점 전체 조회 (비인증)	36번	1160ms
음식점 전체 조회 (인증)	137번 (좋아요 100개)	2946ms
음식점 상세 조회 (비인증)	6번	231ms
음식점 상세 조회 (인증)	7번	235ms
음식점의 주변 음식점 조회 (비인증)	11번	462ms
음식점의 주변 음식점 조회 (인증)	112번 (좋아요 100개)	2328ms

 

 

 

 

 

 

 

 

 

 

 

🤔 발생하는 쿼리 분석

가장 문제가 되는 음식점 전체 조회 API의 개선 과정만을 기록하도록 하겠습니다.

 

우선 어떠한 쿼리가 발생했는지 보기 위하여, 쿼리 로그 옵션을 주도록 하겠습니다.

logging:
  level:
    org.hibernate.orm.jdbc.bind: TRACE

spring:
  jpa:
    show-sql: true
    properties:
      hibernate:
        format_sql: true
        use_sql_comments: true
        highlight_sql: true

가장 먼저 음식점을 조회하는 쿼리와 음식점의 전체 수를 세기 위한 쿼리가 발생하였습니다.

 

 

 

 

 

이후 Video를 조회하는 쿼리가 발생하였습니다.

 

해당 쿼리는 아래 코드에서 발생합니다.

 

 

 

 

 

 

위 쿼리 18번

위 쿼리가 총 18번 동작한 것을 확인할 수 있었는데요, 원인은 아래 코드였습니다.

DAO에서는 프로젝션을 통해 DTO로 바로 조회하였기에, 영속성 컨텍스트에 restaurant에 대한 정보가 들어있지 않았고, 따라서 이로 인해 video.restaurant().id() 호출 시 지연 로딩으로 Restaurant에 대한 정보를 가져온 것입니다.

(비디오 조회 쿼리 1 번 + 조회된 비디오의 수 만큼 연관된 음식점 조회 쿼리 발생(N 번))

💡 위 코드에서 Restaurant의 ID(PK, 식별자)만을 사용하기 때문에, 원래는 쿼리가 발생하지 않는 것이 맞습니다.
그러나 저희는 getId()가 아닌 id()라는 네이밍으로 getter()를 사용하였기에, 이는 일반 메서드와 동일하게 동작하여 쿼리가 발생합니다.
getId()로 이름을 변경한다면 위 부분에서는 쿼리가 발생하지 않습니다.

 

 

 

 

 

 

이어서 음식점 사진들을 조회하는 쿼리가 발생하였습니다.

이는 아래 코드에서 발생합니다.

 

 

 

 

 

 

이후 회원 id로 좋아요를 조회하는 쿼리가 발생합니다.

해당 부분은 아래 코드에서 발생합니다.

 

 

 

 

 

 

해당 쿼리 셀 수 없을 정도로 많이

이후 위 쿼리가 정말 많이 발생합니다.

몇십개가 넘어서 세는건 포기했습니다..🥲

 

어디서 쿼리가 발생하는지 확인해보니 아래 코드였습니다.

 

 

 

 

 

위 쿼리는 아래 코드에서 발생하였습니다.

 

 

 

 

 

 

해당 쿼리 11번

마지막으로 셀럽을 조회하는 쿼리가 11번 발생하였습니다.

코드를 살펴보니 다음 부분이었습니다.

 

이제 이들을 본격적으로 개선하기 전에, 참고용으로 getId()와 id()를 비교해보도록 하겠습니다.

 

 

 

 

 

 

🐳 참고 - id() 대신 getId()를 사용하여 쿼리 수 줄이기

음식점에 대한 정보는 dto로 프로젝션하여 가져오기 때문에, 이후 코드들에서는 음식점에 대한 정보는 필요가 없고 단지 Id만을 사용할 뿐입니다.

따라서 조회된 음식점들을 모두 지연로딩 시키지 않는다면 쿼리 수를 줄일 수 있는데요, 실제로 id()만 getId()로 바꿔주어도 다음과 같이 쿼리의 개수가 36개에서 19번으로 줄어든 것을 확인할 수 있었습니다.

 

 

그러나 여전히 쿼리의 수가 많이 발생하며, 이제부터 그 문제를 해결해 보도록 하겠습니다.

 

 

 

 

 

 

 

 

 

 

 

 

🤔 N + 1 문제 해결

위 쿼리 18번

가장 먼저 해결해야 할 부분은, 총 18번의 쿼리가 발생하는 위 코드입니다.

 

이는 videoQueryDaoSupport.findAllByRestaurantIdIn()의 메서드의 결과로 조회된 18개의 비디오에 대하여, 이들을 순회하여 각각 이들과 연관된 음식점들을 조회할 때 발생합니다.

 

위 N + 1 문제를 해결하기 위해, Video를 조회하는 동시에 Restaurant도 조회하게 해야 합니다.

(혹은 id() 대신 getId()를 사용하게 할 수 있으나, getter에 대한 네이밍을 바꾸지 않고 해결할 것입니다.)

 

 

 

 

JPQL을 직접 작성하여 fetch join을 적용할 수도 있겠지만, 저는 @EntityGraph를 사용하였습니다.

 

 

 

 

@EntityGraph를 적용한 상태에서 다시 쿼리를 확인해보니, 쿼리가 하나도 줄어들지 않은 것을 확인했습니다.

 

 

 

원인을 살펴보니 위 부분에서 N+1 문제는 발생하지 않았지만, 이후 진행되는 코드 중 아래 코드에서 음식점을 조회하는 쿼리가 더 많이 발생한 것을 확인할 수 있었습니다.

이는 음식점 전체 조회 API 내부에서 조회(영속성 컨텍스트에 저장)되어야는 음식점의 개수는 동일하므로, 음식점을 조회하는 쿼리의 개수가 달라지지 않아 발생한 일입니다.

 

 

위 코드에도 @EntityGraph를 적용하여 N+1 문제를 해결해 보도록 하겠습니다.

 

 

 

 

이제 쿼리를 다시 확인해 보도록 하겠습니다.

쿼리가 매우 많이(좋아요의 개수 만큼) 감소한 것을 확인할 수 있었습니다.

 

그러나 아직도 쿼리는 19번이나 발생하는데요, 계속해서 해결해 보도록 하겠습니다.

 

 

 

 

 

해결해야 할 부분은 다음과 같습니다.

 

해당 쿼리 11번

원인은 조회된 영상(Video)과 연관된 셀럽(Celeb)들이 지연로딩 되기 때문이었습니다.

 

이는 비디오를 조회할 때 셀럽들도 함께 조회함으로써 해결할 수 있습니다.

저는 기존 @EntityGraph의 attributePaths에 celeb을 추가해 줌으로써 해결하였습니다.

 

 

최종적으로, 쿼리는 다음과 같이 개선되었습니다.

 

 

 

 

 

 

 

 

 

 

🤔 개선 결과

🐳 음식점 전체 조회 api

(해당 API의 기본 페이지 사이즈는 18개입니다.)

(비인증)

 

 

(인증)

 

 

 

 

 

🐳 음식점 상세 조회 api

(비인증)

 

 

 

(인증)

 

 

 

 

 

🐳 음식점의 주변 음식점 조회 api

(해당 API의 기본 페이지 사이즈는 4개입니다.)

(비인증)

 

 

(인증)

 

 

 

 

 

API	쿼리 개수		소요시간(단위: ms)
	개선전	개선후	개선전	개선후
음식점 전체 조회 (비인증)	36번	5번	1160ms	533ms
음식점 전체 조회 (인증)	137번	6번	2946ms	589ms
음식점 상세 조회 (비인증)	6번	5번	231ms	200ms
음식점 상세 조회 (인증)	7번	6번	235ms	200ms
음식점의 주변 음식점 조회 (비인증)	11번	5번	462ms	267ms
음식점의 주변 음식점 조회 (인증)	112번	6번	2328ms	298ms

 

어느정도의 비약(음식점 개수가 2만개라는)이 있었으나, 성능이 많이 좋아진 것을 확인할 수 있었습니다.