API 개발 고급 - 지연 로딩과 조회 성능 최적화

사전 준비 - 조회용 샘플 데이터 입력

jpabook::jpashop::InitDb

/**
 * 총 주문 2개
 * userA
 *      JPA1 BOOK
 *      JPA2 BOOK
 * userB
 *      SPRING1 BOOK
 *      SPRING2 BOOK
 */
@Component
@RequiredArgsConstructor
public class InitDb {

    private final InitService initService;

    @PostConstruct
    public void init() {
        initService.dbInit1();
        initService.dbInit2();
    }

    @Component
    @Transactional
    @RequiredArgsConstructor
    static class InitService {

        private final EntityManager em;

        public void dbInit1() {
            Member member = createMember("userA","서울", "1", "1111");
            em.persist(member);

            Book book1 = createBook("JPA1 BOOK", 10000, 100);
            em.persist(book1);

            Book book2 = createBook("JPA2 BOOK", 20000, 100);
            em.persist(book2);

            OrderItem orderItem1 = OrderItem.createOrderItem(book1, 10000, 1);
            OrderItem orderItem2 = OrderItem.createOrderItem(book2, 20000, 2);

            Delivery delivery = createDelivery(member);
            Order order = Order.createOrder(member, delivery, orderItem1, orderItem2);
            em.persist(order);
        }

        public void dbInit2() {
            Member member = createMember("userB","진주", "2", "2222");
            em.persist(member);

            Book book1 = createBook("SPRING1 BOOK", 20000, 200);
            em.persist(book1);

            Book book2 = createBook("SPRING2 BOOK", 40000, 300);
            em.persist(book2);

            OrderItem orderItem1 = OrderItem.createOrderItem(book1, 20000, 3);
            OrderItem orderItem2 = OrderItem.createOrderItem(book2, 40000, 4);

            Delivery delivery = createDelivery(member);
            Order order = Order.createOrder(member, delivery, orderItem1, orderItem2);
            em.persist(order);
        }

        private static Member createMember(String name, String city, String street, String zipcode) {
            Member member = new Member();
            member.setName(name);
            member.setAddress(new Address(city, street, zipcode));
            return member;
        }

        private static Delivery createDelivery(Member member) {
            Delivery delivery = new Delivery();
            delivery.setAddress(member.getAddress());
            return delivery;
        }

        private static Book createBook(String name, int price, int stockQuantity) {
            Book book1 = new Book();
            book1.setName(name);
            book1.setPrice(price);
            book1.setStockQuantity(stockQuantity);
            return book1;
        }
    }
}

※ 참고

IntelliJ shortcut
ctrl+ alt + m : duplicate code refactor(중복된 코드들을 하나의 메서드로 추출해준다.)
ctrl+ alt + v : method 반환 값에 따라 변수 선언을 해준다.

주문 + 배송정보 + 회원을 조회하는 API를 여러 방법으로 만들어 볼 것이다.
그러면서 지연로딩 때문에 발생하는 성능 문제를 단계적으로 해결할 것이다.

(Impotant) 실무에서 중요한 내용들을 다루기에 이 챕터는 모두 복습 철저히 하도록 하자.

이번 장에서는 xxToOne(ManyToOne, OneToOne) 관계에 있는 엔티티와의 성능 최적화에 집중하여 해결한다.

간단한 주문 조회 V1: 엔티티 직접 노출

V1. 엔티티 직접 노출

Hibernate5Module 모듈 등록, LAZY=null 처리
양방향 관계 문제 발생 -> @JsonIgnore

package jpabook.jpashop.api;

import jpabook.jpashop.domain.Order;
import jpabook.jpashop.repository.OrderRepository;
import jpabook.jpashop.repository.OrderSearch;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.List;


/**
 * xToOne(ManyToOne, OneToOne) 관계 최적화
 * Order
 * Order -> Member
 * Order -> Delivery
 */
@RequiredArgsConstructor
@RestController
public class OrderSimpleApiController {
    private final OrderRepository orderRepository;

    @GetMapping("/api/v1/simple-orders")
    public List<Order> ordersV1(){
        List<Order> all = orderRepository.findAllByString(new OrderSearch());
        return all;
    }
}

