🔎 Overview

 3주간의 프로젝트가 종료되었다. 이번 프로젝트는 스스로 굉장히 얻은 게 많은 프로젝트였다.
이후 프로젝트 회고에서 다룰 예정이지만, 어렵고 힘든 일들도 많았으나 결과적으로 어느정도 괜찮은 퀄리티의 결과물을 뽑아낸 듯하여 조금 마음이 놓인다.

  이번 우리 팀 프로젝트 주제는 호텔 예약이다. 이 프로젝트에서 필자는 호텔 및 객실 도메인의 작업을 맡아서 진행하였다.
그러다보니 가장 많이 생각해본 부분이 바로 성능이다. 호텔과 객실이라는 굉장히 많은 양의 데이터들을 어떻게 하면 좀 더 효과적으로 다룰 수 있을까.

  지금 프로젝트에는 default_batch_fetch_size 가 적용되어있다.
처음에는 이거 하나로 N+1 문제를 전부 해결할 수 소리를 듣고 더욱 최적화할 수 있는 쿼리 생성에 집중했지만, 강사님과의 Q&A 이후로 배치를 적용하기로 결정했다.

  추가로, 1:N 의 데이터를 가져오기 위해서 어떤 방법이 가장 좋을까에 대해서도 많은 고민이 있었다.
JOIN 을 여러 번 사용하는 것과 Batch Fetching 중 어떤 것이 더 좋은 성능을 발휘할 수 있을까.
DB에서 일부 데이터만 가져오고 내부 메모리에서 변환 과정을 거치는 것이 좋을까, DB 에서 모든 작업을 끝내고 가져오는 것이 더 좋을까.
지금 이 프로젝트에는 어떤 것이 더 좋을까.

  현재는 호텔의 정보를 가져올 때 호텔 이미지의 썸네일을 가져오기 위해, 이미지 DB의 첫번째 값을 가져오기 위해서 조건문에 서브쿼리를 추가하였다.
지금 당장은 싱글 서버의 소규모 데이터셋을 가지고 진행하는 프로젝트이기 때문에 이러한 방법을 적용했지만, 지금의 이러한 방식은 이후 데이터가 늘어남에 따라 성능저하를 일으킬 수 있는 원인이 되기에 수정해야할 부분이다.

 이렇듯, 어떻게 보면 간단한 CRUD 작업일지라도 성능에 대한 고려를 하다보니 생각보다 많은 고민이 필요했다.

 앞으로 수없이 직면할 이러한 문제들을 더욱 더 효과적으로 해결하기 위해, N+1 에 대한 확실한 학습이 필요하다.
프로젝트가 끝난 기념으로 N+1 문제에 대해서 정리해보고자 한다.

---

📖 N+1 문제

• ORM 환경에서 발생하는 성능 문제로, 1개의 쿼리를 실행할 때 추가적으로 N개의 쿼리가 발생하는 현상
• 주로 JPA 와 같은 ORM 에서, 연관된 데이터를 Lazy Loading 으로 가져올 때 발생

@Entity
@Builder
public class Hotel {
	@Id
    @GeneratedValue(strategy = GenerationType.Identity) // 이후 생략
    private Long id;
    
    @Column
    private String hotelName;
    
    @OneToMany(mappedBy = "hotel")
    @Builder.Default
    private List<Room> rooms = new ArrayList<>();
}

@Entity
public class Room {
	// ...
    
    private String roomName;
    
    @ManyToOne
    private Hotel hotel;
}

• 알다시피, @OneToMany 의 기본 FetchType 은 Lazy
• hotelRepository.findAll() 로 전체 Hotel 의 정보를 가져올 시
  • 여기서 SELECT 쿼리가 1번 발생
• Hotel 에는 현재 실제 Room 들의 값이 들어있는 것이 아닌, 해당 Room 들의 주소값을 포함하고 있는 Proxy 객체를 갖고 있음
• 이후 Room 의 정보를 얻으려고 할 시
  • Room 에 대한 SELECT 쿼리를 여기서 다시 실행

결과적으로 Hotel 을 가져올 때 1번, Room 의 정보를 가져올 때 N 번, 총 N+1 번의 쿼리가 실행됨

• 쿼리의 총 개수가 적다면 크게 문제가 되지 않을 수 있지만, 큰 규모에서는 이렇게 추가로 생성된 쿼리로 인해 문제가 생길 가능성이 높음

• 즉, 성능에 큰 영향을 미칠 수 있는 아주 중요한 부분

---

💡 N+1 문제 해결 방법

1️⃣. Fetch Join

• 1:N 연관관계에서 연관된 엔티티를 한 번에 조회할 때 사용
• 필요할 데이터들을 모두 한 번에 가져올 수 있음
• N+1 을 해결하기 위한 가장 좋은 방법
• 단, 페이징이 되지 않는다는 단점이 있음
• 또한 Repsitory 에서 한 번에 DTO 로 반환 시 사용할 수 없음
  • 이는 Fetch Join 방식은 엔티티 그래프를 한 번에 로딩하는 방식이기 때문
  • DTO 프로젝션은 엔티티를 가져오는 게 아닌, 특정 필드만 가져오는 방식
  • Fetch Join 은 엔티티 전쳬를 조회해야 동작하므로, DTO 와 함께 사용 불가능
    
    

