[Anifriends] JPA N+1 문제 개선기

🚀  개요

데브코스 4기에서 봉사 플랫폼인 Anifriends 을 개발하면서 조회 서비스에서 N+1 문제가 발생하였다. N+1 문제란 무엇이고 해결 방안은 어떤 것들이 있는지 학습해 보며 적용해 보자.

📖 N+1 문제란?

JPA 의 연관 관계가 설정된 엔티티를 조회할 경우 해당 엔티티와 연관 관계를 갖는 엔티티를 조회하기 위해 N 개의 추가적인 쿼리가 발생하는 문제이다. 즉, 1번의 쿼리를 날렸을 때 N 개의 추가 쿼리가 발생하는 문제이다. 이는 의도치 않은 쿼리를 발생시켜 어플리케이션의 성능 저하로 이어질 수 있다.

✅ N+1 문제 개선하기

내가 맡은 부분은 보호 동물 조회이다. 보호 동물 관련 ERD 는 다음과 같다.

• 보호 동물 & 보호 동물 이미지 : oneToMany
• 보호동물 & 보호소 : manyToOne
• 보호소 & 보호소 이미지 : OneToOne

보호 동물 단일 조회, 보호소의 보호 동물 목록 조회, 봉사자의 보호 동물 목록 조회에서 N+1 문제가 발생하였다. 하나씩 개선해 보자.

보호 동물 단일 조회

보호 동물과 보호 동물 이미지는 oneToMany 연관 관계를 갖는다.

@Entity
public class Animal {
    ...
    @OneToMany(mappedBy = "animal", fetch = FetchType.LAZY, ...)
    private List<AnimalImage> images = new ArrayList<>();
}

보호 동물을 단일 조회할 경우 다음과 같은 쿼리가 발생한다.

Hibernate: 
    select
        a1_0.animal_id,
        ...
    from
        animal a1_0 
    where
        a1_0.animal_id=?
Hibernate: 
    select
        i1_0.animal_id,
        i1_0.animal_image_id,
        ...
    from
        animal_image i1_0 
    where
        i1_0.animal_id=?

1. animal 을 단일 조회하는 쿼리 1번
2. animal_image 목록을 조회하는 쿼리 1번

fetch join 을 사용해서 개선해 보자.

📖 fetch join 이란?

연관 관계를 갖는 엔티티나 컬렉션을 join 하여 한 번에 불러오는 방법이다. JPQL 에서 성능 최적화를 위해 제공하는 join 으로 일반 SQL join 과는 다르다.(SQL join 은 연관된 엔티티를 함께 조회해오진 않는다.)

@Query("select a from Animal a "
        + "join fetch a.images "
        + "where a.animalId = :animalId")
Optional<Animal> findByAnimalIdWithImages(@Param("animalId") Long animalId);

이제 다시 조회 로직을 실행하면 다음과 같이 한 번의 쿼리로 보호 동물의 정보를 가져오게 된다.

Hibernate: 
select
    a1_0.animal_id,
    ...
from
    animal a1_0 
join
    animal_image i1_0 
        on a1_0.animal_id=i1_0.animal_id 
where
    a1_0.animal_id=?

보호소의 보호 동물 목록 조회

보호소는 자신이 등록한 보호 동물 목록만 조회할 수 있으며 보호 동물 목록 조회 시 다음과 같이 쿼리가 발생한다.

Hibernate: 
    select
        a1_0.animal_id,
        ...
    from
        animal a1_0 
    where
        a1_0.shelter_id=?
    order by
        a1_0.created_at desc
    offset
        ? rows
    fetch
        first ? rows only
Hibernate: 
    select
        i1_0.animal_id,
        i1_0.animal_image_id,
        ...
    from
        animal_image i1_0 
    where
        i1_0.animal_id=?
Hibernate: 
    select
        i1_0.animal_id,
        i1_0.animal_image_id,
        ...
    from
        animal_image i1_0 
    where
        i1_0.animal_id=?
Hibernate: 
    select
        i1_0.animal_id,
        i1_0.animal_image_id,
        ...
    from
        animal_image i1_0 
    where
        i1_0.animal_id=?
....

1. shelter_id 에 해당하는 animal 목록을 조회하는 쿼리 1번
2. 각 animal_id 에 해당하는 animal_image 목록을 조회하는 쿼리 N번

총 N + 1번의 쿼리가 발생한다. 상세 조회와 마찬가지로 fetch join 을 사용해서 개선해 보자.

