실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 - 인프런 | 강의

스프링 부트와 JPA를 활용해서 API를 개발합니다. 그리고 JPA 극한의 성능 최적화 방법을 학습할 수 있습니다., 스프링 부트, 실무에서 잘 쓰고 싶다면? 복잡한 문제까지 해결하는 힘을 길러보세요

www.inflearn.com

주문내역에서 주문한 상품 정보를 추가로 조회해보자

Order 기준으로 컬렉션인 OrderItem 와 Item 이 필요

주문 조회 V1 - 엔티티 직접 노출

@RestController
@RequiredArgsConstructor
public class OrderApiController {

    private final OrderRepository orderRepository;

    @GetMapping("/api/v1/orders")
    public List<Order> ordersV1(){
        List<Order> all = orderRepository.findAllByString(new OrderSearch());
        for (Order order : all) {
            order.getMember().getName();
            order.getDelivery().getAddress();

            List<OrderItem> orderItems = order.getOrderItems();
            orderItems.stream().forEach(o -> o.getItem().getName());
        }
        return all;
    }
}
  • orderItem, item 관계를 직접 초기화 하면 Hibernate5Module 설정에 의해 엔티티를 JSON으로 생성한다.
  • 양방향 연관관계면 무한 루프에 걸리지 않게 한 곳에 @JsonIgnore를 추가해야한다.
  • 엔티티를 직접 노출하므로 좋지 않다.

주문 조회 V2 - 엔티티를 DTO로 변환

Controller

@GetMapping("/api/v2/orders")
    public List<OrderDto> ordersV2() {
        List<Order> orders = orderRepository.findAllByString(new OrderSearch());
        List<OrderDto> collect = orders.stream()
                                       .map(o -> new OrderDto(o))
                                       .collect(Collectors.toList());

        return collect;
    }

    @Data
    static class OrderDto {
        private Long orderId;
        private String name;
        private LocalDateTime orderDate;
        private OrderStatus orderStatus;
        private Address address;
        private List<OrderItemDto> orderItems;

        public OrderDto(Order order) {
            orderId = order.getId();
            name = order.getMember().getName();
            orderDate = order.getOrderDate();
            orderStatus = order.getStatus();
            address = order.getMember().getAddress();
            orderItems = order.getOrderItems().stream()  //지연로딩 호출
                    .map(OrderItemDto::new)
                    .collect(Collectors.toList());
        }
    }
    @Getter
    static class OrderItemDto {

        private String itemName; //상품 명
        private int orderPrice; //주문 가격
        private int count; // 주문 수량

        public OrderItemDto(OrderItem orderItem) {
            itemName = orderItem.getItem().getName();
            orderPrice = orderItem.getOrderPrice();
            count = orderItem.getCount();
        }
    }
  • OrderDto 생성자에서 OrderItems를 지연로딩으로 호출해 주고 있는데, 이를 dto로 처리하지 않을시 결국 엔티티가 직접 호출이 되는 것이기 때문에, 조인된 필드의 엔티티도 Dto로 만들어서 처리한다. → OrderDto와 OrderItemDto 생성
  • 나머지 ValueObject(Address)는 엔티티 그대로 조회해도 된다.
  • 위의 방법은 엔티티는 노출하지 않았지만, 지연로딩으로 인해 너무 많은 SQL이 실행된다.

SQL 실행 수

  • order 1번
  • member, address N번
  • orderItem N 번
  • item N 번

영속성 컨텍스트에 엔티티가 존재할 시 영속성 컨텍스트에 있는 엔티티를 사용하고, 없으면 SQL을 사용한다. 따라서 같은 영속성 컨텍스트에서 이미 로딩한 회원 엔티티를 추가로 조회하면 SQL을 실행하지 않는다.

주문 조회 V3 - 엔티티를 DTO로 변환, 페치 조인 최적화

Controller

@GetMapping("/api/v3/orders")
    public List<OrderDto> ordersV3() {
        List<Order> orders = orderRepository.findAllWithItem();
        List<OrderDto> collect = orders.stream()
                                       .map(o -> new OrderDto(o))
                                       .collect(Collectors.toList());
        return collect;
    }

Repository

