[Spring] JPA 쿼리 DTO 조회 쿼리 최적화

0. 들어가며

DB와의 통신 과정에서 부하를 줄이는 방법으로 인덱스, 지연로딩, 캐싱 등 여러 방법을 활용해볼 수 있다.

 

오늘은 기존에 잘 생각해보지 못했던 엔티티 조회 방법을 말해보려고 한다.

 

평소에 JPA를 이용해서 엔티티를 조회하고 클라이언트 요청에 응답할 때, 보통의 경우에는 다음과 같이 사용했었다.

 

public interface UserRepository extends JpaRepository<User, Long> {

    Optional<User> findById(Long id);
    
}

@Builder
@Getter
public class UserResponseDto {

    Long id;
    String email;
    String name;

    public static UserResponseDto from(User user) {
        return UserResponseDto.builder()
                .id(user.getId())
                .name(user.getName())
                .email(user.getEmail())
                .build();
    }

}

 

필요한 Entity를 먼저 전체로 조회하고, 필요한 DTO로 변환하는 방식으로 사용했다.

 

public UserResponseDto getUser(Long id) {
    User user = userRepository.findById(id).orElseThrow();
    return UserResponseDto.from(user);
}

 

무분별한 Entity 전체 조회는 곧 성능저하로 이어질 수 있다.

 

실제로 인프런에서 비슷한 방식의 슬로우 쿼리로 인해 서비스 장애가 이어진 적이 있었다.

 

https://tech.inflab.com/202201-event-postmortem/

 

 

실제로 사용하지 않던 대용량 컬럼을 제거하면서 슬로우 쿼리를 해결했다.

 

 

1. 전체 컬럼 조회 vs 특정 컬럼 조회

 

1-1. 비용 계산

 

만약 Post 테이블이 여러 컬럼을 갖고 있다고 가정할 때,

SELECT * FROM post WHERE id >=1 AND id <=100;

SELECT title, summary, created_at FROM post WHERE id >=1 AND id <=100;

 

두 쿼리중 어떤 쿼리가 비용이 적게 들까?

 

쿼리의 비용을 계산해주는 MySQL explain을 사용해보면, 

 

전체 컬럼 조회

 

특정 컬럼 조회

 

놀랍게도 두 쿼리의 총 비용(cost)은 10.3으로 같다.

 

그 이유는 MySQL 데이터 저장 방식에 있는데,

 

https://blog.ex-em.com/1699

 

MySQL은 데이터를 페이지 단위로 저장한다.

 

따라서 특정 행을 읽을 때는, 몇 개의 컬럼을 읽든 상관없이 페이지 전체를 메모리로 가져와야 한다.

 

MySQL Explain의 비용 계산 식은 다음과 같다.

cost = (데이터 페이지 수 × 페이지 읽기 비용) + (행 수 × 행 처리 비용)

 

두 쿼리 모두 같은 수의 페이지를 읽기 때문에, 결국 비용 계산 결과가 같게 나온다.

 

그렇다면 비용이 같으니까, DB 입장에선 차이가 없는게 아닌가?

 

1-2. 실행 시간

비록 비용은 같을 수 있지만, 실제 실행 시간은 다를 수 있다.

 

전체 조회는 특정 컬럼 조회보다 클라이언트에게 더 많은 데이터를 전송해야 하므로, 네트워크 대역폭을 더 많이 사용하게 된다.

 

실제 데이터 전송량을 프로파일링을 이용해서 비교해 보겠다.

# 프로파일링 활성화
SET profiling = 1;

# 전체 컬럼 조회
SELECT * FROM post WHERE id >=1 AND id <=100;

# 특정 컬럼만 조회
SELECT title, summary, created_at FROM post WHERE id >=1 AND id <=100;

# 프로파일링 결과 확인
SHOW PROFILES;

전체 컬럼 조회

 

특정 컬럼 조회

 

전체 컬럼 : 0.001626

특정 컬럼 : 0.000568

 

미묘하지만 분명히 차이가 있고, 이는 반환 컬럼이 많아질수록 차이가 분명해질 것이다.

 

또한 네트워크 사용량 이외에도, 데이터가 애플리케이션으로 넘어와서 (ORM을 사용할 경우) 객체에 매핑하는 시간이 증가하고,

 

더 많은 데이터를 저장하고 처리해야 하므로 메모리 사용량이 증가한다.

 

2. JPA와 DTO 반환

그렇다면, JPA에서 어떻게 데이터를 원하는 DTO로 반환받을 수 있을까?

 

다음과 같은 Post 엔티티를 가지고 있다고 가정해 보겠다.

 

@Entity
@Getter
@Builder
@AllArgsConstructor
@NoArgsConstructor
@Table(name = "post")
public class Post {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String title;

    @Column(length = 10000)
    private String content;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "user_id")
    private User user;

    @Column(length = 1000)
    private String summary;

    private LocalDateTime createdAt;

    @Column(length = 500)
    private String tags;

    private int viewCount;

    @Column(length = 2000)
    private String metaDescription;

    private String category;
    private boolean isPublished;
    private LocalDateTime lastModifiedAt;
    private String thumbnailUrl;
}

 

예를 들어, 게시글 미리보기에선 모든 정보가 필요하진 않다.

 

