실전 적용 - API 개발과 성능 최적화

1. 실무에서는 엔티티를 API 스펙에 노출하면 안된다!

엔티티를 request, response 파라미터로 받으면, 

• 엔티티가 변경되면 API 스펙이 변한다..!
• 엔티티에 프레젠테이션 레이어의 검증을 위한 로직이 들어간다(@NotEmpty 등등). 
  실무에서는 회원 엔티티를 위한 API가 다양하게 만들어지는데, 한 엔티티에 각각의 API를 위한 모든 요청 요구사항을 담기는 어렵다.
• 추가로 컬렉션을 직접 반환하면 항후 API 스펙을 변경하기 어렵다.
  (별도의 Result 클래스 생성으로 해결. Result 클래스로 컬렉션을 감싸면 향후 필요한 필드를 추가할 수 있다.)
• 지연 로딩 설정으로 인해 프록시 빈이 주입되었기 때문에 json으로 처리도 불가하다.
  특히 양방향 연관관계일 경우 json으로 바꾸면서 무한 루프에 빠질 수 있다.

=> DTO를 활용하여 엔티티와 API 스펙을 명확하게 분리해야 엔티티가 변해도 API 스펙이 변하지 않는다.

 

 

2. 페치 조인 최적화

JPQL 사용 시 연관관계가 있을 경우 즉시로딩이든 지연로딩이든 N+1 문제가 발생한다.

# 즉시로딩을 사용해도 N+1 문제가 발생하는 이유

em.find() 등을 통해서 엔티티 하나만 조회할 때는 즉시 로딩으로 설정하면 연관된 팀도 한 쿼리로 가져오도록 최적화 되지만 JPQL을 사용하면 이야기가 달라진다.

JPQL은 연관관계를 즉시로딩으로 설정하는 것과 상관없이 JPQL 자체만으로 SQL로 그대로 번역되기 때문이다.

ex) 

1. 멤버 전체를 조회하기 위해 JPQL 실행 select m from member m

2. JPQL은 EAGER와 무관하게 SQL로 그대로 번역 -> select m.* from member

3. JPQL 결과가 member만 조회하고, team은 조회하지 않음

4. member와 team이 즉시 로딩으로 설정되어 있기 때문에 연관된 팀을 각각 쿼리를 날려서 추가 조회 (N+1)

 

# 지연 로딩 예시

1. order 조회 1번(order 조회 결과 수가 N이 된다.)

2. N번 루프를 돌면서 조회하여 지연 로딩 시

• order -> member 지연 로딩 조회 N 번
• order -> delivery 지연 로딩 조회 N 번

=> 엔티티를 페치 조인(fetch join)을 사용해서 쿼리 1번에 조회하자.
구성하고 있는 연관 엔티티를 사용하지 않더라도 프록시로 대체하는게 아니고 한 번에 전부 땡겨온다.

페치 조인으로 order -> member , order -> delivery 는 이미 조회 된 상태이므로 지연로딩X

Order만 조회했지만 Member, Delivery도 조회된다

 

※ 참고로 fetch join을 사용하지 않고 DTO로 바로 조회하는 방법이 있지만,
지저분하고, API 스펙에 리포지토리가 맞추게 되며, 재사용성이 떨어진다.
(엔티티로 바로 조회하면 리포지토리 재사용성도 좋고, 개발도 단순해진다)

DTO 조회 장점: fetch join을 사용하지 않고, SELECT 절에서 원하는 데이터를 직접 선택하므로 DB 애플리케이션 네트웍 용량 최적화(생각보다 미비)

 

[정리] 쿼리 방식 선택 권장 순서

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

---

컬렉션 조회 최적화

[요약] 컬렉션 fetch join 시 데이터 row 수 뻥튀기 되므로 -> 메모리에서 페이징(위험) => 꼭 해야한다면 지연로딩+batch_fetch

 

컬렉션 로딩 관련 두가지 문제

• 즉시 로딩 : Cartesian 곱 (데이터 뻥튀기)
• 지연 로딩 : N+1 문제 (JPQL 사용 시 즉시 로딩도 발생. 일단 SQL을 날리고 즉시 로딩하므로..)
  => fetch join, @EntityGraph, batch_fetch

상황에 따라 둘 사이의 균형을 잡아야 한다.

 

컬렉션 페치 조인의 한계  (by 데이터 뻥튀기)

일대다 조인이 있으면 데이터베이스 row가 증가하여 그 결과 같은 order 엔티티 수가 뻥튀기 된다. 그래서 distinct가 필요한데, JPA의 distinct는 SQL에 distinct를 추가하고(SQL의 distinct는 row 전체가 같아야해서 사실상 의미x),
추가로 애플리케이션 단에서 같은 엔티티가 조회되면 중복을 걸러준다.