우선 엔티티를 직접 노출(반환) 하는것은 좋지 않다.(저번 챕터에서도 언급)
해당 API를 호출하면 Order ▶ Member와 Order ▶ Delivery간에 서로의 엔티티를 조회하는 것이 무한순회를 하게되어 에러가 발생하고 제대로된 Response가 오지 못한다.

@JsonIgnore

양방향 연관관계 부분에 @JsonIgnore 을 추가해주면 Json Response를 생성할 때 연관관계 반대 쪽으로는 Ignore 하므로 무한 루프 에러는 해결된다.

하지만, 다음 에러가 발생한다.

에러 메세지를 보면 bytebuddy.ByteBuddyInterceptor에서 Type defnition error가 발생한것을 볼 수 있다. 어째서 해당 에러가 났을까?

현재 코드의 로딩 전략은 지연로딩(LAZY)전략을 사용한다. 그 말은 Member, Delivery등의 엔티티들을 조회하는 시점에서는 실제 객체가 아닌 프록시 객체를 가지고 있다.

※ 참고

요즘에는 프록시 기술을 쓸 때 bytebuddy라이브러리를 많이 사용한다. 그래서 ByteBuddyInterceptor클래스가 사실 Member member = new ByteBuddyInterceptor(); 처럼 프록시 객체가 대신 들어가 있는 것이다.

여기서 문제점은 jackson 라이브러리는 기본적으로 이 프록시 객체를 json으로 어떻게 생성해야 하는지 모르기 때문에 예외가 발생하는 것이다.

해결책

스프링 부트를 사용 중이라면 Hibernate5Module 을 스프링 Bean으로 등록하면 해결된다.

/*build.gradle*/
implementation 'com.fasterxml.jackson.datatype:jackson-datatype-hibernate5'

/*JpashopApplication.java*/
@Bean
Hibernate5Module hibernate5Module(){
	return new Hibernate5Module();
}

gradle에 implentation 할 때 version을 따로 입력해주지 않으면 Gradle에서 자동으로 현재 버전과 잘 맞는 버전을 import해서 관리해준다.

아래와 같이 hibernate5Module설정을 통해 강제로 지연 로딩도 사용 가능하다.

@Bean
Hibernate5Module hibernate5Module(){
	Hibernate5Module hibernate5Module = new Hibernate5Module();
    //강제 지연 로딩 설정
	hibernate5Module.configure(Hibernate5Module.Feature.FORCE_LAZY_LOADING, true);
	return hibernate5Module;
}

이 옵션을 키면 order ▶ member, member ▶orders 양방향 연관관계 무한루프가 돌기 때문에 @JsonIgnore를 설정해줘야 한다.

※ 주의

스프링 부트 3.0 이상이면 Hibernate5Module 대신에 Hibernate5JakartaModule 을 사용해야한다

※ 주의

엔티티를 직접 노출할 때는 양방향 연관관계가 걸린 곳은 꼭! 한곳을 @JsonIgnore 처리 해야 한다.
안그러면 양쪽을 서로 호출하면서 무한 루프가 걸린다.

하지만 사실 Lazy Loading 때문에 Hibernate 모듈을 직접 등록해서 사용하는 것은 애매한 부분이 있다.

그래서 만약 위 설정 없이 원하는 결과를 반환하고 싶다면 다음과 같이 할 수도 있다.

@GetMapping("/api/v1/simple-orders")
 public List<Order> ordersV1() {
     List<Order> all = orderRepository.findAllByString(new OrderSearch());
     for (Order order : all) {
         order.getMember().getName(); //Lazy 강제 초기화
         order.getDelivery().getAddress(); //Lazy 강제 초기환
     }
     return all;
 }

하지만 이렇게 만든 엔티티를 직접 노출한 API는 너무 정보가 많고 고정되어 있다. 만약 Client 해당 API를 사용하여 이미 구현을 해뒀으면 나중에 API 스팩에 따른 변경이 너~무 힘들다.

(중요!!) 앞에서 계속 강조했듯이 정말 간단한 애플리케이션이 아니면 엔티티를 API 응답으로 외부로 노출하는 것은 좋지 않다.

따라서 Hibernate5Module을 이용하는 방법은 알아만 두고 실무에서는 DTO로 변환해서 반환하는것이 더 좋은 방법이다.

※ 주의

지연 로딩(LAZY)을 피하기 위해 즉시 로딩(EARGR)으로 설정하면 안된다! 즉시 로딩 때문에 연관관계가 필요 없는 경우에도 데이터를 항상 조회해서 성능 문제가 발생할 수 있다. 즉시 로딩으로 설정하면 성능 튜닝이 매우 어려워 진다.

