[Spring] JPQL 사용시 Eager Type 질문

[DoohyunHwang97]

위의 코드대로 실행을 하려했을 때 N+1 문제가 발생하였습니다. 쿼리 로그를 봤을 때 앨범 엔티티를 가져오는 것으로 보아 Eager Type을 JPQL로 인해서 가져오지 않아서 생기는 문제 같아서 아래와 같이 해결했습니다.

1. 이런 경우에 다대일 관계의 경우 Eager Type이기에 JPQL에서 join fetch 하지 않으면 쿼리를 한번 더 날려서 조인을 하는 것인가요?
2. 하지만 그렇다고 해서 JPQL 사용시 EagerType을 모두 수동으로 Join fetch하는 것이 맞을까라는 의문이 들고 song - album - artist 처럼 다대일 관계가 계속 이어져있는 경우에 계속 Join fetch를 해주어야 되는지에 대한 의문도 생깁니다.
3. 그리고 join fetch를 하다보면 두번의 쿼리(findAllByIDListJoinFetch(), findByIDJoinFetch())가 가져오는 데이터의 중복이 많아지는데 이것이 올바른 방향인지도 궁금합니다.

감사합니다

[davin111]

안녕하세요, 질문에 답변이 늦어 죄송합니다.

참고로, 코드를 공유해주실 때는 스크린샷보다는 복붙이 가능한 방식으로 올려주시면 좋습니다.

@Query ("SELECT s FROM songs S " +
        "LEFT JOIN FETCH s.album a " +
        "LEFT JOIN FETCH s. song_artists sa "
        "LEFT JOIN FETCH sa.artist " +
        "WHERE s.id IN :idList")
fun findAliByIDListJoinFetch(idList: List<Long>): List<SongEntity>

위와 같이 markdown 문법(```kotlin)을 이용하여 Kotlin 문법 하이라이트를 하면서 코드를 예쁘게 공유할 수 있답니다. 복잡한 질문의 경우, 재현이 가능하도록 본인 repo 의 특정 branch 에 push 해두시고 링크를 걸어주셔도 좋습니다. 갈수록 과제가 복잡해지면서 개인마다 설계 상황 등이 다를 수 있어서 답변하는 입장에서 상황을 이해하기 어려울 수 있거든요.

---

1. 엄밀히 말해, JPA 의 연관관계에서 Eager, Lazy 가 N+1 문제를 일으키는 것과 직결되지는 않습니다. 관련은 있지만요. Eager 로 해도, Lazy 로 해도, 상황에 따라 N+1 문제는 발생할 수 있습니다. Eager 와 Lazy 의 구분에서 중요한 것은, 당장 필요하지 않아도 가져오게 할 거냐인 거죠. Lazy 라도 아직 안 가져온 연관관계 대상 각각이 결국 필요해지는 시점이 되면 N+1 은 터질 수 있습니다. (참고: https://cheese10yun.github.io/jpa-nplus-1/, https://mighty96.github.io/til/fetch_fetchjoin/) 한편 Eager 는 오히려 가능한 경우, 알아서 서로 다른 entity 를 따로따로 안 가져오고 한 방 join 쿼리로 효율적인 실행을 돕기도 합니다. 어쨌든 간에, 어떤 형태의 연관관계든 Lazy 로 설정해두시는 게 여러모로 성능 튜닝에서 이점을 가져오고 잠재적 문제를 줄이기에 현업에서 비교적 선호됩니다.
   답하기가 애매하지만, 네, 일단 Eager 로 하셨으니 지금 상황에서는 N+1 문제가 발생하는 데에 일조한 것이 맞습니다. Song 을 가져와놓고 (JPQL 은 기본적으로 sql 로의 변환에 충실하기 때문에 Eager 라고 알아서 처음부터 join 해서 가져오거나 하지 않음), 어 나 Eager 인데 엮인 Album 이 없네? 하면서 그제서야 후다닥 나머지를 다 하나씩 땡겨오는 것이죠. 다만 위에 길게 설명했듯, Lazy 라고 해도, 어차피 코드 뒤쪽 가서 개별 Album 이 필요한 상황이 되었다면, N+1 은 마찬가지로 발생했을 것입니다. (바꿔서 직접 테스트해보셔도 좋겠네요)

2. 앞서 언급했듯, 그냥 1:N, N:1 어느 경우든 모두 Lazy 를 기본으로 설정해두는 것이 튜닝에 편합니다. 때에 따라선 비교적 많은 테이블을 fetch join 하는 것이 맞는 선택일 수도 있습니다. 그러나 쿼리 부하가 걱정되는 등의 상황이라면(MySQL explain 기능으로 쿼리 성능 평가 가능), 차라리 한 방 쿼리로 다 가져오려고 하기보다, 쿼리를 쪼개서 실행하는 게 좋을 수도 있겠죠.

3. 여러 쿼리가 자꾸 이미 서버로 가져온 데이터를 또 불필요하게 가져오고 있다면 좋은 상황은 아닐 거 같고요. 2.에서 언급했듯, 쿼리를 잘 쪼개서 필요한 것을 필요한 타이밍에 잘 챙겨올 수 있도록 고민해보는 것이 좋은 개발일 것 같습니다. JPA 가 많이 쓰이지만, 사실 질문해주신 내용들에서 느끼셨듯, 조금만 비즈니스 로직이 복잡해져도 잘 쓰기가 쉬운 기술은 아닙니다. ORM이 처음에는 쿼리를 자동으로 생성해주니 편하지만, 성능 튜닝 고민이 깊어질 수록 오히려 어려워지는 거죠. 그런 점에서 정말 복잡한 조회 쿼리를 만들어야하는 경우엔 QueryDsl 의 도움을 받기도 하고, 아예 raw query 를 직접 쓰거나, 그에 준하는 기술인 MyBatis 등을 쓰는 경우도 있을 것입니다.

cc. @PFCJeong

[DoohyunHwang97]

@davin111 와 정말 퀄리티 높은 답변에 감탄했습니다🫢인사이트가 느껴집니다..안 그래도 스샷 찍으면서 이게 맞나 싶었는데ㅋㅋ방법이 있었군요. 질문 올리는 팁까지 올려주시다뇨🫡감사합니다