참고로 hibernate6부터는 distinct를 생략해도 엔티티 중복을 제거해준다. 따라서 Order가 DB상 4개 조회됐으나 java 상 2개가 된다.

단점 1: 컬렉션 페치 조인을 사용하면 페이징이 불가능하다.

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

단점 2 : 컬렉션 페치 조인은 1개만 사용할 수 있다.

• 컬렉션 둘 이상에 페치 조인을 사용하면 안된다. 데이터가 부정합하게 조회될 수 있다.
  (row수가 n*m개이면, 무슨 기준으로 중복을 제거해야 하는가?)

 

페이징과 한계 돌파

대부분의 페이징 + 컬렉션 엔티티 조회 문제는 아래 방법으로 해결할 수 있다.

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

1. 먼저 ToOne(OneToOne, ManyToOne) 관계를 모두 페치조인 한다.
   (ToOne 관계는 row수를 증가시키지 않으므로 페이징 쿼리에 영향을 주지 않는다.)
2. 컬렉션은 지연 로딩으로 조회한다. (1 기준으로 페이징 할거니까, 다의 데이터는 불러오지 말자)
3. 지연 로딩 성능 최적화를 위해 hibernate.default_batch_fetch_size , @BatchSize 를 적용한다.
   • 이 옵션을 사용하면 컬렉션이나, 프록시 객체를 한꺼번에 설정한 size 만큼 IN 쿼리로 조회한다.
   • hibernate.default_batch_fetch_size: 글로벌 설정 (기본 설정 X)
   • @BatchSize: 개별 최적화
   • @Fetch(FetchMode.SUBSELECT) : sub 쿼리로 전체 조회(사이즈를 설정하지 않는 버전이라고 생각하면 됨)

1. ToOne(OneToOne, ManyToOne) 관계는 모두 페치조인

2. 컬렉션은 지연 로딩으로 조회. 조회 시 성능 최적화

select o.order_id, o.order_item_id, o.count, o.item_id, o.order_price 
  from order_item o
 where o.order_id in (1, 2)//in 쿼리로 조회

 

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

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

참고: 스프링 부트 3.1 - 하이버네이트 6.2 변경사항 - array_contains
하이버네이트 6.2 부터는 where in 대신에 array_contains 를 사용한다.
이미 실행된 SQL 구문 파싱된 결과를 내부에 캐싱하여 재사용하기 위함이다.
아래 문법은 in (?,?,?) 과 달리 ?에 바인딩 되는 것이 딱1개 이다. 배열 1개가 들어가는 것이라 재사용 가능한 쿼리다.
select ... where array_contains(?, item.item_id)

 

정리

권장 순서

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

엔티티 조회 방식은 JPA가 많은 부분을 최적화 해주기 때문에, 단순한 코드를 유지하면서, 성능을 최적화 할 수 있다.
페치 조인이나, hibernate.default_batch_fetch_size , @BatchSize 같이 코드를 거의 수정하지 않고, 옵션만 약간 변경해서, 다양한 성능 최적화를 시도할 수 있다.

반면에 DTO를 직접 조회하는 방식은 성능을 최적화 하거나 성능 최적화 방식을 변경할 때 많은 코드를 변경해야 한다.

DTO 직접 조회

• JPA에서 DTO를 직접 조회(V4, 1+N)
  → 코드가 단순. 특정 주문 한건만 조회하면 이 방식을 사용해도 성능이 잘 나온다 
• 컬렉션 조회 최적화 - 일대다 관계인 컬렉션은 IN 절을 활용해서 메모리에 미리 조회해서 최적화(V5, 1+1)
  → 코드가 복잡하다. 여러 주문을 한꺼번에 조회하는 경우에는 V4 대신에 이것을 최적화한 V5 방식을 사용해야.
• 플랫 데이터 최적화 - JOIN 결과를 그대로 조회 후 애플리케이션에서 원하는 모양으로 직접 변환(V6, 1)
  → 쿼리 한번으로 최적화 되어서 상당히 좋아보이지만, Order를 기준으로 페이징이 불가능하다. 실무에서는 이정도 데이터면 수백이나, 수천건 단위로 페이징 처리가 꼭 필요하므로, 이 경우 선택하기 어려운 방법이다. 그리고 데이터가 많으면 중복 전송이 증가해서 V5와 비교해서 성능 차이도 미비하다

---

OSIV와 성능 최적화

OSIV는 영속성 컨텍스트가 API 응답할 때까지 유지하는 설정이다.

- Open Session In View: 하이버네이트

- Open EntityManager In View: JPA

(최초 하이버네이트에서 OSIV를 써와서 지금까지 관례상 OSIV라 한다.)

 

OSIV ON (기본 설정)