public List<Order> findAllWithItem() {
        return em.createQuery(
                "select distinct o from Order o" +
                        " join fetch o.member m" +
                        " join fetch o.delivery d" +
                        " join fetch o.orderItems oi" +
                        " join fetch oi.item i", Order.class)
                .getResultList();

    }
  • 페치 조인으로 인해 SQL이 한 번만 실행된다.
  • oneToMany 관계일 때 distinct를 사용하지 않으면 row수가 ONE의 갯수가 아닌, Many의 갯수만큼 증가하게 된다.
  • JPQL에서 distinct를 사용하게 된면 SQL에 distinct를 추가하고, 애플리케이션에서 같은 엔티티중복을 걸러준다. 이로써 컬렉션 페치 조인 때문에 중복조회 되는것을 막을 수 있다.

단점

  • 페이징 불가능 → 컬렉션 페치 조인을 사용하면 페이징이 불가능 하다. 이유는 하이버네이트는 경고 로그를 남기면서 모든 데이터를 DB에서 읽어오고, 메모리에서 페이징을 해버린다. 그러면, 조회한 데이터가 많은 경우 out of memory 예외가 발생할 수 있어 매우 치명적이다.
  • 컬렉션 페치 조인은 1개만 사용할 수 있다. → 컬렉션 둘 이상 페치조인 사용 시 데이터의 정합성이 떨어지며, N * N개로 조회되는 중복된 row의 수가 기하급수적으로 증가한다.

주문 조회 V3.1 - 페이징과 한계 돌파

페이징과 한계 돌파

컬렉션을 페치 조인하면 페이징이 불가능하다.

  • 컬렉션을 페치조인하면 일대다 조인이 발생 → 데이터가 예측할 수 없이 증가
  • 일대다에서 일(1)을 기준으로 페이징을 하는 것이 목적이다. 그런데 데이터는 다(N)을 기준으로 row가 생성되어 버린다.
  • Order를 기준으로 페이징 하고 싶은데, 다(N)인 OrderItem을 조인하면 OrderItem이 기준이 되어 버린다.
  • 이 경우 하이버네이트는 경고 로그를 남기고 모든 DB데이터를 읽어서 메모리에서 페이징을 시도하는데, 최악의 경우 장애로 이어질 수 있다.

한계 돌파

페이징 + 컬렉션 엔티티를 함께 조회하기 위해서는 어떻게 해야할까?

  1. 먼저 ToOne(OneToOne, ManyToOne)관계를 모두 페치조인 한다. ToOne관계는 row수를 증가시키지 않으므로 페이징 쿼리에 영향을 주지 않는다.
  2. 컬렉션은 지연 로딩으로 조회한다.
  3. 지연 로딩 성능 최적화를 위해 hibernamte.default_batch_fetch_size, @BatchSize를 적용한다.
    hibernamte.default_batch_fetch_size : 전역 설정
    @BatchSize : 개별 최적화
    해당 옵션을 사용하면 컬렉션이나, 프록시 객체를 한꺼번에 설정한 size만큼 IN쿼리로 조회한다.

Controller

@GetMapping("/api/v3.1/orders")
    public List<OrderDto> ordersV3_page(
            @RequestParam(value= "offset", defaultValue = "0" ) int offset,   // 페이징 시작
            @RequestParam(value= "limit", defaultValue = "100" ) int limit) { // 페이징 마지막
        List<Order> orders = orderRepository.findAllWithMemberDelivery(offset, limit); // Member와 Delivery만 페치 조인
        List<OrderDto> collect = orders.stream()                              // 컬렉션은 지연로딩으로 처리
                                       .map(o -> new OrderDto(o))
                                       .collect(Collectors.toList());
        return collect;
    }

최적화 옵션 hibernamte.default_batch_fetch_size 적용 : application.yml or application.properties

// application.yml
spring:
    jpa:
    properties:
      hibernate:
            default_batch_fetch_size: 100

// application.properties
spring.jpa.properties.hibernate.default_batch_fetch_size = 100
  • 해당 옵션을 개별로 설정하려면 @BatchSize를 적용하면 된다.
    → 컬렉션은 컬렉션 필드에, 엔티티는 엔티티 클래스에 적용한다.

