[JPA] OSIV 찍먹하기 2편 - 준영속 상태 엔티티를 지연 로딩하기 (FetchType.EAGER와 N+1 문제, fetch join)

🌱 들어가기 전

지난 포스팅에서는 준영속 상태의 엔티티는 지연 로딩할 수 없다고 말했다.

이는, 지연 로딩을 위한 프록시 객체를 초기화하기 위해 영속성 컨텍스트가 필요한데, 준영속 상태의 엔티티는 영속성 컨텍스트의 관리 범위에서 벗어났기 때문이다.

그렇다면, 준영속 상태의 엔티티는 어떻게 처리해야 할까?

 

---

 

🌱 글로벌 페치 전략을 LAZY에서 EAGER로 수정하기

간단하게 말하면 지연 로딩을 사용하지 말고, 즉시 로딩을 사용하자는 것이다 😅

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Crew {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    private String name;

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "wootecho_id", nullable = false, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT))
    private Wootecho wootecho;
}

크루 클래스의 fetch 전략을 EAGER로 설정하였다. (어차피 @ManyToOne의 디폴트 전략이 fetch이기 때문에 명시적으로 설정하지 않아도 똑같다.)

즉시 로딩을 사용하게 되면, Crew를 조회할 때 연관된 엔티티인 Wootecho 역시 함께 가져오게 된다.

실제로 쿼리를 확인해보자.

다음과 같이 Join을 통해 한 번에 가져온 것을 볼 수 있다.

 

 

💬 join을 통해 가져오는 거면 더 좋은 거 아니야? 

만약, crew 엔티티에 연관된 엔티티가 지금처럼 하나가 아니라 여러 개라면?

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Crew {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    private String name;

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "wootecho_id", nullable = false, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT))
    private Wootecho wootecho;

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "wootecho2_id", nullable = false, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT))
    private Wootecho wootecho2;

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "wootecho3_id", nullable = false, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT))
    private Wootecho wootecho3;
}

상당히 어지러운 쿼리가 나가는 것을 볼 수 있다. 심지어, 위 예제는 정말 간단한 예제인데도 여러 join이 걸리게 되는 것이다.

 

 

💬 N+1 문제

이는 JPQL을 사용했을 때의 문제이다.

JPQL을 통해 JPA가 SQL을 사용하게 되면, 글로벌 페치 전략은 신경쓰지 않고 JPQL 자체 정보만 사용하기 때문에 연관된 엔티티에 대해서 join 대신 where 절로 묶인 다수 개의 쿼리가 나가게 된다.

 

이 문제를 재현하기 위해서는 OneToMany 관계를 살펴봐야 하기 때문에, 우테코를 기준으로 조회 API를 생성할 것이다.

우테코 엔티티를 다음과 같이 수정하자.

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Wootecho {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Enumerated(EnumType.STRING)
    private Course course;

    @OneToMany(fetch = FetchType.EAGER, mappedBy = "wootecho")
    private List<Crew> crews;
}

crew에 대한 정보를 추가해주고, 연관관계의 주인을 Wootecho로 설정해주었다.

 

그리고, JPQL을 사용하기 위해서 위와 같이 커스텀 메서드를 생성해주었다.

public interface WootechoRepository extends JpaRepository<Wootecho, Long> {

    @Query("select w from Wootecho w")
    List<Wootecho> findWootechos();
}

 

서비스와 컨트롤러, DTO이다. 간단한 예제이기 때문에 추가 설명은 작성하지 않겠다.

// WootechoService.java
@Service
@RequiredArgsConstructor
public class WootechoService {
    private final WootechoRepository wootechoRepository;

    public List<Wootecho> getAll() {
        return wootechoRepository.findWootechos();
    }
}


// WootechoController.java
@RestController
@RequestMapping("/wootecho")
@RequiredArgsConstructor
public class WootechoController {
    private final WootechoService wootechoService;

    @GetMapping
    public ResponseEntity<List<WootechoResponse>> getAll() {
        final List<Wootecho> wootechos = wootechoService.getAll();
        final List<WootechoResponse> result = wootechos.stream()
            .map(WootechoResponse::of)
            .toList();
        return ResponseEntity.ok(result);
    }
}

