OSIV 성능 최적화

KOSE·2022년 10월 24일

spring

목록 보기

2/9

안녕하세요. OSIV의 성능 최적화를 정리하고자 글을 작성하게 되었습니다.

1. OSIV 정의

OSIV(Open Session In View)는 영속성 컨텍스트를 뷰까지 열어두는 기능입니다.
영속성 컨텍스트가 유지되면 엔티티도 영속 상태로 유지되므로, 뷰에서도 지연 로딩을 사용할 수 있습니다. OSIV는 스프링이 실행될 때 "WARN .... spring.jpa.open-in-view is enabled by default."라는 문구로 확인할 수 있습니다.

2. 영속성 컨텍스트를 뷰까지 열어두는 기능?

지연로딩은 해당 엔티티가 실행이 되지 않는다면 프록시 형태로 존재합니다. 따라서, OSIV가 ON인 상태라면, Controller 단계까지 프록시가 유효하므로, 영속 상태인 엔티티를 호출하면, 지연로딩이 실행되면서 데이터를 받아올 수 있습니다.

예시)

//application.yml
spring.jpa.open-in-view: true

(open-in-view는 default: true)


//MemberController

@GetMapping("/members")
    public String list(Model model) {
        List<Member> members = memberService.findMembers();
        List<Order> order = members.get(0).getOrders();
        System.out.println("order.get(0).getId() = " + order.get(0).getId());
        model.addAttribute("members", members);
        return "members/memberList";
    }


//MemberRepository

public List<Member> findMembers() {
        return memberOldRepository.findAll();
    }

open-in-view true로 인해, MemberRepository의 findMembers() 메소드가 실행되면, Member의 필드에 해당하는 Order의 객체는 지연로딩 상태입니다. 즉, Member가 영속성 컨텍스트 상태가 되었으므로, Controller에서 member.get(0).getOrders()로 Order를 호출하면 지연로딩이 실행되면서 Order 값을 얻어올 수 있습니다. 실제 출력 결과를 보면 다음과 같습니다.
-- order.get(0).getId() = 7

하지만 open-in-view 속성을 false로 바꾸면, 다음과 같은 에러를 확인할 수 있습니다.

//application.yml
spring.jpa.open-in-view: false

//postman 결과:
{
    "timestamp": "2022-10-24T07:40:39.173+00:00",
    "status": 500,
    "error": "Internal Server Error",
    "trace": "org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: ... }

이는, 이미 트랙잭션 범위 안에서 영속성 컨텍스트가 끝난 상태이므로, 리포지토리에서 받아온 객체에서 Order를 호출할 경우, 컨텍스트에 존재하지 않으므로 에러가 난 상황입니다.

3. OSIV 동작 원리

스프링 프레임워크가 제공하는 OSIV는 비즈니스 계층에서 트랙잭션을 사용하는 OSIV입니다.
영속성 컨텍스트는 사용자의 요청 시점에서 생성이 되지만, 데이터를 쓰거나 수정할 수 있는 트랙잭션은 비즈니스 계층에서만 사용할 수 있도록 트랜잭션이 일어납니다.
우리가 기본적으로 사용하는 스프링은 open-in-view가 true인 상태입니다. 따라서, 위에서 에러가 난 상황은 동작원리를 보면서 파악이 가능합니다.

3.1 OSIV on 동작 원리

클라이언트의 요청이 들어오면, 서블릿 필터나, 스프링 인터셉터에서 영속성 컨텍스트를 생성합니다.

서비스 계층에서 @Transactional로 트랜잭션을 시작하면, 영속성 컨텍스트를 찾아온 후, 트랜잭션을 시작합니다.

서비스 계층이 끝나면 트랜잭션을 커밋한 후, 영속성 컨텍스트를 플러시합니다. 이때, 영속성 컨텍스트는 커넥션 상태입니다.

컨트롤러와 뷰까지 영속성 컨텍스트가 유지되므로, 조회한 엔티티는 영속 상태입니다.

서블릿 필터나, 스프링 인터셉터로 요청이 돌아오면 영속성 컨텍스트는 종료됩니다. (플러시를 호출하지 않고 종료)

OSIV가 on이면, 코드를 작성하는데 있어서 편리함이 있지만, 커넥션을 오랜 시간 유지한다는 점에서 실시간 트래픽이 많은 서비스의 경우 과부하가 올 수 있습니다.

3.2 OSIV off 동작 원리

OSIV를 끄면 트랜잭션을 종료하면, 영속성 컨텍스트를 종료합니다.

데이터베이스 커넥션도 반환합니다. 따라서, 커넥션 리소스를 낭비하지 않습니다.

OSIV를 끄면 모든 지연로딩을 트랜잭션 안에서 처리해야 하고, view template에서 지연로딩이 동작하지 않으므로 트랜잭션 종료 전에 미리 지연 로딩을 강제로 호출해야합니다. (fetch join)

4. 커멘드와 쿼리 분리

실무에서는 OSIV를 끈 상태로 복잡성을 관리하는 좋은 방법이 존재한다고 합니다.
이는 Command와 Query를 분리하는 방법입니다.

OrderService

OrderService: 핵심 비즈니스 로직

OrderQueryService: 화면이나 API에 맞춘 서비스 (주로 읽기 전용 트랜잭션 사용)

4번의 경우, 다음 포스팅에서 자세하게 분리하는 과정을 설명하도록 하겠습니다.

잘못된 점이 있다면, 댓글 부탁드립니다~!
읽어주셔서 감사합니다!

참고 자료:
1. 인프런 김영한님 강의 - 실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
2. https://ykh6242.tistory.com/entry/JPA-OSIVOpen-Session-In-View%EC%99%80-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94