장점

  • 쿼리 호출수가 1 + N → 1 + 1 로 최적화 된다.
  • 조인보다 DB 데이터 전송량이 최적화 된다.(Order와 OrderItem을 조인하면 Order가 OrderItem만큼 중복해서 조회된다. 이 방법은 각각 조회하므로 전송해야 할 중복 데이터가 없다.)
  • 페치 조인 방식과 비교해서 쿼리 호출 수가 약간 증가하지만, DB데이터 전송량이 감소한다.
  • 컬렉션 페치 조인은 페이징이 불가능 하지만, 이 방법은 페이징이 가능하다.

결론

  • ToOne 관계는 페치 조인해도 페이징에 영향을 주지 않는다. 따라서 ToOne 관계는 페치조인으로 쿼리수를 줄이고,
    나머지는 hibernamte.default_batch_fetch_size 로 최적화 하자.

default_batch_fetch_size 의 크기는 어떻게 정할까?

100 ~ 1000 사이의 값을 선택하는 것을 권장한다. 이 전략은 SQL IN 절을 사용하는데, 데이터베이스에 따라 IN 절 파라미터를 1000으로 제한하기도 한다.
1000으로 잡으면 한번에 1000개를 DB에서 애플리케이션에 불러오므로 DB에 순간 부하가 증가할 수 있다.
하지만 애플리케이션은 100이든 1000이든 결국 전체 데이터를 로딩해야 하므로 메모리 사용량이 같으므로, 1000으로 설정하는 것이 성능이 가장 좋지만,
DB가 어디까지 부하를 견딜 수 있는지로 결정하면 된다.

주문 조회 V4 - JPA에서 DTO 직접 조회

Controller

@GetMapping("/api/v4/orders")
public List<OrderQueryDto> ordersV4() {
    return orderQueryRepository.findOrderQueryDtos();
}

OrderQueryRepository

public List<OrderQueryDto> findOrderQueryDtos() {
        List<OrderQueryDto> result = findOrders(); // 쿼리 1번 -> N개
        result.forEach(o -> {
            List<OrderItemQueryDto> orderItems = findOrderItems(o.getOrderId()); // Query N번
            o.setOrderItems(orderItems);
        });
        return result;
    }

    private List<OrderItemQueryDto> findOrderItems(Long orderId) {
        return em.createQuery(
                "select new jpabook.jpashop.repository.order.query.OrderItemQueryDto(oi.order.id, i.name, oi.orderPrice, oi.count)" +
                        " from OrderItem oi" +
                        " join oi.item i" +
                        " where oi.order.id = :orderId", OrderItemQueryDto.class)
                .setParameter("orderId", orderId)
                .getResultList();
    }

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

OrderQueryDto

@Data
public class OrderQueryDto {
    private Long orderId;
    private String name;
    private LocalDateTime orderDate;
    private OrderStatus orderStatus;
    private Address address;
    private List<OrderItemQueryDto> orderItems;

    public OrderQueryDto(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;
    }
}

OrderItemQueryDto

@Data
public class OrderItemQueryDto {
    @JsonIgnore
    private Long orderId;
    private String itemName;
    private int orderPrice;
    private int count;

    public OrderItemQueryDto(Long orderId, String itemName, int orderPrice, int count) {
        this.orderId = orderId;
        this.itemName = itemName;
        this.orderPrice = orderPrice;
        this.count = count;
    }
}
  • Query : 루트 1번, 컬렉션 N 번 실행
  • ToOne(N:1, 1:1) 관계들을 먼저 조회하고, ToMany(1:N) 관계는 각각 별도로 처리한다.
    → ToOne 관계는 조인해도 데이터 row수가 증가하지 않는다
    → ToMany(1:N) 관계는 조인하면 row 수가 증가한다.
  • row수가 증가하지 않는 ToOne관계는 조인으로 최적화 하기 쉬우므로 한번에 조회하고, ToMany 관계는 최적화 하기 어려우므로 findOrderItems() 같은 별도의 메서드로 조회한다.

주문 조회 V5 - JPA에서 DTO 직접조회, 컬렉션 조회 최적화

Controller

@GetMapping("/api/v5/orders")
    public List<OrderQueryDto> ordersV5() {
        return orderQueryRepository.findAllByDto_optimization();
    }

Repository

