JPA 성능 개선팁

인프런 김영한님

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

대부분 성능 문제는 조회에서 발생한다. 앱과 JPA단에서 할 수 있는 최적화를 알아보자.

 

💭 요약

1. 우선 Entity로 객체지향적으로 조회한다.
- 연관 객체 조회는 Lazy를 기본으로 깔고, 조회할 때 join fetch로 사용하는 연관 객체를 한방쿼리로 가져온다.

2. Entity에서 연관관계인 컬렉션 (List, Set)을 가져오고 싶다면

- 페이징이 필요없다면 join fetch로 가져온다. (단 컬렉션이 1개일 경우에만 패치조인 가능)

- 페이징이 필요하다면 그냥 Lazy로 냅두고 @BatchSize (hibernate.default_batch_fetch_size 추천)를 사용한다.

- 사실 이정도만 하더라도 대부분 서비스에서는 문제 없다.

 

3. 이 단계로 해결이 안되는 대형 서비스라면 그냥 Redis 같은 캐시를 쓰자.

- 참고로 DTO 를 캐시해야한다. Entity를 캐시(2차캐시)하는건 정합성 문제로 실무에서 사용하기 너무 까다롭다.

- 사실 그정도의 대형서비스라면, 조회에서는 JPA를 포기하고 MyBatis나 Native SQL 생 쿼리를 함께 사용한다.

 

4. OSIV는 쓰지말자. 참고로 기본값이 true라서 직접 설정해줘야한다.

spring.jpa.open-in-view : true // 기본값

 

---

💭 API에서 Entity를 직접 조회하지  마라.

이 정도는 당연한 상식이지만, 아래와 같이 넘어가면 안된다. 안되는 이유를 알고 있어야 한다.

🤦‍♂️ : 왜 DTO나 Service를 사용하냐고..? 그냥 남들이 다 그렇게 하니까?"

• 도메인이 API에 의존성이 생긴다. 나중에 변경, 유지보수하기 매우 어렵다.
• 캡슐화가 깨진다. 값을 어디서 꺼냈는지, 어디서 변경되었는지 알기 어렵다.
• JPA 연관 관계 때문에 1+N 문제가 발생하기 쉽다. ( 회원 1건 조회 -> 연관된 주문 객체 N건 조인해서 같이 조회)

@GetMapping("/api/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;
}

 

 

📑 해결책 - Lazy와 패치조인

1. 연관관계는 Lazy를 기본으로 사용한다.

- 오해하면 안되는게, Lazy는 만능이 아니다. 연관 관계를 사용하는 시점에 결국 1+N문제가 발생한다.

 

2. 절대로 Entity 를 직접 노출시키지 않는다. DTO를 사용한다.

3. 연관관계를 사용할 때에는 패치조인(join fetch)으로 가져온다

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

// orderRepository.findAllWithMemberDelivery
public List<Order> findAllWithMemberDelivery() {
    return em.createQuery(
            "select o from Order o" +
                " join fetch o.member m" + // Inner Join 으로 o.member를 가져온다.
                " join fetch o.delivery d", Order.class) // o.delivery도 가져온다.
        .getResultList();
}

JPQL 조인에 fetch를 사용하면는 연관 객체(또는 컬렉션)까지 Inner Join을 사용해서 한 쿼리로 가져온다.

참고로 Lazy에 그냥 조인만 사용(select m form Member m join m.team)은 연관 객체(team) 값을 미리 가져오지 않는다.

 

 

4. (그래도 성능이 안나온다면) JPA를 포기하고, 해당 DB의 SQL을 직접 작성한다. 

// JPA Native Query를 이용해도 되고, 그냥 JDBC Template 을 사용해도 된다. (Mybatis 등)
String sql = "SELECT ID, AGE, NAME, TEAM_ID" +
             " FROM MEMBER WHERE AGE > ?";
 
Query nativeQuery = em.createNativeQuery(sql, Member.class)
                      .setParameter(1, 20);
 
List<Member> resultList = nativeQuery.getResultList();

 

 