List<Animal> animals = query.select(animal)
    .from(animal)
    .join(animal.images).fetchJoin()
    .where(
        animal.shelter.shelterId.eq(shelterId),
        ...
    )
    .orderBy(animal.createdAt.desc())
    .limit(pageable.getPageSize())
    .offset(paeable.getOffset())
    .fetch();

이제 다시 보호 동물 목록을 조회해 보자.

Hibernate: 
select
    a1_0.animal_id,
    ...
from
    animal a1_0 
join
    animal_image i1_0 
        on a1_0.animal_id=i1_0.animal_id 
where
    a1_0.shelter_id=?
order by
    a1_0.created_at desc

엥? offset 과 limit 이 전혀 동작하지 않고 있다. 또한 다음과 같이 하이버네이트 WARN 이 발생한다.

db 에 저장되어 있는 모든 데이터를 메모리상으로 가져와서 하이버네이트가 경고를 준 것이다. offset 과 limit 이 동작하지 않는 이유는 무엇일까?

oneToMany 관계에서 fetch join 을 하게 되면 Many 의 개수만큼 데이터를 가져온다. 개발자가 원하는 페이징의 기준은 Many 가 아닌 One 이다. 즉, 보호 동물 이미지가 아닌 보호 동물이 기준이 되어야 한다.

Hibernate 는 oneToMany 관계에서 fetch join 을 할 경우 모든 데이터를 db 에서 조회하여 메모리에 모든 데이터를 올려두고 페이징 처리를 하고 WARN 로그를 남기는 방법을 선택했다. 이 경우 위험한 상황이 발생할 수 있다. 만약 보호 동물이 100만개 또는 그 이상이 db 에 저장되어 있다면 페이징처리를 하지 않고 모든 데이터를 메모리에 올리게 되므로 지연시간 증가는 물론 메모리 부족으로 인해 OutOfMemoryError 가 발생할 위험이 있다.

그렇다면 또 다른 방법인 BatchSize 를 설정해 보자.

📖 BatchSize 란?

연관 관계를 갖는 엔티티나 컬렉션을 조회할 때 BatchSize 만큼 where in 절을 사용하여 조회해 오는 방식이다.

@OneToMany(mappedBy = "animal", fetch = FetchType.LAZY, ... )
@BatchSize(size = 100)
private List<AnimalImage> images = new ArrayList<>();

 변경되는 쿼리는 다음과 같다. 

Hibernate: 
    select
        a1_0.animal_id,
        ...
    from
        animal a1_0
    where
        a1_0.shelter_id=?
    order by
        a1_0.created_at desc
    offset
        ? rows
    fetch
        first ? row only
Hibernate: 
    select 
        i1_0.animal_id,
        i1_0.animal_image_id,
        ...
    from
        animal_image i1_0
    where
        i1_0.animal_id in (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)

animal_image 를 join 해오는 것이 아닌 설정한 BatchSize 만큼 where in 문을 통해 가져오게 된다.

봉사자의 보호 동물 목록 조회

보호 동물과 보호소는 manyToOne 연관관계를 갖으며, 보호소와 보호소 이미지는 oneToOne 연관관계를 갖는다.

@Entity
public class Animal {
    ...
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "shelter_id")
    private Shelter shelter;
}

@Entity
public class Shelter {
    ...
    @OneToOne(mappedBy = "shelter", fetch = FetchType.LAZY, ...)
    private ShelterImage image;
}

봉사자는 등록된 모든 보호 동물 목록을 조회할 수 있으며 발생되는 쿼리는 다음과 같다.

Hibernate: 
    select
        a1_0.animal_id,
        ...
    from
        animal a1_0
    where
        a1_0.shelter_id=?
    order by
        a1_0.created_at desc
    offset
        ? rows
    fetch
        first ? row only
Hibernate: 
     select
         s1_0.shelter_id,
         ...
    from
        shelter s1_0
    where 
        s1_0.shelter_id=?
Hibernate: 
    select
        s1_0.shelter_image_id,
    ...
    from
        shelter_image s1_0
    where
        s1_0.shelter_id=?
...
Hibernate:
    select
        i1_0.animal_id,
        i1_0.animal_image_id,
        ...
    from
        animal_image i1_0
    where
        i1_0.animal_id=?
...

1. animal 목록을 조회하는 쿼리 1번
2. 각 animal 의 animal_image 목록을 조회하는 쿼리 N번
3. 각 animal 의 shelter 를 조회하는 쿼리 N 번
4. 각 shelter 의 shelter_image 목록을 조회하는 쿼리 N번

