[스프링] JPA N+1 문제 트러블 슈팅

실제 프로젝트를 진행하면서 만났던 N+1 문제를 해결하는 과정을 중심으로 작성해 보았습니다.

✅ N+1 문제란?

: 요청이 1개의 쿼리로 처리되길 기대했는데 추가로 N개의 쿼리가 발생하는 현상

 

개념은 정말 간단합니다.

N개의 데이터를 한 번에 조회하는 쿼리 1개를 날렸는데, 추가적으로 N개의 쿼리가 더 발생하는 현상입니다.

(사실 흐름상 1+N 문제라고 하는 것이 더 적절합니다)

 

이제 실제 프로젝트 상황을 중심으로 `N+1` 문제가 언제, 어떤 상황에서 발생하는지 알아보겠습니다.

 

---

✅ 프로젝트 상황

📍 ERD

"프로젝트 팀원을 모집하는 기능"을 구현하기 위해 아래와 같이 `ERD`를 설계했습니다.

프로젝트 팀원 모집 관련 ERD

 

팀원 모집 게시물에는 선호하는 성격, 모집하는 분야, 모집하는 언어를 여러 개 설정할 수 있습니다.

따라서 각각 1:N의 관계로 연결하였습니다.

• 팀원 모집 게시물: 선호 성격 = `1:N`
• 팀원 모집 게시물: 분야 = `1:N`
• 팀원 모집 게시물: 언어 = `1:N`

 

📍 Entity

위 ERD에 따라 팀원 모집 게시물(RecruitPost) 엔티티는 다음과 같이 구현했습니다.

RecruitPost Entity

로직 구현 과정에서 `RecruitPost` -> `RecruitField`, `RecruitLanguage`, `RecruitPersonality` 방향이 자주 필요하다고 생각되어 양방향으로 설정했습니다.

 

그리고 각각의 관계는 지연 로딩(`FetchType.LAZY`)으로 설정되어 있는 상태입니다.

지연 로딩: 연관된 엔티티를 처음에는 조회하지 않고, 실제로 해당 엔티티가 필요한 시점에 조회하는 방식

 

📍 Service & Repository

`N+1` 문제가 발생한 비즈니스 로직은 다음과 같습니다.

사용자에게 적절한 팀원 모집 게시물을 추천해 주는 로직입니다.

 

먼저 JpaRepository의  `findAllByIsCompleteAndUserIdNot(false, user)`를 통해

특정 조건을 만족하는 모든 팀원 모집 게시물 리스트를 조회해오고 있습니다.

 

그리고 `calculatePriorities()`에서 이 결과 리스트를 순회하며 연관된 엔티티들(언어, 관심분야, 성격)을 `get`하고 있습니다.

---

✅ 트러블 슈팅

📍 로직 실행 결과

위 로직을 실행하면, 찍히는 쿼리 결과는 아래와 같습니다.

여기서 `N`은 현재 DB에 들어있는 팀원 모집 게시물 RecruitPost의 개수입니다.

 

`RecruitPost` 리스트를 조회하는 쿼리 1번 + 리스트를 순회하면서 각 `RecruitPost`와 연관된 언어, 분야, 성격을 조회하는 쿼리 N번

= `1+N`

= `N+1`

 

제가 JpaRepository의 함수를 호출한 것은 1번임에도, 추가로 N번의 쿼리가 더 발생한 것을 알 수 있습니다.

그리고 이 상황이 바로 N+1 문제입니다.

 

📍 N+1 문제 발생

 

비즈니스 로직의 어떤 부분에서 이 쿼리들이 발생했는지 살펴보면 위와 같습니다.

현재 `RecruitPost`와 연관된 엔티티가 3개(언어, 분야, 성격)이기 때문에 정확하게는 `1+3N`번의 쿼리가 발생한 것입니다.

 

📍원인 분석

JPQL: 엔티티 객체를 조회하는 객체지향 쿼리

 

Spring Data Jpa에서는 메서드의 이름을 분석해서 `JPQL`을 생성하여 실행합니다.

아래 메서드명을 통해 WHERE 조건절을 만들고, `FROM RecruitPost`로 게시물을 가져올 것입니다.

기존 메서드

 

그런데, 이전에 봤던 `RecruitPost` 클래스 안에는 `RecruitField`, `RecruitLanguage`, `RecruitPersonality`의 리스트가 양방향으로 선언되어 있습니다.

 

그럼 이 리스트들도 위 메서드를 실행하면 같이 조회해 올까요?

 

 

위 리스트들은 RecruitPost 리스트를 조회해 올 때 함께 실제 DB에서 조회해오지 않습니다. 

 

왜냐하면 "지연 로딩"으로 설정되어 있기 때문인데요!

 지연 로딩을 사용하면 RecruitPost를 조회할 때는 리스트들이 프록시 객체로 존재하게 됩니다. 

이후 해당 리스트에 접근하기 위해 post.getXXX() 메서드를 호출하면, 그 시점에 실제 객체를 조회하기 위한 쿼리가 실행됩니다. 

 

---

✅ 해결 과정

