JPA N+1 문제 해결 강좌: Fetch Join & EntityGraph 이해하기

JPA N+1 문제 개요

JPA(Java Persistence API)는 자바 애플리케이션에서 관계형 데이터베이스를 사용하도록 지원하는 표준입니다. 하지만 JPA를 사용하면서 자주 마주하는 문제 중 하나가 바로 N+1 문제입니다.

N+1 문제란, 연관된 엔티티를 조회하는 과정에서 발생하는 성능 저하 문제입니다. 예를 들어, 한 명의 사용자와 그 사용자가 작성한 게시글 정보를 조회하는 경우를 생각해 봅시다. 우선 사용자 정보를 조회하는 쿼리 한 개와 사용자별 게시글을 조회하는 쿼리 N개가 필요하게 되어 총 N+1개의 쿼리가 실행되는 것입니다.

이처럼 불필요한 쿼리가 많이 실행되면 데이터베이스의 성능이 저하되고, 애플리케이션의 처리 속도가 느려질 수 있습니다. 따라서 이러한 N+1 문제를 효과적으로 해결하는 것이 중요합니다.

JPA N+1 문제의 원인

JPA N+1 문제는 대부분 지연 로딩(Lazy Loading)과 관련이 있습니다. 지연 로딩은 연관된 엔티티가 실제로 사용되는 시점에서 조회하는 JPA의 로딩 전략으로, 필요한 데이터만 로딩한다는 장점이 있으나 N+1 문제가 발생할 가능성이 높아집니다.

지연 로딩 전략에 따르면, 첫 번째 쿼리로 부모 엔티티를 조회한 후, 개별 자식 엔티티를 조회하기 위해 추가 쿼리를 실행하게 됩니다. 부모-자식 관계가 N개 존재할 경우 N+1 개의 쿼리가 실행되어 성능 문제가 발생하는 것입니다.

이러한 N+1 문제를 예방하고자 즉시 로딩(Eager Loading)을 사용하면 다른 문제가 발생할 수 있습니다. 즉시 로딩은 연관된 모든 엔티티를 미리 조회하는 로딩 전략으로, 항상 모든 관련 데이터를 로딩하기 때문에 데이터 전송량이 불필요하게 커질 수 있습니다.

따라서 적절한 방법으로 N+1 문제를 해결해야 합니다. 다음 장에서는 Fetch Join과 EntityGraph를 이용한 해결 방안을 소개합니다.

해결 방법 1: Fetch Join 사용하기

Fetch Join은 JPQL(Java Persistence Query Language)의 JOIN 키워드를 사용하여 엔티티를 조회할 때 연관된 엔티티도 함께 조회하는 방법입니다. 이 방법은 부모 엔티티를 조회하는 쿼리에 자식 엔티티를 join하므로 한 번의 쿼리로 필요한 데이터를 모두 조회할 수 있습니다.

Fetch Join은 다음과 같이 JPQL에서 'fetch' 키워드를 사용하여 구현할 수 있습니다.

// 기존 쿼리
String jpql = "select u from User u";
// Fetch Join 적용한 쿼리
String fetchJoinJpql = "select u from User u join fetch u.posts";

Fetch Join을 사용하면 쿼리 수를 줄일 수 있으나, 조인된 결과에 중복 데이터가 많을 수 있습니다. 이를 해결하기 위해선 JPQL의 'distinct' 키워드를 사용하여 중복 결과를 제거할 수 있습니다.

String distinctFetchJoinJpql = "select distinct u from User u join fetch u.posts";

Fetch Join을 사용하면 한 번의 쿼리로 필요한 데이터를 조회하여 N+1 문제를 해결할 수 있습니다. 하지만, 대용량 데이터에 대해서는 조심스럽게 사용해야 합니다. 이 경우에는 다음 장에서 설명하는 EntityGraph를 고려해볼 수 있습니다.

해결 방법 2: EntityGraph 사용하기

EntityGraph는 JPA 2.1 버전부터 도입된 특성으로, 연관된 엔티티를 동적으로 불러올 수 있게 해주는 기능입니다. EntityGraph를 사용하면 데이터 조회 시점에 로딩 전략을 지정할 수 있어, N+1 문제와 데이터 전송량 문제를 효과적으로 해결할 수 있습니다.

EntityGraph는 Named Entity Graph와 Dynamic Entity Graph 두 가지 방법으로 적용할 수 있습니다. Named Entity Graph는 엔티티 클래스에 @NamedEntityGraph 어노테이션을 사용하여 정의하며, Dynamic Entity Graph는 동적으로 API를 통해 생성할 수 있습니다.

먼저, Named Entity Graph를 사용하는 방법을 살펴봅시다. 다음 예제에서는 User 엔티티와 연관된 Post 엔티티를 함께 조회하는 EntityGraph를 생성합니다.

@Entity
@NamedEntityGraph(name = "User.posts", attributeNodes = @NamedAttributeNode("posts"))
public class User {
    // ... 생략 ...
}

위에서 정의한 Named Entity Graph를 사용하여 조회하려면 다음과 같이 질의에 적용할 수 있습니다.

EntityGraph<User> entityGraph = em.createEntityGraph(User.class);
entityGraph.addAttributeNodes("posts");
List<User> users = em.createQuery("select u from User u", User.class)
    .setHint("javax.persistence.fetchgraph", entityGraph)
    .getResultList();

Dynamic Entity Graph는 엔티티 클래스에 어노테이션을 사용하지 않고 동적으로 생성하는 방법입니다. 구현 방법은 다음과 같습니다.

EntityGraph<User> entityGraph = em.createEntityGraph(User.class);
entityGraph.addAttributeNodes("posts");
List<User> users = em.createQuery("select u from User u", User.class)
    .setHint("javax.persistence.loadgraph", entityGraph)
    .getResultList();

EntityGraph를 사용하면 Fetch Join과 달리 중복 데이터를 줄이고 실행될 쿼리 수를 줄여서 N+1 문제를 해결할 수 있습니다. 이를 통해 조회 성능을 향상시킬 수 있습니다.

결론과 총정리

JPA를 사용하면서 N+1 문제는 많은 개발자들이 직면하는 성능 저하의 주요 원인 중 하나입니다. 이러한 N+1 문제를 해결하기 위해 다양한 방법을 사용할 수 있습니다.

Fetch Join은 JPQL에서 연관된 엔티티를 함께 조회하여 성능 저하를 방지할 수 있는 방법입니다. 이 방법은 한 번의 쿼리로 필요한 데이터를 조회할 수 있으나, 조인된 결과에 중복 데이터가 많을 수 있습니다. 그렇기 때문에 대용량 데이터에 대해서는 조심스럽게 사용해야 합니다.

EntityGraph는 JPA 2.1 버전부터 도입된 기능으로, 연관된 엔티티를 동적으로 불러올 수 있습니다. 이 방법은 데이터 조회 시점에 로딩 전략을 지정할 수 있어, N+1 문제와 데이터 전송량 문제를 동시에 해결할 수 있습니다. 또한 EntityGraph는 Named Entity Graph와 Dynamic Entity Graph 두 가지 방법으로 적용할 수 있습니다.

위에서 소개한 방법을 적절하게 사용하여 JPA N+1 문제를 해결함으로써 데이터베이스 성능을 향상시키고 애플리케이션의 처리 속도를 개선할 수 있습니다. 상황에 맞게 적절한 방법을 선택하여 최적의 성능을 달성하는 것이 중요합니다.