[Spring]OSIV와 성능 최적화

 

OSIV란?

---

Open Session In View의 줄임말로, JPA에서 EntityManager의 역할을 하이버네이트에서는 Session이 한다.
JPA에서는 Open EntityManager In View라 한다. (줄임말은 그대로 OSIV)
 

OSIV ON

---

spring.jpa.open-in-view: true 
#default 값은 true

최초 데이터베이스 커넥션 시작 시점부터 API 응답이 끝날 때까지 영속성 컨텍스트와 데이터베이스 커넥션을 유지한다.
보통 서비스 계층에서 DB 트랜잭션을 시작할 때, 영속성 컨텍스트가 DB 커넥션을 가져온다.
OSIV값이 true라면, 서비스 계층의 @Transactional 메서드를 벗어나도 컨트롤러 계층에서까지 커넥션을 계속 유지하기에 지연 로딩을 가능하게 한다.
하지만, 이는 너무 오랜 시간 동안 데이터베이스 커넥션 리소스를 사용하기에, 실시간 트래픽이 중요한 애플리케이션에서는 커넥션이 모자랄 수 있고 장애로 이어질 수 있다.
 

OSIV OFF

---

spring.jpa.open-in-view: false

OSIV값이 false라면, 서비스 계층의 @Transactional 메서드를 벗어나면 영속성 컨텍스트를 닫고, 데이터베이스 커넥션도 반환한다. 그렇기에 커넥션 리소스를 낭비하지 않는다.
이 경우, 모든 지연로딩을 @Transactional 메서드 안에서 처리해야 하므로 메서드 안에 코드가 많아진다는 단점이 있다.
 

커맨드와 쿼리 분리

---

 
OSIV를 끈 상태로 위의 단점인 복잡성을 관리하는 방법으로 Command와 Query를 분리하는 방법이 있다.
단순 조회 로직과 비즈니스 로직에는 차이점이 있다.
비즈니스 로직은 특정 엔티티를 등록하거나 수정하는 것이므로 성능에 큰 문제가 되지 않는다.
하지만, 조회 로직의 경우 복잡한 화면을 출력해야 하므로 성능을 최적화하는 것이 중요하다.
그렇기에, 이 둘을 명확하게 분리하는 것은 유지보수 관점에서 충분한 의미가 있다.
필자의 경우는 Provider와 Service로 분리한다.

1. Provider: 조회(Read)와 관련된 곳으로, DB에서 조회한 값을 가공해 결과를 추출. @Transactional(readOnly = true)
2. Service: 등록(Create), 수정(Update), 삭제(Delete)와 관련된 곳으로, 비즈니스 로직을 처리

참고: 영한님은 고객 서비스의 실시간 API는 OSIV를 끄고, ADMIN처럼 커넥션을 많이 사용하지 않는 곳에서는 OSIV를 켜는 것을 추천하십니다.