spring.jpa.open-in-view : true 기본값. 영속 상태가 요청부터 응답까지 지속. 트랜잭션 범위 내에서만 수정 가능.

 

OSIV가 on 일 때, 애플리케이션 시작 시점에 warn 로그를 남기는 것은 이유가 있다.

OSIV 전략은 트랜잭션 시작처럼 최초 데이터베이스 커넥션 시작 시점부터 API 응답이 끝날 때까지 영속성 컨텍스트와 데이터베이스 커넥션을 유지한다. 그래서 지금까지 View Template이나 API 컨트롤러에서 지연 로딩이 가능했던 것이다.

지연 로딩은 영속성 컨텍스트가 살아있어야 가능하고, 영속성 컨텍스트는 기본적으로 데이터베이스 커넥션을 유지한다.(그래야 필요시 DB에서 데이터 가져오고 저장)  이것 자체가 큰 장점이다. 개발을 단순하게 할 수 있다.

Repository에서 엔티티를 조회하고, Controller에서 지연 로딩

 

그런데 이 전략은 너무 오랜시간동안 데이터베이스 커넥션 리소스를 사용하기 때문에, 실시간 트래픽이 중요한 애플리케이션에서는 커넥션이 모자랄 수 있다. 이것은 결국 장애로 이어진다.

예를 들어 컨트롤러에서 외부 API를 호출하면 외부 API 대기 시간 만큼 커넥션 리소스를 반환하지 못하고 유지해야 한다.

 

OSIV OFF

spring.jpa.open-in-view: false

spring.jpa.open-in-view: false OSIV 종료

 

OSIV를 끄면 트랜잭션을 종료할 때 영속성 컨텍스트를 닫고, 데이터베이스 커넥션도 반환한다. 따라서 커넥션 리소스를 낭비하지 않는다.

 

지연 로딩은 영속성 컨텍스트의 존재에 기반한다. 따라서 지연 로딩 시에 영속성 컨텍스트가 존재하지 않을 경우 LazyInitializationException이 발생한다.

따라서 OSIV를 끄면 view template에서 지연로딩이 동작하지 않기 때문에 모든 지연로딩을 트랜잭션 안에서 처리해야 한다. 그래서 지금까지 작성한 많은 지연 로딩 코드를 트랜잭션 안으로 넣어야 하는 단점이 있다. 결론적으로 트랜잭션이 끝나기 전에 지연 로딩을 강제로 호출해 두어야 한다

(트랜잭션 시작 시점에 영컨, DB커넥션을 얻어오고, 트랜잭션 종료 시점에 커넥션 반납)

기존 코드로는 OSIV를 끄면 지연로딩을 컨트롤러에서 처리하지 못해서 위와 같은 오류가 발생했다.

 

그렇다면 OSIV를 켜고 끄는 기준은 무엇으로 하며, 끌 경우 어떻게 처리하면 좋을까?

=> 고객 서비스의 실시간 API는 OSIV를 끄고, ADMIN 처럼 커넥션을 많이 사용하지 않는 곳에서는 OSIV를 켜자.

 

커맨드와 쿼리 분리

실무에서 OSIV를 끈 상태로 복잡성을 관리하는 좋은 방법이 있다. 바로 Command와 Query를 분리하는 것이다

( 참고: https://en.wikipedia.org/wiki/Command–query_separation )

 

보통 비즈니스 로직은 특정 엔티티 몇 개를 등록하거나 수정하는 것이므로 성능이 크게 문제가 되지 않는다. (커맨드성)

그런데 복잡한 화면을 출력하기 위한 쿼리는 화면에 맞추어 성능을 최적화 하는 것이 중요하다. 하지만 그 복잡성에 비해 핵심 비즈니스에 큰 영향을 주는 것은 아니며, 화면은 수정도 잦아서 배포 주기도 다르다.

그래서 크고 복잡한 애플리케이션을 개발 할 때, 이 둘의 관심사를 분리하는 선택은 유지보수 관점에서 의미가 있다.

 

아래처럼 핵심 비즈니스용, 화면/API용 서비스를 분리하고 서비스 단에 트랜잭션을 거는 것이다. 

• OrderService: 핵심 비즈니스 로직
• OrderQueryService: 화면이나 API에 맞춘 서비스 (주로 읽기 전용 트랜잭션 사용)

보통 서비스 계층에서 트랜잭션을 유지한다. 두 서비스 모두 트랜잭션을 유지하면서 지연 로딩을 사용할 수 있다

보통 컨트롤러에선 @Transactional을 사용하지 않으므로, 쿼리용 서비스 생성하여 호출.

 

---

참고 자료 & 이미지 출처
실전! 스프링 부트와 JPA 활용2 (김영한 님)
https://github.com/jaelyangChoi/jpashop (소스코드)