🙄 : 그냥 원하는 값만 쿼리로 뽑아서 DTO로 반환하면 안되나요?

Entity를 거치지 않고, 일반 쿼리문처럼 값을 선택해서 가져올 수 있다. DB I/O 성능이 조금 좋아지긴 한다.

단 재사용성이 떨어지고 DTO가 리포지토리에 들어가서 추천하는 방법은 아니다. (API와 DB에 의존성이 생긴다.)

@GetMapping("/api/orders")
public List<OrderSimpleQueryDto> ordersV4() {
    return orderSimpleQueryRepository.findOrderDtos();
}

public List<OrderSimpleQueryDto> findOrderDtos() {
    return em.createQuery(
            "select new package.repository.order
              .simplequery.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();
}

 

모든 건 트레이드 오프이다. 대부분의 비즈니스 서비스는 이런 코드가 안좋다.

하지만 변경할 일이 없고, 통계 데이터를 요청하는 API 트래픽이 많다면, 이런 방법도 고민 대상에 들어갈 수 있다.

 

 

---

💭 연관관계 컬렉션 조회(OneToMany)

@OneToOne, @ManyToOne 관계는 필요할 때 패치조인으로 같이 가져오면 된다.

그렇다면 @OneToMany, 즉 연관 컬렉션은 어떻게 해야할까. 그냥 패치조인으로 통째로 다 가져오면 되는걸까? 

order에서 List<OrderItem>을 가져올려면?

 

 

🙄 : ?? 그냥 연관관계인 컬렉션도 join fetch로 가져오면 되는거 아닌가요?

맞는 말이다. 하지만 아무 생각없이 사용하면 큰일난다.

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

    return result;
}

// orderRespoitory.findAllWithItem()
public List<Order> findAllWithItem() {
    return em.createQuery(
            "select o from Order o" +
                " join fetch o.member m" +
                " join fetch o.delivery d" +
                " join fetch o.orderItems oi" + // List<OrderItem> 패치조인
                " join fetch oi.item i", Order.class) // OrderItem.Item 패치조인
        .getResultList();
}

이 패치조인은, 아래의 SQL문을 만든다.

Select * from orders o
join order_item oi on o.order_id = oi.order_id

 

DB공부를 했다면 알겠지만 이런 형식의 조인 쿼리는 똑같은 데이터를 배로 뻥튀기시켜버린다.
Order가 단 1개 밖에 없더라도, OrderItem이 N개라면

조인했을 때 중복된 Order 데이터로 N개가 찍히게되버린다. (여러 개라면 그만큼 행 수가 곱해진다.)

테이블을 조인했기 때문에 똑같은 Order_ID 를 여러줄로 복사해서 조회한다.

 

실제로 하이버네이트에 2개이상의 패치조인(entity -> toMany -> toMany)을 시도하면 `MultipleBagFetchException` 발생시킨다.

 

📑 해결책 - 패치조인에 distinct 를 넣어서 중복을 제거한다.

실제로 JPQL 에서 distinct 키워드는 DB SQL에 그대로 붙여주는 효과 외에 한가지 기능을 더해준다.

바로 Entity ID를 이용해 중복된 데이터가 존재한다면, JPA 앱 메모리상에서 중복을 제거해준다.

// orderRespoitory.findAllWithItem()
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" + // List<OrderItem> 패치조인
                " join fetch oi.item i", Order.class) // OrderItem.Item 패치조인
        .getResultList();
}

 

 

🧨 주의 (페이징) - 쿼리는 하나지만, 데이터 중복은 그대로다.

여기서 중요한점은, 앱 상에서는 중복이 해결된 것 같지만 요청 쿼리문은 그대로 라는 점이다.

조인된 테이블은 Order 만 중복일 뿐, Item에 대한 정보는 중복이 아니다. 

 

1. 아래와 같은 페이징 쿼리가 있다고 생각해보자.

public List<Order> findAllWithMemberDelivery() {
    return em.createQuery(
            "select o from Order o" +
                    " join fetch o.member m" +
                    " join fetch o.delivery d", Order.class)
            .setFirstResult(1) // 시작지점
            .setMaxResults(100) // 페이지 개수
            .getResultList();
}