새로운 WootechoService와 WootechoController를 생성하였다.

 

이제, 우테코 전체를 조회해보자. 현재 테이블에는 다음과 같이 데이터가 저장되어 있다.

Hibernate: 
    select
        w1_0.id,
        w1_0.course 
    from
        wootecho w1_0
Hibernate: 
    select
        c1_0.wootecho_id,
        c1_0.id,
        c1_0.name 
    from
        crew c1_0 
    where
        c1_0.wootecho_id=?
Hibernate: 
    select
        c1_0.wootecho_id,
        c1_0.id,
        c1_0.name 
    from
        crew c1_0 
    where
        c1_0.wootecho_id=?
Hibernate: 
    select
        c1_0.wootecho_id,
        c1_0.id,
        c1_0.name 
    from
        crew c1_0 
    where
        c1_0.wootecho_id=?

다음과 같이 굉장히 길어진 쿼리가 나간 것을 볼 수 있다. 하나씩 보자.

위와 같이 Wootecho만 조회하려고 했으나, 즉시 로딩으로 인해 Crew에 대한 정보도 가져오면서 1+N개의 쿼리가 발생한 것이다.

 

JPQL이 코드 분석 시 다음과 같은 절차를 밟으며 발생한 문제이다.

1. select w from Wootecho w를 보고 select * from wootecho 쿼리 생성
2. 생성된 쿼리를 바탕으로 List<Wootecho> 엔티티 생성
3. 쿼리가 생성된 이후, 즉시 로딩 전략으로 인해서 Wootecho와 연관된 Crew 엔티티 역시 함께 즉시 로딩
4. Wootecho 엔티티의 개수만큼 select * from crew where wootecho_id = ? 쿼리 발생

 

---

 

🌱 LAZY로 유지하면서 fetch join 사용하기

지연 로딩을 사용하면서, jpql을 호출하는 시점에 한 번에 가져오도록 최적화를 하는 전략이다.

public interface WootechoRepository extends JpaRepository<Wootecho, Long> {

    @Query("select w from Wootecho w join fetch w.crews")
    List<Wootecho> findWootechos();
}

위와 같이 jpql에 join fetch를 추가해주면 된다.

이 상태로 쿼리를 다시 살펴보자.

깔끔하게 join을 이용하여 한 번에 가져온 것을 확인할 수 있다 😊

 

---

 

🌱 강제로 초기화하기 - Hibernate.initialize()

영속성 컨텍스트가 살아있을 때 프레젠테이션 계층에서 필요한 엔티티를 강제로 초기화하여 반환할 수 있다.

JPA는 기본적으로 관련 기능을 제공하지 않기 때문에, 하이버네이트에서 제공하는 Hibernate.initialize()를 사용할 수 있다.

 

우리가 이전 포스팅부터 고민했던 '크루를 조회할 때 우테코 엔티티를 함께 조회하는 경우'에 대해 적용해보자.

public class Crew {
	...
    
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "wootecho_id", nullable = false, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT))
    private Wootecho wootecho;
}

다시 Crew 엔티티에서 Wootecho 엔티티의 페치 전략을 LAZY로 설정해준다. (마찬가지로 Wootecho 엔티티의 Crew 역시 LAZY로 설정해주었다.)

// CrewService.java
public Crew getById(final Long wootechoId) {
    final Crew findCrew = crewRepository.findById(wootechoId)
        .orElseThrow(() -> new IllegalArgumentException("존재하지 않는 아이디입니다."));
    Hibernate.initialize(findCrew.getWootecho());
    return findCrew;
}

그리고, 다음과 같이 getById() 메서드에 Hibernate.initialize()를 추가해주었다.

 

기존에는 no Session Exception이 터졌던 것과 다르게, 잘 조회되는 것을 볼 수 있다.

 

Hibernate 기술을 직접적으로 사용하는 것이 부담스럽다면, 영속성 컨텍스트가 살아있는 범위에서 프레젠테이션 계층이 사용할 데이터를 실제로 사용해버리는 방법도 있다.

