📚[Spring] 대용량 데이터 처리

대용량 데이터 처리

들어가며

	@Test
void signup_백만건의_유저가입() {
	List<User> users = new ArrayList<>();
	String password = passwordEncoder.encode("1234");
	
	for(int i=0; i<1000000; i++) {
		users.add(User.of("hong"+i+"@gmail.com", password, nicknameGenerate(), UserRole.USER));
	}
	userRepository.saveAll(users);
}

단순히 saveAll()에 100만 건을 한 번에 넘기면 어떻게 될까 궁금해서 실행해봤다.
예상대로 java.lang.OutOfMemoryError: Java heap space 예외가 발생하며 테스트는 약 3분 만에 실패했다.
영속성 컨텍스트가 비워지지 않으면서 메모리가 누적된 것이 원인이었다.

• 결과: BUILD FAILED in 3m 17s

---

10,000건씩 100번 저장

saveAll() 호출마다 영속성 컨텍스트를 비워주면 메모리 누수를 방지할 수 있을 거라 판단했다.

	@Test
	void signup_백만건의_유저가입() {
		List<User> users = new ArrayList<>();
	    String password = passwordEncoder.encode("1234");
		int cnt = 1;
		
		for(int i=0; i<100; i++) {
			for(int ii=0; ii<10000; ii++) {
				users.add(User.of("hong"+ cnt, password, nicknameGenerate(), UserRole.USER));
				cnt ++;
			}
			userRepository.saveAll(users);
			users.clear();
		}
	}

예상대로 문제없이 성공했다.
메모리도 과하게 차지하지 않았고 성능도 준수했다.

• 결과: BUILD SUCCESSFUL in 2m 51s

---

1,000건씩 1,000번 저장

더 작은 단위로 나누면 속도 차이가 있을까?

	@Test
	void signup_백만건의_유저가입() {
		List<User> users = new ArrayList<>();
	    String password = passwordEncoder.encode("1234");
		int cnt = 1;

		for(int i=0; i<1000; i++) {
			for(int ii=0; ii<1000; ii++) {
				users.add(User.of("hong"+ cnt +"@gmail.com", password, nicknameGenerate(), UserRole.USER));
				cnt ++;
			}
			userRepository.saveAll(users);
			users.clear();
		}

	}

속도는 약간 느려졌지만 큰 차이는 없었다.

• 결과: BUILD SUCCESSFUL in 2m 55s

saveAll() 호출 횟수가 많아질수록 오버헤드는 증가할 수 있다.
하지만 무작정 많은 양을 한 번에 밀어넣으면 시스템에 과부하가 생길 수 있으니 적절한 크기의 단위가 중요하다.

---

엔티티매니저를 직접 사용한 경우

@Test
@Transactional
@Rollback(false)
void signup_백만건의_유저가입() {
	String password = passwordEncoder.encode("1234");
	int cnt = 1;

	for(int i=0; i<100; i++) {
		for(int ii=0; ii<10000; ii++) {
			entityManager.persist(User.of("hong"+ cnt +"@gmail.com", password, nicknameGenerate(), UserRole.USER));
			cnt ++;
		}
		entityManager.flush();
		entityManager.clear();
	}
}

엔티티 매니저를 직접 사용해도 큰 차이는 없었고 성능은 saveAll()과 유사했다.

• 결과: BUILD SUCCESSFUL in 2m 55s

---

JdbcTemplate을 활용한 Batch Insert

	@Test
	@Transactional
	@Rollback(false)
	void signup_백만건의_유저가입_Jdbc() {
		String sql = "insert into users (email, password, nickname, user_role, created_at, modified_at) values (?, ?, ?, ?, ?, ?)";
		List<User> users = new ArrayList<>();
	    String password = passwordEncoder.encode("1234");
		int cnt = 1;

		for(int i=0; i<100; i++) {
			for(int ii = 0; ii<10000; ii++) {
				users.add(User.of("hong" + cnt + "@gmail.com", password, nicknameGenerate(), UserRole.USER));
				cnt ++ ;
			}

			jdbcTemplate.batchUpdate(sql, users, users.size(),
				(ps, user) -> {
					ps.setString(1, user.getEmail());
					ps.setString(2, user.getPassword());
					ps.setString(3, user.getNickname());
					ps.setString(4, user.getUserRole().name());
					ps.setTimestamp(5, Timestamp.valueOf(LocalDateTime.now()));
					ps.setTimestamp(6, Timestamp.valueOf(LocalDateTime.now()));
				});

			users.clear();
		}
	}