총 N + N + N + 1번의 쿼리가 발생한다.

개선하기에 앞서 한 가지 의문점이 있다. shelter_image 는 어디에서도 접근하고 있지 않은데 fetchType 이 LAZY 임에도 불구하고 즉시 로딩이 되고 있는 이유는 무엇일까?

그 이유는 JPA 에서의 지연 로딩은 프록시로 동작하기 때문이다.

db 상에서 FK 는 shelter_image 가 갖고 있다. 만약 연관관계 주인인 shelter_image를 조회한다면 shelter 는 프록시로 저장될 것이다. 하지만, shelter 를 조회한다면 shelter 는 shelter_image_id 를 갖고 있지 않기 때문에 존재하지 않은 것을 프록시로 감쌀 수 없으므로 즉시 로딩을 하게 된다.

즉, oneToOne 연관관계에서 연관관계 주인이 아닌 곳에서 조회를 할 경우 FK 를 갖고 있지 않으므로 즉시로딩으로 동작하게 되는 것이다.

또 한 가지 문제는 봉사자의 보호동물 조회 로직의 경우 필요한 데이터는 animal_id, animal_name, animal_imageUrl, created_at, shelter_name, shelter_address 총 6개인데 30개 이상의 데이터를 가져오고 있다. 불필요한 데이터를 가져오는 것은 성능 저하를 일으킬 수 있다. dto projection 을 사용하여 필요한 데이터를 가져오자.

📖 dto projection 이란?

select 절에 대상을 지정하여 원하는 값만 조회해 오는 것을 의미한다. dto projection 을 사용하면 불필요한 데이터를 조회하지 않고 필요한 데이터만 조회해 올 수 있다.

@Getter
public class FindAnimalsResult {

    private final Long animalId;
    private final String animalName;
    private final LocalDateTime createdAt;
    private final String shelterName;
    private final String shelterAddress;
    private final String animalImageUrl;

    @QueryProjection
    public FindAnimalsResult(
        Long animalId,
        String animalName,
        LocalDateTime createdAt,
        String shelterName,
        String shelterAddress,
        String animalImageUrl
    ) {
        this.animalId = animalId;
        this.animalName = animalName;
        this.createdAt = createdAt;
        this.shelterName = shelterName;
        this.shelterAddress = shelterAddress;
        this.animalImageUrl = animalImageUrl;
    }
}

List<FindAnimalsResult> animals = query.select(new QFindAnimalsResult(
        animal.animalId,
        animal.name.name,
        animal.createdAt,
        animal.shelter.name.name,
        animal.shelter.addressInfo.address,
        ExpressionUtils.as(
            select(animalImage.imageUrl)
                .from(animalImage)
                .where(animalImage.animalImageId.eq(
                    select(animalImage.animalImageId.min())
                        .from(animalImage)
                        .where(animalImage.animal.eq(animal)
                        ))), "animalImageUrl")
    ))
    ...

이제 한 번의 쿼리로 필요한 필드만 선택해서 가져올 수 있게 되었다.

Hibernate: 
    select
        a1_0.animal_id,
        a1_0.name,
        a1_0.created_at,
        s1_0.name,
        s1_0.address,
        (select
            a2_0.image_url 
        from
            animal_image a2_0 
        where
            a2_0.animal_image_id=(
                select
                    min(a3_0.animal_image_id) 
                from
                    animal_image a3_0 
                where
                    a3_0.animal_id=a1_0.animal_id
            )
        ) 
    from
        animal a1_0 
    join
        shelter s1_0 
            on s1_0.shelter_id=a1_0.shelter_id 
    ...

postman 으로 응답 시간을 테스트해 보니 모든 쿼리를 가져올 경우 1.5초, 필요한 데이터만 가져올 경우 0.13초로 지연 시간이 약 1/10으로 감소된 것을 확인할 수 있었다.

🔚 결론

N+1 문제를 해결하는 방법에는 여러가지가 있고 상황마다 적절한 해결책이 존재한다.

fetch join

• toOne 연관관계일 경우
• toMany 연관관계의 단일 조회일 경우

BatchSize

• toMany 연관관계의 멀티 조회이며 페이지네이션이 필요한 경우
• toMany 연관관계에서 컬렉션이 두 개 이상 존재하는 경우

dto Projection

• 실제 사용하는 컬럼보다 불러오는 컬럼이 훨씬 많아 성능 개선이 필요한 경우
• 영속성 컨텍스트의 관리가 필요 없는 경우