// CrewService.java
public Crew getById(final Long wootechoId) {
    final Crew findCrew = crewRepository.findById(wootechoId)
        .orElseThrow(() -> new IllegalArgumentException("존재하지 않는 아이디입니다."));
    findCrew.getWootecho().getCourse(); // 실제 사용해버리기
    return findCrew;
}

이렇게 해도 위와 동일한 쿼리가 발생하게 된다.

 

하지만, 이렇게 프록시를 초기화하는 역할을 서비스 계층이 담당하면 뷰가 필요한 엔티티에 따라서 서비스 계층의 로직을 변경해야 한다.

만약 CrewResponse가 아닌 다른 DTO 객체가 생기고, 거기서는 course만 필요한 것이 아닌 name이나 다른 필드들의 값들이 필요하다면? 뷰의 변경사항이 서비스까지 함께 영향을 받기 때문에 유지보수 포인트가 증가하는 것이다.

 

이를 위해 서비스 계층에서 프레젠테이션 계층을 위한 프록시 초기화 역할을 분리해야 하며, FACADE 패턴을 활용할 수 있다.

서비스 앞단에서 Facade가 1차적으로 프레젠테이션 계층과 도메인 모델 사이의 논리적 의존성을 분리해줌으로서, 프레젠테이션 계층에서 필요한 프록시 객체를 초기화하는 역할을 담당하는 것이다.

@Component
@RequiredArgsConstructor
public class CrewFacade {

    private final CrewService crewService;
    
    public Crew getById(final Long crewId) {
        final Crew crew = crewService.getById(crewId);
        // 프록시 객체가 필요한 데이터 초기화
        crew.getWootecho().getCrews();
        return crew;
    }
}

// CrewController.java
@GetMapping("/{crewId}")
public ResponseEntity<CrewResponse> getById(@PathVariable Long crewId) {
    final Crew crew = crewFacade.getById(crewId);
    return ResponseEntity.ok(CrewResponse.of(crew));
}

 

하지만... 이런 식으로 중간 계층이 들어가면 결과적으로 개발자가 작성해야 하는 코드가 많아진다는 것이다.

또한, JPA에 대한 이해도가 없는 개발자와 협업을 하게 된다면 해당 코드에 대해 제대로 이해하지 못한 상태로 제거해버리는 상황이 발생할 수도 있다 🥲

 

결국 지금까지의 모든 문제는 '엔티티가 프레젠테이션 계층에서 준영속 상태이기 때문에' 발생했던 문제이다.

이런 원초적인 문제부터 해결을 해보자.

 

---

🌱 OSIV (Open session In View)

OSIV는 영속성 컨텍스트를 뷰까지 열어둔다는 의미이다. 뷰까지 컨텍스트가 열려 있기 때문에 자동으로 지연 로딩이 가능해지는 것이다.

cf. 참고로, OSIV는 하이버네이트에서 사용하는 용어여서 JPA에서는 OEIV (Open EntityManager In View)를 더 많이 사용하지만, OSIV가 더 익숙하기 때문에 OSIV라고 부르겠다.

 

OSIV는 여러 방식이 있는데, 클라이언트의 요청과 생명주기가 동일한 Transaction per request OSIV가 존재한다.

요청이 들어오자마자 서블릿 필터나 스프링 인터셉터에서 영속성 컨텍스트를 만들면서 트랜잭션을 시작하고, 요청이 끝날 때 컨텍스트와 트랜잭션을 함께 종료하는 방법이다. 이러면 영속성 컨텍스트가 끝까지 살아 있어서 어디서 조회하든 영속 상태가 되다.

 

지연 로딩 역시 자유롭게 가능하지만, 엔티티와 트랜잭션 생명주기가 너무 길기 때문에 프레젠테이션 영역에서 엔티티를 자유롭게 참조할 수 있다는 것이다. 엔티티는 코어한 영역이기 때문에 외부에서 쉽게 참조하는 건 좋지 않다. 도메인이 DTO를 참조하지 않는 것과 동일한 영역이라고 봐도 된다. ㅎㅎ

(개인적인 생각으로는 entity가 controller 영역까지 참조되는 걸 선호하지 않기 때문에 그러한 관점에서도 별로다)

 

그러면, 스프링에서는 어떤 OSIV 전략을 채택하고 있을까?