public List<OrderQueryDto> findAllByDto_optimization() {
        List<OrderQueryDto> result = findOrders();  //쿼리 1
        Map<Long, List<OrderItemQueryDto>> orderItemMap = findOrderItemMap(toOrderIds(result)); //쿼리 2
        result.forEach(o -> o.setOrderItems(orderItemMap.get(o.getOrderId()))); //루프를 돌면서 컬렉션 추가(추가 쿼리 실행X)
        return result;
    }

    private Map<Long, List<OrderItemQueryDto>> findOrderItemMap(List<Long> orderIds) {
        List<OrderItemQueryDto> orderItems = em.createQuery(
                                                      "select new jpabook.jpashop.repository.order.query.OrderItemQueryDto(oi.order.id, i.name, oi.orderPrice, oi.count)" +
                                                              " from OrderItem oi" +
                                                              " join oi.item i" +
                                                              " where oi.order.id in :orderIds", OrderItemQueryDto.class)
                                              .setParameter("orderIds", orderIds)
                                              .getResultList();
        Map<Long, List<OrderItemQueryDto>> orderItemMap = orderItems.stream()
                                                               .collect(Collectors.groupingBy(OrderItemQueryDto -> OrderItemQueryDto.getOrderId()));
        return orderItemMap;
    }

    private List<Long> toOrderIds(List<OrderQueryDto> result) {
        List<Long> orderIds = result.stream()
                                    .map(OrderQueryDto::getOrderId)
                                    .collect(Collectors.toList());
        return orderIds;
    }
  • Query : 루트 1번, 컬렉션 1번
  • ToOne 관계들을 먼저 조회하고, 여기서 얻은 식별자 orderId로 ToMany 관계인 OrderItem을 한꺼번에 조회
  • Map을 이용해서 매칭 성능 향상

주문 조회 V6 - JPA에서 DTO 직접 조회, 플랫 데이터 최적화

Controller

@GetMapping("/api/v6/orders")
public List<OrderQueryDto> ordersV6() {
    List<OrderFlatDto> flats = orderQueryRepository.findAllByDto_flat();
    return flats.stream()
            .collect(groupingBy(o -> new OrderQueryDto(o.getOrderId(), o.getName(), o.getOrderDate(), o.getOrderStatus(), o.getAddress()),
                    mapping(o -> new OrderItemQueryDto(o.getOrderId(), o.getItemName(), o.getOrderPrice(), o.getCount()), toList())))
            .entrySet().stream()
            .map(e -> new OrderQueryDto(e.getKey().getOrderId(), e.getKey().getName(), e.getKey().getOrderDate(), e.getKey().getOrderStatus(), e.getKey().getAddress(), e.getValue()))
            .collect(toList());
}

OrderFlatDto

@Data
@EqualsAndHashCode(of = "orderId")  // 컨트롤러에서 groupingBy 할때, 기준이 되는 필드 설정
public class OrderQueryDto {
    private Long orderId;
    private String name;
    private LocalDateTime orderDate;
    private OrderStatus orderStatus;
    private Address address;
    private List<OrderItemQueryDto> orderItems;

    public OrderQueryDto(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;
    }

    public OrderQueryDto(Long orderId, String name, LocalDateTime orderDate, OrderStatus orderStatus, Address address, List<OrderItemQueryDto> orderItems) {
        this.orderId = orderId;
        this.name = name;
        this.orderDate = orderDate;
        this.orderStatus = orderStatus;
        this.address = address;
        this.orderItems = orderItems;
    }
}

Repository

public List<OrderFlatDto> findAllByDto_flat(){
    return em.createQuery(
            "select new" +
                    " jpabook.jpashop.repository.order.query.OrderFlatDto(o.id, m.name, o.orderDate, o.status, d.address, i.name, oi.orderPrice, oi.count)" +
                    " from Order o" +
                    " join o.member m" +
                    " join o.delivery d" +
                    " join o.orderItems oi" +
                    " join oi.item i", OrderFlatDto.class)
            .getResultList();
}
  • 해당 코드들을 수행했을 때 실행되는 쿼리(Query)는 1번이다.

단점

  • 쿼리는 한 번만 수행되지만 조인으로 인해 DB에서 애플리케이션에 전달하는 데이터에 중복데이터가 추가되기 때문에 V5보다 더 느릴수도 있다.
  • Grouping 및 Mapping을 애플리케이션에서 처리 → 애플리케이션의 추가 작업이 크다.
  • 페이징이 불가능하다. → 중복된 데이터를 반환하기 때문에 Order를 기준으로 페이징이 불가능하다.