테스트할 때에는 앱 상에서 중복이 제거되니까 정상작동 하는 것처럼 보인다.

하지만 실제로는? 말도 안되는 개수의 쿼리가 뻥튀기되어 찍히고 있다. 즉, 컬렉션을 패치조인 해버리면 페이징이 사실 상 불가능해진다.

 

2. 한 쿼리에서 컬렉션에 대한 패치조인은 단 한 줄만 사용할 수 있다.

하나의 Order에서 List<OrderItems> , List<SpecialItems> 이렇게 2개 이상의 컬렉션을 패치조인하면 절대 안된다.

왜냐하면 데이터가 엄청나게 뻥튀기 되어 [ 회원수 * 아이템 수 *  아이템 수 ] 의 미친 한방 쿼리가 나오기 때문이다.

실제로 이런식의 패치조인의 사용은 정합성을 보장할 수 없기에 아래와 같은 하이버네이트 경고 로그가 찍힌다.

하이버네이트 경고. 말도 안되게 많은 데이터를 불러와서, 메모리에서 페이징을 시도한다. (최악의 경우 메모리 부족으로 앱이 죽는다.)

Order - List&amp;amp;amp;lt;OrderItem&amp;amp;amp;gt; 만 해도 이렇게 중복되는데, 여기에 List&amp;amp;amp;lt;SpecialItem&amp;amp;amp;gt; 한개를 더 조인하면..?

 

 

📑 페이징 해결책 - @BatchSize

1. 먼저 ToOne 관계만 따로 패치조인으로 가져온다.

2. 컬렉션은 패치조인 하지않고, 기존 Lazy로 그대로 둔다. (이대로 두면 1+N이 발생한다.)

@GetMapping("/api/orders")
public List<OrderDto> orders_page(
    @RequestParam(value = "offset", defaultValue = "0") int offset,
    @RequestParam(value = "limit", defaultValue = "100") int limit) {

    List<Order> orders = orderRepository.findAllWithMemberDelivery(offset, limit);
    
    // order.OrderItems 를 꺼낼 때 1+N 발생
    // order.OrderItems.Item 을 꺼내면서 1(Order) + N(OrderItems) + N(Items) 개의 쿼리 완성
    List<OrderDto> result = orders.stream().
        .map(o -> new OrderDto(o)) 
        .collect(toList());

    return result;
}

public List<Order> findAllWithMemberDelivery(int offset, int limit) {
    return em.createQuery(
            "select o from Order o" +
                " join fetch o.member m" +
                " join fetch o.delivery d", Order.class) // 일단 컬렉션은 패치조인 안한다.
        .setFirstResult(offset) // 시작지점
        .setMaxResults(limit) // 페이지 개수
        .getResultList();
}

 

3. @BatchSize 를 사용한다. (또는 hibernate.default_batch_fetch_size 설정을 이용해 전역적으로 설정한다.)

이 옵션을 사용하면 컬렉션이나 프록시 객체를 설정한 개수만큼 [ Where IN (pk1, pk2 ...) ]로 조회한다.

• 테이블마다 key로 찝어서 조회하는거라, 중복 데이터가 없다. (SQL 정규화)
• Where in (key)는 동등비교(=)와 동일한 성능이라 DB에도 최적화 되있다.

@BatchSize(size = 100) // 엔티티에 설정
@Entity
public class Item {
    ...
}


@Entity
public class Parent {

    @BatchSize(size = 100) // 컬렉션 필드에 설정
    @OneToMany(mappedBy = "parent")
    private List<Child> children = new ArrayList<>();
}

spring: # resource/application.yml
  jpa:
    hibernate:
      ddl-auto: create
    
    properties:
      hibernate:
        format_sql: true
        default_batch_fetch_size: 1000 # 기본 배치사이즈 (limit 1000)

 

@BatchSize를 사용하면 컬렉션이나 프록시 객체를 설정한 개수만큼 [ WHERE IN 쿼리 ]로 필요한 연관 값을 가져온다.