- 다양한 OSIV 클래스가 있기 때문에 이를 필터나 인터셉터가 등록하여 사용할 수 있다. (중요한 내용은 아니니 생략하겠다)

 

 

💬 스프링 프레임워크가 제공하는 OSIV

OSIV를 사용하지만, 비즈니스 계층까지만 트랜잭션을 사용하는 전략이다.

클라이언트 요청이 들어오면 서블릿 필터나 스프링 필터에서 영속성 컨텍스트를 생성하지만, 트랜잭션은 시작하지 않는다.

이후, 서비스 계층에서 @Transactional을 시작할 때 초기에 생성한 영속성 컨텍스트를 바탕으로 트랜잭션을 시작한다.

서비스 계층이 종료되면 트랜잭션 커밋 후 영속성 컨텍스트를 플러시하고, 트랜잭션은 종료하지만 컨텍스트는 종료하지 않는다.

 

이렇게 되면 프레젠테이션 계층까지 영속성 컨텍스트가 살아있기 때문에 엔티티는 영속 상태를 유지하게 되고, 지연 로딩이 가능하게 된다!

이후 필터나 인터셉터로 요청이 다시 되돌아오면 컨텍스트를 종료해준다. (이때, 플러시를 호출하지 않는다!)

 

⭐️ 기존의 방법에 비해 프레젠테이션 계층에서는 트랜잭션이 없기 때문에 엔티티에 대한 변경이 불가능하다.

-> 정확하게는, 이미 서비스 계층에서 플러시까지 진행되었고 필터-인터셉터에서도 플러시를 호출하지 않기 때문에, 플러시를 호출하지 않아 엔티티의 변경사항에 대해 DB로 반영하지 않는 것이다.

-> 강제로 플러시하더라도 트랜잭션 범위 밖이라 수정할 수 없다는 예외가 발생한다. (TransactionRequiredException)

 

하지만, 지연 로딩을 통해서 엔티티를 조회해올 수 있기 때문에 단순히 조회는 가능하게 되는 것이다.

 

💡 여기서 중요한 건, 영속성 컨텍스트가 살아있기 때문에 내부에 변경사항이 저장되어 있는 것이다.
프레젠테이션 레이어에서 @Transactional 포함한 비즈니스 로직을 호출하게 되면 해당 비즈니스 로직이 종료될 때 이미 이전에 저장되었던 변경사항을 함께 flush 해버리기 때문에 예기치 못한 버그가 발생할 수도 있다.
- 보통은 컨트롤러에서 서비스를 먼저 호출하기 때문에 이런 일은 거의 없겠지만... 
플러시를 호출하지 않아서 변경사항을 반영하지 않는다는 점을 기억하자!

 

---

🌱 다시 돌고 돌아서...

스프링부트는 기본적으로 OSIV를 true로 설정해두었기 때문에 뷰까지 데이터를 참조한다.

하지만 개인적으로 OSIV 옵션은 끄고 사용하는 것이 좋다고 생각한다.

우선 DB 커넥션을 계속 잡고 있기 때문에 리소스의 낭비가 발생할 수 있기 때문이다.

(지연 로딩을 통해서 받아오려면 아무튼 커넥션이 살아 있어야 하니까)

 

또한, 스프링의 OSIV 전략은 프레젠테이션의 데이터 변경은 막지만, 애초에 프레젠테이션까지 엔티티가 참조 관계를 가지는 건 레이어의 단방향 흐름을 깬다고 생각하기 때문이다. (같은 의미로 DTO 역시 서비스 레이어에서 생성한 다음에 뷰로 반환하는 것을 선호한다.)

 

각 레이어간의 단방향 관계를 유지하기 위해서는 엔티티에 대한 조작은 서비스 레이어까지만 진행하고, 이후 뷰에 처리될 데이터는 DTO를 통해 연관관계를 끊은 상태로 조작하는 게 더 좋다는 것이 나의 의견이다 😊

(그리고 성능 최적화 방법으로 Command-Query separation 이라는 것도 있던데, 핵심 로직과 뷰 관련 서비스 로직을 분리하는 것이다. 나중에 미션할 때 한 번 이걸로 적용해봐야겠다...)