항상 지연 로딩을 기본으로 하고, 성능 최적화가 필요한 경우에는 페치 조인(fetch join)을 사용해자!!
(V3에서 설명)

간단한 주문 조회 V2: 엔티티를 DTO로 변환

package jpabook.jpashop.api;

import jpabook.jpashop.domain.Address;
import jpabook.jpashop.domain.Order;
import jpabook.jpashop.domain.OrderStatus;
import jpabook.jpashop.repository.OrderRepository;
import jpabook.jpashop.repository.OrderSearch;
import lombok.Data;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.time.LocalDateTime;
import java.util.List;
import java.util.stream.Collectors;


/**
 * xToOne(ManyToOne, OneToOne
 * Order
 * Order -> Member
 * Order -> Delivery
 */
@RequiredArgsConstructor
@RestController
public class OrderSimpleApiController {
    private final OrderRepository orderRepository;

    @GetMapping("/api/v2/simple-orders")
    public List<SimpleOrderDto> ordersV2(){
        List<Order> orders = orderRepository.findAllByString(new OrderSearch());

        List<SimpleOrderDto> result = orders.stream()
                .map(o -> new SimpleOrderDto(o))
                .collect(Collectors.toList());
        return result;

    }

    @Data
    static class SimpleOrderDto{
        private Long orderId;
        private String name;
        private LocalDateTime orderDate;
        private OrderStatus orderStatus;
        private Address address;

        public SimpleOrderDto(Order order){
            orderId = order.getId();
            name = order.getMember().getName(); //LAZY 초기화
            orderDate = order.getOrderDate();
            orderStatus = order.getStatus();
            address = order.getDelivery().getAddress(); //LAZY 초기화
        }
    }
}

엔티티를 DTO로 변환하는 일반적인 방법이다.
- DTO가 엔티티를 파라미터로 직접 받는 것은 큰 문제가 되지 않는다. 왜냐하면 별로 중요하지 않은 곳에서 엔티티를 의존하는 것뿐이기 때문에 문제가 되지 않는다.

V1, V2의 공통된 문제점 ( N + 1 문제 )

쿼리가 총 1 + N + N 번 실행된다.(v1과 쿼리수 결과는 같다.)
- order 조회 1번(order 조회 결과 수가 N이 된다.)
- order → member 지연 로딩 조회 N번
- order → delivery 지연 로딩 조회 N번
- Ex: order의 결과가 2개면 최악의 경우 1 + 2 + 2번 실행된다.(최악의 경우)
  - 왜 최악의 경우라도 따로 언급을 했냐면...
    → 지연로딩은 영속성 컨텍스트에서 조회하므로, 이미 조회된 경우 쿼리를 생략한다.
    → 즉, 만약 영속성 컨텍스트에 같은 @Id를 갖는 엔티티가 있으면 쿼리가 생략된다는 것이다.

V2버전으로 API호출했을 때 실행되는 쿼리

쿼리가 1 + N + N 번 실행된 것을 볼 수 있다.
- 물론, 여기서 member가 동일할 경우 처음 조회 이후 다시 조회 하지 않기 때문에 1번의 쿼리수행이 더 줄어들 수 있지만, 흔한 케이스가 아니기에 고려하지 않는다.
Order 조회가 많아질수록 기하급수적으로 쿼리수행이 많아지고 성능저하가 일어날 수 있다

만약 로딩 전략은 EAGER로 한다면 해결될까? 쿼리는 어떻게 실행될까?? 쿼리가 최적화 될까?

Order와 Delivery 쿼리 외에도 아래와 같은 전혀 예상하지 못한 쿼리가 실행된다.

간단한 주문 조회 V3: 엔티티 DTO로 변환 → 페치 조인 최적화

V3. 엔티티를 조회해서 DTO로 변환(fetch join 사용O)

fetch join으로 쿼리 1번 호출

참고: fetch join에 대한 자세한 내용은 JPA 기본편 참고(정말 중요함)

12. 객체지향 쿼리 언어2 - 중급 문법

경로 표현식 .(점)을 찍어 객체 그래프를 탐색하는 것 select m.username -> 상태 필드 from Member m join m.team t -> 단일 값 연관 필드 join m.orders o -> 컬렉션 값 연관 필드 where t.name ='팀A' 경로 표현식 용어