쿼리를 하나로는 못만들지만, 1+N+N 쿼리를 1+1+1 쿼리로 바꿀 수 있다.

참고로 100개를 조회하는데, @BatchSize(20)이라면 JPA는 쿼리를 5번 (100/20 = 5개) 날린다.

패치조인은 중복은 발생하지만, 쿼리는 단 1개가 찍힌다. (페이징은 사실상 불가능)

기존의 코드는 Order * OrderItems * Items 개수만큼 쿼리가 찍힌다.

 

DB에서의 Where In 사용

@BatchSize를 사용했을 때 JPA에 찍힌 쿼리

사용하는 ID (4,11)만 where in 한방 쿼리로 가져왔다.

 

 

🙄 : 쿼리가 적게 찍히도록 BatchSize를 크게하는게 좋을까요?

사실 DB와 회사마다 달라서 정답은 없지만, 최대 1000개를 안넘도록 설정해주는게 좋다.

• Where In 쿼리가 1000개가 넘어가면 DB 오류를 일으키는 경우가 종종 있어서 그 이상은 권장하지 않는다.
• 개수가 너무 많으면 한번에 처리해야할 요청 데이터가 상당히 커진다. 이는 DB와 앱 서버에 부담을 줄 수 있다.
• 개수가 작으면 DB, 앱서버에 부하는 줄겠지만, 그만큼 요청 횟수가 많아져서 네트워크 대기시간이 길어진다.

앱서버(WAS), DB에 부담을 주지않게 100으로 설정해놓고, 나중에 변경하는걸 추천한다. 

참고로 너무 크면 앱 메모리를 많이 사용해서 안된다는 말도 하는데, 이는 전혀 상관없는 이야기이다.

List<OrderItem>에 쿼리를 여러번 찍는다고해서, 절반만 채우고 API를 여러번 전송하지는 않는다. 결국 쿼리가 한방이든 여러방이든 앱에선 List가 가득 찰 때까지 기다리기 때문에 앱 메모리 사용량과는 상관없다.

 

 

+ 특별한 이유가 없다면 @BatchSize로 하나하나 설정하기 보다는, 아래처럼 전역적으로 설정 해놓는 걸 추천한다.

spring: # resource/application.yml
  jpa:
    hibernate:
      ddl-auto: create
    
    properties:
      hibernate:
        format_sql: true
        default_batch_fetch_size: 1000 # 기본 배치사이즈 (limit 1000)

 

 

📑 트레이드 오프 [ 컬렉션 패치조인 vs @BatchSize ]

그냥 @BatchSize를 전역적으로 사용하는걸 권장하지만, 성능 튜닝이 필요한 시점에는 컬렉션 패치조인도 생각해야한다.

 

물론 페이징에선 사용 불가능하지만, 그게 아니라면 컬렉션 패치조인이 한방 쿼리가 나오기에 성능이 더 좋을 수 있다.

결국  [DB 네트워크 호출 횟수]와 [전송 데이터량]의 트레이드 오프를 고려해야한다.

 

컬렉션이 딱 하나이고 데이터가 몇 개 안된다면 패치조인 한방쿼리로 가져오는게 성능이 좋다.

하지만 데이터가 1000건이 넘는다면, 긴 한방 쿼리보다 몇번 더 호출하더라도 @BatchSize 를 쓰는게 성능이 좋다.

 

 

📑 다른방법 - 만약 연관 컬렉션을 DTO로 직접 조회하고 싶다면

Entity를 만들지 않고 DTO로 바로 조회하는 경우 @BatchSize를 사용할 수 없는데, 이때는 어떻게 해야할까?

 List<OrderDto> 안에 List<OrderItemDto> 가 존재한다.

1. ToOne 관계를 먼저 조회한다. OrderDto에서 컬렉션 부분은 일단 비워둔다.

2. 반복문으로 ToMany 관계를 별도로 조회해서 하나씩 끼워넣는다. (반복 횟수만큼 쿼리 발생, 사실상 1+N 문제와 동일)

