[JPA] API 개발 - 지연로딩과 성능 최적화 (feat.Fetch 조인)

JPA 의 지연로딩 옵션을 사용할 때 발생하는 성능문제를 단계적으로 해결해보자. 

 

Version 1. 엔티티를 직접 노출 (지양 해야하는 버전)

아래 코드는 Order 엔티티를 컬렉션에 담아 그대로 노출한다. 이럴 경우 API 스펙이 변경되면 클라이언트 단에서는 변경된 스펙에 대응하지 못하고 잘못된 값을 읽어들여 에러가 발생할 가능성이 존재한다. 또한 엔티티를 그대로 노출하기 때문에 보안상의 문제도 간과한다. 

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

    private final OrderRepository orderRepository;
    private final OrderSimpleQueryRepository orderSimpleQueryRepository; //의존관계 주입

    /**
     * V1. 엔티티 직접 노출
     * - Hibernate5Module 모듈 등록, LAZY=null 처리
     * - 양방향 관계 문제 발생 -> @JsonIgnore
     */
    @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;
    }
}

Order 엔티티는 Member 와 Delivery 라는 엔티티와 xToOne 관계를 맺고 있다. 무슨 뜻이냐하면 Order은 1이거나 N이 될 수 있지만, Member 와 Delivery는 항상 1인 경우를 의미한다. 각각의 엔티티를 살펴보자. 서로가 서로를 단방향으로 참조하기 때문에 Order-Member, Order-Delivery 는 양방향 연관관계가 형성된다.

Order

Member 와 Delivery 를 참조하며 옵션은 LAZY 를 사용하고 있다. 지연로딩을 사용한다는 의미인데, 이것을 EAGER 로 변경하면 Order 를 조회하는 즉시 Member 와 Delivery 도 조회한다. 그러면 편하고 좋은것 아니냐고? 그렇게 생각할 수도 있지만 EAGER 를 사용하면 1) N + 1 문제와 2) 성능 최적화 2가지 문제가 발생할 수 있다. 왜냐하면 즉시 로딩을 사용시, Order 만 조회하고 싶은 경우에도 Member, Delivery 가 곧바록 따라서 조회되기 때문에 불필요한 데이터를 읽어 성능이 저하될 수 있다.  때문에 LAZY 옵션을 사용하더라도, 위 컨트롤러의 for문으로  member 와 delivery 에 대해 강제 초기화를 진행하는 방법을 지향해야한다. 그럼 강제초기화는 왜 해야하는 걸까? Order -> Member 와 Order -> Delivery 는 지연로딩이다. 즉 실제 엔티티 대신 프록시 객체를 가져오는 것이고, 이를 그대로 웹에 노출할 시, 프록시 객체를 json 형태로 변경하는 방법을 모르기 때문에 예외가 발생한다. 그래서 일일이 강제초기화를 해줘야 한다. 

@Entity
@Table(name = "orders")
@Getter @Setter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Order {

    @Id @GeneratedValue
    @Column(name = "order_id")
    private Long id;

    @ManyToOne(fetch = LAZY)
    @JoinColumn(name = "member_id")
    private Member member;

    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
    private List<OrderItem> orderItems = new ArrayList<>();

    @OneToOne(fetch = LAZY, cascade = CascadeType.ALL)
    @JoinColumn(name = "delivery_id")
    private Delivery delivery;


}

Member

@Entity
@Getter @Setter
public class Member {

    @Id @GeneratedValue
    @Column(name = "member_id")
    private Long id;

    private String name;

    @Embedded
    private Address address;

    @JsonIgnore
    @OneToMany(mappedBy = "member")
    private List<Order> orders = new ArrayList<>();

}

Delivery

@Entity
@Getter @Setter
public class Delivery {

    @Id @GeneratedValue
    @Column(name = "delivery_id")
    private Long id;

    @JsonIgnore
    @OneToOne(mappedBy = "delivery", fetch = LAZY)
    private Order order;

    @Embedded
    private Address address;

    @Enumerated(EnumType.STRING)
    private DeliveryStatus status; //READY, COMP
}