s-y-130.tistory.com

package jpabook.jpashop.api;

import jpabook.jpashop.domain.Address;
import jpabook.jpashop.domain.Order;
import jpabook.jpashop.domain.OrderStatus;
import jpabook.jpashop.repository.OrderRepository;
import jpabook.jpashop.repository.OrderSearch;
import lombok.Data;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.time.LocalDateTime;
import java.util.List;
import java.util.stream.Collectors;


/**
 * xToOne(ManyToOne, OneToOne
 * Order
 * Order -> Member
 * Order -> Delivery
 */
@RequiredArgsConstructor
@RestController
public class OrderSimpleApiController {
    private final OrderRepository orderRepository;

    @GetMapping("/api/v3/simple-orders")
    public List<SimpleOrderDto> ordersV3(){
        List<Order> orders = orderRepository.findAllWithMemberDelivery();

        List<SimpleOrderDto> collect = orders.stream()
                .map(o -> new SimpleOrderDto(o))
                .collect(Collectors.toList());
        return collect;

    }

    @Data
    static class SimpleOrderDto{
        private Long orderId;
        private String name;
        private LocalDateTime orderDate;
        private OrderStatus orderStatus;
        private Address address;

        public SimpleOrderDto(Order order){
            orderId = order.getId();
            name = order.getMember().getName(); //LAZY 초기화
            orderDate = order.getOrderDate();
            orderStatus = order.getStatus();
            address = order.getDelivery().getAddress(); //LAZY 초기화
        }
    }
}
...
/*orderRepository.findAllWithMemberDelivery*/
public List<Order> findAllWithMemberDelivery() {
    return em.createQuery(
            	    "select o from Order o" +
                    " join fetch o.member m" +
                    " join fetch o.delivery d", Order.class
    ).getResultList();
}

엔티티를 페치 조인(fetch join)을 사용해서 쿼리 1번에 조회
페치 조인으로 order → member, order→ delivery 는 이미 조회 된 상태 이므로 지연로딩 X

V3버전으로 API호출했을 때 실행되는 쿼리

V3까지 최적화를 통해 N+1 쿼리를 1건 쿼리로 최적화를 진행해봤다. 하지만 여기서도 쿼리를 보시다시피 엔티티를 이용하여 쿼리가 실행되고 있다.

V4에서는 이를 최적화 하는 방법을 학습할 것이다.

간단한 주문 조회 V4: JPA에서 DTO로 바로 조회

Controller

/**
 * V4. JPA에서 DTO로 바로 조회
 * - 쿼리1번 호출
 * - select 절에서 원하는 데이터만 선택해서 조회 
 */
@GetMapping("/api/v4/simple-orders")
public List<OrderSimpleQueryDto> ordersV4() {
	return orderSimpleQueryRepository.findOrderDtos(); 
}

방법에 따라서 원하는 값을 선택해서 조회하는 경우 엔티티를 조회하는 리포지토리(OrderRepository)가 아니라 따로 쿼리용 리포지토리를 만들면 구분이 쉽다.
또한 실무에서는 통계용 쿼리, 통계용 API 등 복잡한 join 쿼리를 갖고 DTO를 바로 뽑는 경우도 많기 때문에 패키지를 따로 만들어 가는게 유지보수에도 좋다.

OrderSimpleQueryRepository 조회 전용 리포지토리

package jpabook.jpashop.repository.order.simplequery;

import jpabook.jpashop.repository.OrderSimpleQueryDto;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;

import javax.persistence.EntityManager;
import java.util.List;

@Repository
@RequiredArgsConstructor
public class OrderSimpleQueryRepository {

    private final EntityManager em;

    public List<OrderSimpleQueryDto> findOrderDtos() {
        return em.createQuery(
                "select new jpabook.jpashop.repository.OrderSimpleQueryDto(o.id,m.name,o.orderDate,o.status,d.address)" +
                "  from Order o"
                " join o.member m" +
                " join o.delivery d", OrderSimpleQueryDto.class
        ).getResultList();
    }
}

jpa는 기본적으로 엔티티나 value Object만 반환할 수 있다.
또한 new 연산자 방법은 엔티티를 바로 넘기는 것은 안된다. 엔티티를 바로 넘겨버리면 식별자만 넘어간다.
new 를 통해 객체를 생성해줄 때 full package path를 입력해줘야 한다.