public List<OrderQueryDto> findOrderQueryDtos() {
    //루트 조회(toOne 코드를 모두 한번에 조회)
    List<OrderQueryDto> result = findOrders();

    //루프를 돌면서 컬렉션 추가(추가 쿼리 실행)
    result.forEach(o -> {
        List<OrderItemQueryDto> orderItems = findOrderItems(o.getOrderId());
        o.setOrderItems(orderItems);
    });
    return result;
}

private List<OrderQueryDto> findOrders() {
    return em.createQuery(
            "select new package.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();
}

private List<OrderItemQueryDto> findOrderItems(Long orderId) {
    return em.createQuery(
            "select new package.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();
}

 

 

이런 경우에는 쿼리를 반복하지말고, List<OrderId>를 만들어서 Where in 한방쿼리로 조회하자.

그리고 OrderDto에 OrderItemDto를 하나씩 매핑해주면 되는데, 이때 Map 자료형을 이용하면 간단하게 처리할 수 있다.

public List<OrderQueryDto> findAllByDto_optimization() {

    //루트 조회(toOne 코드를 모두 한번에 조회)
    List<OrderQueryDto> result = findOrders();

    //orderItem 컬렉션을 MAP 한방에 조회
    Map<Long, List<OrderItemQueryDto>> orderItemMap = findOrderItemMap(toOrderIds(result));

    //루프를 돌면서 컬렉션 추가(추가 쿼리 실행X)
    result.forEach(o -> o.setOrderItems(orderItemMap.get(o.getOrderId())));

    return result;
}

private Map<Long, List<OrderItemQueryDto>> findOrderItemMap(List<Long> orderIds) {
    List<OrderItemQueryDto> orderItems = em.createQuery(
            "select new package.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();

    return orderItems.stream() // 조회한 List<OrderItemDto> 를  Map<id, OrderItemDto> 로 변환
            .collect(Collectors.groupingBy(orderItemQueryDto -> orderItemQueryDto.getOrderId()));
}

 

 

💭 OSIV (Open Session In View) 끄기

여담으로 JPA에서는 Open EntityManager In View라고 부른다.

근데 기존의 하이버네이트에서 Open Session In View라고 사용했기에, OSIV라고 많이 사용한다.

 

이를 스프링 진형에서 인지했는지, 설정값은 open-in-view라고 이름을 지었다.

spring.jpa.open-in-view : true // 기본값

 

📑 OSIV를 왜 사용하는거죠?

JPA 의 지연로딩은 트랜잭션 범위를 벗어나면 (View에 전달된 이후에는) 쿼리 호출이 불가능하다.

그래서 트랜잭션이 끝나기전, 지연로딩된 값들이 필요하다면 미리 호출해둬야한다.

 

하지만 View에서 값이 필요있는지 없는지는 미리 알기 어렵다. 그래서 OSIV라는 기능을 제공한다.

 

OSIV는 쉽게말해 트랜잭션의 시작(DB 커넥션이 생성)부터 API 응답이 끝날 때 까지 영속성 컨텍스트와 DB 커넥션을 닫지않고 유지시켜주는 기능이다.

 

🙄 어 그럼 좋은거 아닌가요? 성능에 문제가 생길려나?

그렇다. 데이터베이스 커넥션을 너무 오랜시간 동안 사용한다.

만약 컨트롤러에서 외부 API를 호출한다면, 그 API의 대기시간만큼 커넥션이 유지가 되어있다.

 

이는 성능상에 문제도 있겠지만, 개발자가 쿼리가 실행되는 시점을 예상하기 어렵다.

그래서 되도록이면 OSIV를 끄는걸 추천한다. 특히 요즘 유행하는 SPA - Rest API 방식이면 딱히 필요없기도 하다.

(참고로 커넥션이 없는데 지연로딩을 시도하면 LazyInitializationException 예외가 발생한다.)

 

OSIV가 없어도 DTO, Application 계층 (Facade), 커맨드와 쿼리분리 (CQS)등으로 해결할 수 있다.

물론 어드민 페이지처럼 딱히 커넥션 관리가 중요하지않다면, OSIV를 사용하고 코드를 깔끔하게 두는게 나을 수 있다.