* V1 처럼 엔티티를 직접 노출할 때는 양방향관계가 걸린 곳은 꼭 한곳을 @JsonIgnore 처리해야 한다. 그렇지 않으면 양쪽을 서로 호출하면서 무한 루프가 발생한다. 

 

Version 2. 엔티티를 DTO로 변환

@RestController
@RequiredArgsConstructor
public class OrderSimpleApiController {

    private final OrderRepository orderRepository;
    private final OrderSimpleQueryRepository orderSimpleQueryRepository; //의존관계 주입

    /**
     * V2. 엔티티를 조회해서 DTO로 변환(fetch join 사용X)
     * - 단점: 지연로딩으로 쿼리 N번 호출
     */
    @GetMapping("/api/v2/simple-orders")
    public List<SimpleOrderDto> ordersV2() {
        List<Order> orders = orderRepository.findAll();
        List<SimpleOrderDto> result = orders.stream()
                .map(o -> new SimpleOrderDto(o))
                .collect(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();
            orderDate = order.getOrderDate();
            orderStatus = order.getStatus();
            address = order.getDelivery().getAddress();
        }
    }

}

엔티티를 DTO 로 변환하는 일반적인 방법으로, V1 과 달리 엔티티를 직접적으로 노출하지 않는다.

그럼 다 해결된것인가? 아직 최적화의 문제가 남았다.

위 코드에서는 쿼리가 총 1 + N + N번 실행된다. 

우선 order 를 1번 조회한다. 이때 order 의 조회 결과가 N개 라고 하자. 

그럼 order 에서 member 를 조회할 때 지연로딩이 N 번 발생하고, 마찬가지로 order 에서 delivery를 조회할 때 또 지연로딩이 N번 발생한다. 예를 들어 N 이 10이라면 총 발생하는 쿼리 갯수가 1 (order) + 10 (member) + 10 (delivery) 로 총 21번 실행되는 것이다. 이런 N + 1 문제로 인해 성능 저하 문제가 발생할 수 있음을 인지하고 V3에서 페치 조인 최적화로 문제를 해결해보자. 

 

 

Version 3. 엔티티를 DTO로 변환 + 페치 조인 최적화

 findAllWithMemberDelivery() 라는 메서드만 조회하면 V2 코드와 별반 다를게 없어 보인다.  findAllWithMemberDelivery() 내부를 살펴보자.

@RestController
@RequiredArgsConstructor
public class OrderSimpleApiController {

    private final OrderRepository orderRepository;
    private final OrderSimpleQueryRepository orderSimpleQueryRepository; //의존관계 주입

    /**
     * V3. 엔티티를 조회해서 DTO로 변환(fetch join 사용O)
     * - fetch join으로 쿼리 1번 호출
     * 참고: fetch join에 대한 자세한 내용은 JPA 기본편 참고(정말 중요함)
     */
    @GetMapping("/api/v3/simple-orders")
    public List<SimpleOrderDto> ordersV3() {
        List<Order> orders = orderRepository.findAllWithMemberDelivery();
        List<SimpleOrderDto> result = orders.stream()
                .map(o -> new SimpleOrderDto(o))
                .collect(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();
            orderDate = order.getOrderDate();
            orderStatus = order.getStatus();
            address = order.getDelivery().getAddress();
        }
    }

}

 

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();
}

JPQL 문법에서 join fetch 명령어를 사용한다. 이를 페치 조인이라 하는데, SQL 문법이 아닌 JPQL 에서 성능 최적화를 위해 제공하는 기능이다. 페치 조인을 사용하면 연관된 엔티티나 클래스를 한번에 같이 조회할 수 있는 기능을 제공한다. 즉 Order 를 조회할 때 연관관계에 있는 member 와 delivery 도 함께 조회하는 것이라 생각하면 된다.

이렇게 페치 조인을 사용하면 뭐가 좋을까? 바로 N + 1 문제가 해결된다. 즉 쿼리 1번에 Order 뿐만 아니라 Member 와 Delivery 까지 조회가 가능해진다. 페치 조인을 사용하면 지연 로딩 자체가 실행되지 않음을 기억하자. 

 

 

 

* 출처 
실전!스프링부트와 JPA 활용 2 를 수강하고 정리한 포스팅임을 밝힙니다.