OrderSimpleQueryDto

package jpabook.jpashop.repository.order.simplequery;

import jpabook.jpashop.domain.Address;
import jpabook.jpashop.domain.Order;
import jpabook.jpashop.domain.OrderStatus;
import lombok.Data;

import java.time.LocalDateTime;

@Data
public class OrderSimpleQueryDto {
    private Long orderId;
    private String name;
    private LocalDateTime orderDate;
    private OrderStatus orderStatus;
    private Address address;

    public OrderSimpleQueryDto(Order order) {
        orderId = order.getId();
        name = order.getMember().getName(); //LAZY 초기화
        orderDate = order.getOrderDate();
        orderStatus = order.getStatus();
        address = order.getDelivery().getAddress(); //LAZY 초기화
    }
		/* OrderSimpleQueryRepository::findOrderDtos메서드에서 사용할 생성자(Constructor)*/
    public OrderSimpleQueryDto(Long orderId,
                               String name,
                               LocalDateTime orderDate,
                               OrderStatus orderStatus,
                               Address address) {
        this.orderId = orderId;
        this.name = name;
        this.orderDate = orderDate;
        this.orderStatus = orderStatus;
        this.address = address;
    }

}

일반적인 SQL을 사용할 때 처럼 원하는 값을 선택해서 조회
new 명령어를 사용해서 JPQL이 결과를 DTO로 즉시 변환
SELECT 절에서 원하는 데이터를 직접 선택하므로 DB → application 네트워크 용량 최적화(생각보단 미비하다)
리포지토리 재사용성이 떨어짐, API 스펙에 맞춘 코드가 리포지토리에 들어가는 단점

v3, v4 쿼리 비교

각각의 장단점이 있지만 우선 쿼리만 보면 확실히 원하는 것만 가져오는 DTO 방식이 더 짧은 것을 확인할 수 있다.

그러나 과연 성능 차이가 얼마나 날까??

정확히는 성능 테스트를 해봐야 알겠지만 대부분의 경우는 두 방식의 성능차이는 거의 나지 않는다.
우선 네트워크가 많이 발전했다.
그리고 대부분의 성능은 join 문과 연관이 있다. 즉, select 절에서 필드가 몇개 추가된다고 해서 성능 차이는 그렇게 없다.
- 또한 대부분 쿼리 성능은 인덱스를 잘못 걸었다든지 그런 부분이다.
물론 데이터 사이즈가 너무 클 때는 얘기가 다르다. select 필드가 20~30개가 되면 api 호출 횟수에 따라 select 문 최적화도 고민은 해볼 수 있다.

정리

엔티티를 DTO로 변환하거나, DTO로 바로 조회하는 두가지 방법은 각각 장단점이 있다. 둘 중 상황에 따라서 더 나은 방법을 선택하면 된다.
엔티티로 조회하면 리포지토리 재사용성도 좋고, 개발도 단순해진다. 따라서 권장하는 방법은 다음과 같다.

쿼리 방식 선택 권장 순서

우선 엔티티를 DTO로 변환하는 방법을 선택한다.
필요하면 페치 조인으로 성능을 최적화 한다. => 대부분의 성능 이슈가 해결된다(95%이상 해결 가능)
그래도 안되면 DTO로 직접 조회하는 방법을 사용한다. => V4 방법
최후의 방법은 JPA가 제공하는 네이티브 SQL이나 스프링 JDBC Template을 사용해서 SQL을 직접 사용한다

사전 준비 - 조회용 샘플 데이터 입력

jpabook::jpashop::InitDb

간단한 주문 조회 V1: 엔티티 직접 노출

@JsonIgnore

해결책

간단한 주문 조회 V2: 엔티티를 DTO로 변환

V1, V2의 공통된 문제점 ( N + 1 문제 )

V2버전으로 API호출했을 때 실행되는 쿼리

간단한 주문 조회 V3: 엔티티 DTO로 변환 → 페치 조인 최적화

V3버전으로 API호출했을 때 실행되는 쿼리

간단한 주문 조회 V4: JPA에서 DTO로 바로 조회

Controller

OrderSimpleQueryRepository 조회 전용 리포지토리

OrderSimpleQueryDto

v3, v4 쿼리 비교

정리

쿼리 방식 선택 권장 순서

티스토리툴바