@Query("SELECT h FROM Hotel h JOIN FETCH h.rooms")
List<Hotel> findAllHotels();

• 실제 쿼리가 실행될 때 JOIN Room r ON h.id = r.hotel_id 가 발생
  
  
  

2️⃣. Batch

1. @BatchSize 를 통한 배치 사이즈 조정

@OneToMany(mappedBy = "hotel")
@BatchSize(size = 50)
private List<Room> rooms;

2. Global 설정을 통한 배치 사이즈 조정

spring:
  jpa:
    properties:
      hibernate.default_batch_fetch_size: 50

• 배치 사이즈를 50으로 고정
• SELECT * FROM Room WHERE room_id IN (1, 2, 3.... 49, 50) 같이 실행 ( IN 이 사용됨)
• 한 번 Hotel 의 데이터를 가져올 때 50개의 Room 데이터를 함께 가져옴
• 50개 이후의 데이터를 가져올 때는 또 다시 N+1 문제가 발생
  
  
  

3️⃣. @EntityGraph

• Fetch Join 을 사용하지 않는 방법
• 복잡한 경우 한계가 존재

@EntityGraph(attributePaths = {"Room"})
@Query("SELECT h FROM Hotel h JOIN FETCH h.rooms")
List<Hotel> findAllHotels();

---

📑 여러 개의 @OneToMany

• 하나의 Entity 에 여러개의 @OneToMany 가 달려있는 경우도 있음
• 이러한 경우에 가장 좋은 방법은 크게 2가지
  
  

1️⃣ BatchSize 조정

@OneToMany(mappedBy = "hotel")
@BatchSize(size = 50)
private List<Room> rooms;

@OneToMany(mappedBy = "hotel")
@BatchSize(size = 50)
private List<Review> reviews;

혹은

spring:
  jpa:
    properties:
      hibernate.default_batch_fetch_size: 50

• 마찬가지로 BatchSize 조정을 통해 한 번에 여러 개의 데이터를 가져오는 방법
  
  

2️⃣ 쿼리 분리

• @OneToMany 관계는 따로 조회하고, 이후에 어플리케이션 레벨에서 조립하는 방식
  
  

1. 기존 프로젝트에서 사용한 쿼리

@Query("""
	SELECT new com.ll.hotel.domain.hotel.hotel.dto.HotelWithImageDto(h, i)
	FROM Hotel h
	LEFT JOIN Image i
	ON i.referenceId = h.id
	AND i.imageType = :imageType
	WHERE h.hotelStatus <> 'UNAVAILABLE'
	AND (i.createdAt = (
		SELECT MIN(i2.createdAt)
		FROM Image i2
		WHERE i2.referenceId = h.id
		AND i2.imageType = :imageType
		)
	OR i is NULL)
	AND h.streetAddress LIKE %:streetAddress%
	""")
Page<HotelWithImageDto> findAllHotels(@Param("imageType") ImageType imageType,
                                          @Param("streetAddress") String streetAddress, PageRequest pageRequest);

• Image 테이블의 이미지 타입이 호텔인 이미지들 중 해당하는 첫 번째 이미지(썸네일)만 가져오기 위한 서브쿼리
• 이 쿼리는 현재는 데이터셋이 작기 때문에 큰 문제가 없음
• 하지만 이후 데이터가 커지면 매 호텔마다 서브쿼리가 발생하기 때문에 성능 문제가 생길 수 있음
  
  

2. 이를 분리한 쿼리

@Query("""
	SELECT h
    FROM Hotel h
    WHERE h.hotelStatus <> 'UNAVAILABLE'
    AND h.streetAddress LIKE %:streetAddress%
    """)
Page<Hotel> findHotels(@Param("streetAddress") String streetAddress, Pageable pageable);

@Query("""
	SELECT i
	FROM Image i
	WHERE i.imageType = :imageType
    AND i.createdAt IN (
    	SELECT MIN(i2.createdAt)
        FROM Image i2
        WHERE i2.referenceId IN :hotelIds
        AND i2.imageType = :imageType
        GROUP BY i2.referenceId
		)
	""")
List<Image> findFirstImages(@Param("imageType") ImageType imageType, @Param("hotelIds") List<Long> hotelIds);

• 조건에 맞는 호텔들을 먼저 조회
• 해당하는 호텔의 ID 를 사용하여, 해당 호텔들의 첫 번째 이미지들만 배치로 조회
• 이후 이 두 결과를 애플리케이션 레벨에서 매칭하여 HotelWithImageDto 로 변환
• 이렇게 되면, 서브쿼리가 호텔마다 중복 실행되지 않으므로 성능의 이점이 있음

• 현재는 데이터셋이 많지 않고 실제 서비스가 아닌 프로젝트 레벨이기 때문에, 쿼리를 따로 분리하지 않음
• 데이터셋이 그렇게 크지 않으므로 메모리에서 처리하는 게 더 유리하다고 판단
• 3차 프로젝트를 진행하면서 더 생각해봐야 할 것 같음
• 현대 과학의 발전으로 인해 트레이드 오프로 유지보수성을 챙기는 게 웬만해선 좋을 것으로 판단 중

---

참고) OpenAI. (2024).ChatGPT(4o)[Large language model].https://chatgpt.com/