이 방식은 이전 방식들에 비해 훨씬 빠르고 효율적이었다.
약 1분 30초 정도의 성능 향상이 있었다.

• 결과: BUILD SUCCESSFUL in 1m 27s
  

---

데이터 저장 처리 성능 요약

방식	소요 시간	비고
saveAll(100만건 한 번)	실패	OutOfMemoryError
saveAll(10,000건 × 100)	2m 51s	안정적
saveAll(1,000건 × 1,000)	2m 55s	약간 느림
EntityManager 직접 사용	2m 55s	성능 유사
JdbcTemplate Batch	1m 27s	가장 빠름

---

조회 성능 개선 테스트

100만 건의 사용자 데이터를 기반으로 nickname 조건을 이용한 조회 성능 테스트를 진행하였다.
처음에는 단순한 JPA 쿼리 메서드를 활용한 방식으로 측정하였고 이후 성능 향상을 위해 인덱스 적용과 프로젝션 활용 등의 리팩토링을 단계적으로 수행하였다.

조회 기능에 대한 테스트는 포스트맨을 활용한 통합 테스트로 진행하였다.

---

1단계 - 기본 JPA 쿼리 메서드 조회

//리포지터리 메서드
List<User> findByNickname(String nickname);

//서비스 메서드
public List<UserResponse> findUserByNickname(UserNicknameRequest userNicknameRequest) {
    List<User> foundUsers = userRepository.findByNickname(userNicknameRequest.getNickname());
    return foundUsers
        .stream()
        .map(user -> UserResponse.of(user.getId(), user.getEmail(), user.getNickname())).toList();
}

JPA 가 제공하는 기본 쿼리 메서드를 사용하여 nickname 으로 사용자를 조회하고 이를 DTO 로 변환하는 방식이다.
단순하고 직관적이지만 불필요하게 모든 컬럼을 조회하기 때문에 성능상의 이슈가 발생할 수 있다.

• 조회 시간: 420ms

---

2단계 - 인덱스 적용

성능 개선을 위해 nickname 컬럼에 인덱스를 추가하였다.
인덱스를 통해 검색 범위를 빠르게 좁힐 수 있기 때문에 쿼리 수행 시간이 단축된다.

create index users_nickname_index on users (nickname);

인덱스를 적용한 결과 약 17% 정도의 성능 향상을 확인할 수 있었다.

• 조회 시간: 349ms

---

3단계 - 프로젝션을 이용한 컬럼 최적화

추가적인 최적화를 위해 JPA 프로젝션 기능을 활용해 필요한 컬럼만 조회하도록 개선하였다.
엔티티 전체를 조회하지 않고 DTO 로 직접 매핑함으로써 쿼리의 비용을 줄일 수 있다.

//리포지터리 메서드
@Query("select new org.example.expert.domain.user.dto.response.UserResponse(u.id, u.email, u.nickname) from User u "
	+ "where u.nickname = :nickname")
List<UserResponse> findProjectedUsersByNickname(@Param("nickname") String nickname);

//서비스 메서드
public List<UserResponse> findUserByNickname(UserNicknameRequest userNicknameRequest) {
	return userRepository.findProjectedUsersByNickname(userNicknameRequest.getNickname());
}

최적화를 통해 전체적으로 약 45%의 성능 개선을 이루었다.

• 조회 시간: 229ms

---

조회 성능 최적화 성능 요약

단계	주요 개선 사항	조회 시간
1단계 기본 조회	JPA 쿼리 메서드 사용	420ms
2단계 인덱스 적용	nickname 컬럼에 인덱스 추가	349ms
3단계 프로젝션 적용	필요한 컬럼만 조회하여 DTO 직접 반환	229ms

---

마치며

대용량 데이터 저장 시 배치 사이즈를 적절히 나누고 JdbcTemplate 배치 처리를 활용하는 게 가장 효율이 좋다고 판단된다.
조회의 경우는 인덱스 적용과 프로젝션으로 필요한 컬럼만 조회하면 성능이 크게 개선된다.
실제 서비스 환경에서 최적화는 사용자의 신뢰와 연결되는 필수적인 요소로 대용량의 데이터를 다루는 방식에 대해 계속해서 고민하고 학습해야겠다.