이제 험난했던 해결 과정입니다.

과거 김영한 님 강의에서 N+1 문제에 대해 학습한 경험이 있기에, 금방 해결될 줄 알았지만 그렇지 않았습니다..

 

📍 JPQL의 FETCH JOIN 사용 & @EntityGraph 사용

`FETCH JOIN`을 사용하면 한 번의 쿼리로 연관된 엔티티를 같이 조회할 수 있습니다.

그래서 아래와 같이 관련된 3개의 엔티티에 모두 `FETCH JOIN`을 사용해서 한 번의 쿼리로 같이 조회해오려 했습니다.

 

(변경) Fetch Join 사용

 

그러나, 실행해 보니  "Hibernate MultipleBagFetchException"이 발생했습니다.

 

처음에는 `JPQL`의 `FETCH JOIN`에서만 발생하는 예외인가? 생각하고 `@EntityGraph`로 방식을 변경해 보았습니다.

(변경) Entity Graph 사용

 

`@EntityGraph`를 사용하면 지연 로딩으로 설정된 연관관계 엔티티들을 한 번에 (Left Join으로) 조회해 옵니다.

마찬가지로 "Hibernate MultipleBagFetchException"이 발생했습니다.

 

 

📍 MultipleBagFetchException

: 2개 이상의 `OneToMany` 자식 테이블에 `FETCH JOIN`했을 때 발생하는 예외

 

제가 OneToMany 관계를 모두 List로 선언해 두었는데, Hibernate는 이를 `Bag`로 취급합니다.

 

두 개 이상의 `Bag`를 함께 `Fetch Join`하면, 중복 데이터가 발생할 가능성이 있습니다.

그리고 Hibernate는 이 중복 데이터를 어떻게 처리할지 결정할 수가 없기 때문에, MultipleBagFetchException을 발생시키는 것입니다.

 

즉, 2개 이상의 `@OneToMany` 관계에서는 fetch join을 사용하면 발생하는 문제입니다!

 

이 예외를 해결하는 방법으로는 2가지를 찾을 수 있었습니다.

(1) List를 Set으로 변경

(2) fetch size 설정

 

 

📍 MultipleBagFetchException 해결: List -> Set 변경

`List`는 중복의 가능성이 있었지만, `Set`은 중복 데이터 발생하지 않습니다.

따라서 중복 데이터를 어떻게 처리할지 고민하지 않아도 되므로 에러가 발생하지 않습니다.

 

다음과 같이 `RecruitPost` 엔티티 내부에서 모두 `Set`으로 변경했습니다.

List -> Set 변경

 

 

그리고 실행해 보면 다음과 같이 쿼리가 찍힙니다.

Fetch Join 결과

 

쿼리 결과를 통해 `Fetch Join`하여 한 번의 쿼리로 연관된 엔티티 모두 조회해 오는 것을 볼 수 있습니다.

 

하지만 Set으로 변경함에 따라 이미 작성해 둔 로직에서 여러 부분을 수정해야 하는 상황이 발생했습니다. 

 

📍 MultipleBagFetchException 해결:  batch size 설정

batch size: 연관된 엔티티를 몇 개씩 가져올지 설정 (IN절에 들어갈 값 개수를 설정)

 

batch size를 적용하면, WHERE절이 같은 여러 개의 SELECT 쿼리들을 하나의 IN 쿼리로 만들어줍니다.

 

여기서 어려운 점은 batch size는 상황에 적절하게 설정해야 한다는 것입니다.

보통 100~1000으로 설정하는 것이 일반적이라고 보긴 했습니다.

 

하지만, 더 찾아보니 batch size 캐싱 케이스 최적화로 인해 (batch size!= IN절에 들어간 값 개수)라고 합니다.

이 부분은 추후에 더 찾아서 따로 공부해야겠습니다.

 

batch size를 설정하는 방법에는 두 가지가 있습니다.

 

1. 프로젝트 전역에 배치 사이즈 적용

application.yml에 추가

2. 각각 배치 사이즈 적용

RecruitPost 수정

 

---

✅ 해결방법 정리

📍 OneToMany 관계가 하나일 때

1. JPQL Fetch Join

2. @EntityGraph

3. Querydsl Fetch Join (Querydsl에서도 `fetchJoin()`을 이용할 수 있습니다)

=> 하지만, 연관된 것이  2개 이상이면 위 3 방식 모두 MultipleBagFetchException 발생

 

📍 OneToMany 관계가 2개 이상일 때

1. List -> Set 변경

2. Batch Size 설정

📍 개인적 결론

• Fetch Join의 문제점: 페이징이 안 되고, OneToMany관계에서는 데이터가 카테시안 곱만큼 늘어나서 조회된다
• 따라서 OneToMany 관계에서의 N+1 문제에서는 연관관계가 한 개이든 두 개이든 페이징이 가능하고 최소 성능을 보장해 주는 batch size를 사용하자

 

카테시안 곱 (Cartesian Product): N개의 행을 가진 테이블과 M개의 행을 가진 테이블을 Join 하면, N*M개의 결괏값이 반환되는 것