나는 여기서 게시글 미리보기에 필요한 데이터를 아래와 같이 추출하려고 한다.

 

@Getter
@AllArgsConstructor
public class PostResponseDto {

    public Long id;
    public String title;
    public String summary;

}

 

 

가장 일차적인 방법으로 직접 쿼리를 작성해서 다음과 같이 사용할 수 있겠다.

 

public interface PostRepository extends JpaRepository<Post, Long> {

    @Query("SELECT new com.example.testproject.PostResponseDto(p.id, p.title, p.summary) FROM Post p")
    List<PostResponseDto> findAllBy();

}

 

public List<PostResponseDto> getPosts() {
    return postRepository.findAllBy();
}

 

이렇게 구성해두면 필요한 컬럼만 조회하는 쿼리가 실행되게 된다.

기존 실행 쿼리

 

개선 후 쿼리

 

 

하지만 여기서 더 간편한 방법이 있는데, 바로 JPA의 변환 기능을 활용하는 것이다.

 

여기서 Repository 메서드만 다음과 같이 바꾸고 실행해보겠다.

 

public interface PostRepository extends JpaRepository<Post, Long> {

    List<PostResponseDto> findAllBy();

}

 

실행된 쿼리

 

필요한 컬럼을 명시해주지 않았는데도, 전과 같이 필요한 컬럼만 골라서 쿼리를 실행하는 것을 볼 수 있다.

 

이는 JPA 내부에서 리턴 타입(클래스)을 분석하고 결과적으로 위에서 직접 작성한 쿼리를 작성해주기 때문이다.

 

같은 방식으로 단건 조회도 사용할 수 있다.

 

public interface UserRepository extends JpaRepository<User, Long> {
    
    UserResponseDto findDtoById(Long id);

}

 

주의사항

1. 이를 위해서 반드시 생성자를 명시해 두어야 한다.(@AllArgsConstructor)
그렇지 않으면 JPA에서 다음과 같은 예외를 던질 것이다.
org.hibernate.query.QueryTypeMismatchException: Specified result type [com.example.testproject.UserResponseDto] did not match Query selection type [com.example.testproject.User] - multiple selections: use Tuple or array

2. DTO의 필드명과 컬럼명이 일치해야 한다.

3. JPA가 제공하는 기본 쿼리 메서드들의 리턴 타입은 엔티티이기 때문에,
기본 메서드를 사용하지 않고 다른 이름을 사용해야 충돌을 피할 수 있다.

 

 

3. 작동방식

그렇다면, DTO로 반환되는 과정이 어떻게 이루어지는걸까?

 

Spring Data JPA 버전 3.2.4 기준

 

3-1. 쿼리 생성

 

먼저 PostRepository의 메서드가 호출되면, Spring Data JPA의 QueryExecutorMethodInterceptor 클래스가 이를 가로챈다.

 

해당 클래스는 메서드 호출을 분석하고 적절한 쿼리를 생성하는 역할을 한다.

org.springframework.data.repository.core.support.QueryExecutorMethodInterceptor

 

이 과정에서 JpaQueryMethod를 통해 메서드 반환 타입을 사용한다.

 

org.springframework.data.jpa.repository.query.AbstractStringBasedJpaQuery

protected Query createJpaQuery(String queryString, Sort sort, @Nullable Pageable pageable,
        ReturnedType returnedType) {

    EntityManager em = getEntityManager();

	//생성자가 있는지 검사
    if (this.query.hasConstructorExpression() || this.query.isDefaultProjection()) {
        return em.createQuery(potentiallyRewriteQuery(queryString, sort, pageable));
    }

	//읽어야 하는 클래스(return type)을 가져옴
    Class<?> typeToRead = getTypeToRead(returnedType);

    return typeToRead == null
            ? em.createQuery(potentiallyRewriteQuery(queryString, sort, pageable))
            : em.createQuery(potentiallyRewriteQuery(queryString, sort, pageable), typeToRead); //->return type과 같이 쿼리를 생성
}

 

typeToRead(리턴 타입)을 가져오고, EntityManager에 같이 반환 타입을 넘기며 쿼리를 생성하게 된다.

 

3-2. 실행 후 변환

JpaQueryExecution내에서 쿼리가 실행된 뒤에, requiredType과 비교하여 변환을 시도한다.

 

org.springframework.data.jpa.repository.query.JpaQueryExecution

@Nullable
public Object execute(AbstractJpaQuery query, JpaParametersParameterAccessor accessor) {

    //...

	//쿼리 실행
    try {
        result = doExecute(query, accessor);
    } catch (NoResultException e) {
        return null;
    }

    //...

	//ConversionService를 통해 변환을 시도
    return CONVERSION_SERVICE.canConvert(result.getClass(), requiredType) //
            ? CONVERSION_SERVICE.convert(result, requiredType) //
            : result;
}

 

 

 

---

 

오늘은 MySQL의 저장 방식과 함께 JPA을 이용하여 DTO로 반환하는 방법을 알아보았다.

 

위에서 소개했던 인프런의 장애 이슈도 그랬듯, 여러 작은 성능 이슈들이 모여서 장애를 일으킬 수 있다는 것을 다시 한 번 느끼게 되었다.

 

작은 요소들도 놓치지 말고 어떤 이슈가 있을 수 있는지 보는 능력을 길러보자!!