API 개발 고급 정리

엔티티 조회

  • 엔티티를 조회해서 그대로 반환 : V1
  • 엔티티 조회 후 DTO로 변환 : V2
  • 페치 조인으로 쿼리 수 최적화 : V3
  • 컬렉션 페이징과 한계 돌파 : V3.1 → ToOne 관계는 페치조인으로 쿼리 수 최적화, 컬렉션은 지연 로딩을 유지하고, hibername.default_batch_fetch_size 또는 @BatchSize로 최적화

DTO 직접 조회

  • JPA에서 DTO를 직접 조회: V4
  • 컬렉션 조회 최적화 - 일대다 관계인 컬렉션은 IN 절을 활용해서 메모리에 미리 조회해서 최적화 : V5
  • 플랫 데이터 최적화 - JOIN 결과를 그대로 조회 후 애플리케이션에서 원하는 모양으로 직접 변환 : V6

권장 순서

  1. 엔티티 조회방식으로 우선 접근
    1. 페치조인으로 쿼리 수를 최적화
    2. 컬렉션 최적화
      1. 페이징 필요 : hibername.default_batch_fetch_size 또는 @BatchSize로 최적화
      2. 페이징 필요 X : 페치 조인 사용
  2. 엔티티 조회 방식으로 해결이 안되면 DTO 조회 방식 사용
  3. DTO 조회 방식으로 해결이 안되면 NativeSQL or 스프링 JdbcTemplate 사용

엔티티 조회 방식은 페치 조인이나, hibername.default_batch_fetch_size , @BatchSize 같이
코드를 거의 수정하지 않고, 옵션만 약간 변경해서, 다양한 성능 최적화를 시도할 수 있다.
반면에, DTO를 직접 조회하는 방식은 성능을 최적화 하거나 성능 최적화 방식을 변경할 때 많은 코드를 변경해야 한다.

개발자는 성능 최적화와 코드 복잡도 사이에서 줄타기를 해야 한다. 항상 그런것은 아니지만, 보통 성능 최적화는
단순한 코드를 복잡한 코드로 몰고간다.
엔티티 조회 방식은 JPA가 많은 부분을 최적화 해주기 때문에, 단순한 코드를 유지하면서, 성능을 최적화 할 수 있다.
반면에 DTO 조회 방식은 SQL을 직접 다루는 것과 유사하기 때문에, 둘 사이에 줄타기를 해야 한다.

DTO 조회 방식의 선택지

  • DTO로 조회하는 방법도 각각 장단이 있다. V4, V5, V6에서 단순하게 쿼리가 1번 실행된다고 V6이 항상 좋은 방법인 것은 아니다.
  • V4는 코드가 단순하다. 특정 주문 한건만 조회하면 이 방식을 사용해도 성능이 잘 나온다. 예를 들어서 조회한 Order 데이터가 1건이면, OrderItem을 찾기 위한 쿼리도 1번만 실행하면 된다.
  • V5는 코드가 복잡하다. 여러 주문을 한꺼번에 조회하는 경우에는 V4 대신에 이것을 최적화한 V5 방식을 사용해야 한다.
    예를 들어서 조회한 Order데이터가 1000건인데, V4 방식을 그대로 사용하면, 쿼리가 총 1+1000번 실행된다.
    여기서 1은 Order를 조회한 쿼리고, 1000은 조회된 Order의 row 수이다. V5방식으로 최적화 하면 쿼리가 총 1+1번만 실행된다. 상황에 따라 다르겠지만 운영 환경에서 100배 이상의 성능차이가 날 수 있다.
  • V6는 완전히 다른 접근 방식이다. 쿼리 한번으로 최적화 되어서 상당히 좋아보이지만, Order를 기준으로 페이징이 불가능하다.
    실무에서는 이정도 데이터면 수백이나, 수천건 단위로 페이징 처리가 꼭 필요하므로, 이 경우 선택하기 어려운 방법이다.
    또한 데이터가 많으면 중복 전송이 증가해서 V5와 비교해서 성능 차이도 미비하다.
반응형
저작자표시

티스토리툴바