별점 중복 생성 동시성 이슈 해결

들어가기 앞서

프로젝트를 진행 중, 프론트엔드 개발자분 께서 별점 기능에서 별점 값이 제대로 업데이트되지 않는 문제를 발견하셨습니다. 문제를 정확히 파악하기 위해 데이터베이스를 확인해본 결과, 동일한 별점 데이터가 2개 저장된 것을 확인할 수 있었습니다. 

public RatingCreateResponse createRating(Long userId, RatingCreateServiceRequest request) {
	User user = userRepository.findById(userId)
		.orElseThrow(() -> new BusinessException(USER_NOT_FOUND));
	
	Book book = bookRepository.findById(request.getBookIsbn())
		.orElseThrow(() -> new BusinessException(BOOK_NOT_FOUND));
	
	// 조회한 user와 book을 통해서 rating을 중복 생성하는지 확인한다.
	if (ratingRepository.existByUserAndBook(user, book)) {
		throw new BusinessException(RATING_ALREADY_EXIST);
	}
	
	Rating rating = ratingRepository.save(request.toEntity());
	
	return RatingCreateResponse.of(rating, book);
}

사용자가 도서에 대해서 2개의 별점을 가지고 있음

흥미로운 점은 애플리케이션 코드에 중복 데이터를 방지하는 로직이 이미 구현되어 있었음에도 불구하고, 중복 데이터가 생성되었다는 점입니다. 그렇다면, 예상대로 코드가 작동하지 않은 원인을 분석해봄으로써 문제의 근본적인 원인을 찾아보겠습니다.

 

동시성 문제로 인해 발생한 중복 데이터 저장

데이터베이스 기록을 살펴보니, 별점 데이터가 거의 동시에 생성된 것이 확인되었습니다. 두 개의 데이터가 거의 동일한 시간에 저장된 것으로 보아, 이는 동시성 문제, 특히 경쟁 상태(Race Condition)로 인해 발생한 것으로 추측됩니다. 그렇다면 경쟁 상태란 무엇이며, 왜 발생하는 것일까요?

 

경쟁 상태 (Race Condition)

경쟁 상태는 다수의 프로세스나 스레드가 동시에 동일한 데이터에 접근하여 수정할 때 발생하는 문제로, 이로 인해 예기치 않은 결과가 발생할 수 있습니다. 

 

위 사진처럼 한 사용자가 별점을 제출할 때 빠르게 요청하여 2번 생성되도록 시도할 경우, 두 요청이 거의 동시에 데이터 베이스에 도달하게 되면서 별점이 있는지 확인하는 로직에서 검증되지 않고 중복 데이터가 저장될 가능성이 생깁니다. 

 

이 같은 상황은 아래의 코드를 통해 확인할 수 있습니다. 

public RatingCreateResponse createRating(Long userId, RatingCreateServiceRequest request) {
	User user = userRepository.findById(userId)
		.orElseThrow(() -> new BusinessException(USER_NOT_FOUND));
	
	Book book = bookRepository.findById(request.getBookIsbn())
		.orElseThrow(() -> new BusinessException(BOOK_NOT_FOUND));
	
	// 조회한 user와 book을 통해서 rating을 중복 생성하는지 확인한다.
	if (ratingRepository.existByUserAndBook(user, book)) {
		throw new BusinessException(RATING_ALREADY_EXIST);
	}
	
	Rating rating = ratingRepository.save(request.toEntity());
	
	return RatingCreateResponse.of(rating, book);
}

 

@Test
@DisplayName("동일한 도서에 대해 사용자가 동시에 별점을 추가하면 여러개의 별점이 생성된다.")
public void createRatingWithThreads() throws Exception {
	// given
	User user = userRepository.save(createUser());
	Book book = bookRepository.save(createBook());
	
	RatingCreateServiceRequest request = RatingCreateServiceRequest.builder()
		.rating(4.5)
		.bookIsbn(book.getIsbn())
		.build();
	
	int threadCount = 2;
	ExecutorService executorService = Executores.newFixedThreadPool(threadCount);
	CountDownLatch latch = new CountDownLatch(threadCount);
	
	// when - 사용자가 동시에 별점 생성을 요청한 상황
	for (int i = 0; i < threadCount; i++) {
		executorService.submit(() -> {
			try {
				ratingService.createRating(user.getId(), request);
			} finally {
				latch.countDown();
			}
		});
	}
	
	latch.await();
	
	// then
	List<Rating> ratings = ratingRepository.findAll();
	assertThat(ratings).hasSize(2);
}

별점이 2개가 생성됨

서비스 로직상에서는 이미 사용자가 이미 별점을 추가했을 경우 중복 생성이 되지 않도록 되어 있으나, 동시에 별점 생성을 요청한 경우에는 별점이 2개가 저장되는 결과를 확인할 수 있습니다.

 

문제 해결 방법

중복 데이터 삽입을 방지하기 위한 방법은 여러가지 방법이 있습니다. 대표적으로 유니크 인덱스 설정과 네임드 락을 통한 Redis 분산 락을 사용하는 방식이 있습니다. 

 

저희 프로젝트에서는 이 두 가지 해결 방식 중 유니크 인덱스를 사용하여 중복 문제를 해결하였습니다. Redis 분산 락은 대규모 분산 시스템이나 멀티 인스턴스 환경에서 여러 서비스 인스턴스가 동시에 접근하는 리소스에 대한 중복 제어에 유용합니다. 그러나 저희 서비스는 단일 인스턴스 환경으로 운영되고 있기 때문에 Redis 분산 락을 구현하는 것은 과도한 판단이라 생각했습니다. 

❓ 낙관적/비관적 락은 중복 생성을 막을 수 없나요?
낙관적/비관적 락은 이미 존재하는 데이터의 정합성을 막기 위해 사용되는 것이기 때문에 INSERT의 경우 새로운 데이터가 생성되는 것이므로, 이미 데이터가 존재하지 않기에 락의 개념이 작동하지 않습니다.

❓ 유니크 인덱스는 락 없이 동시성을 제어하는 건가요?
유니크 인덱스는 INSERT 시 중복 여부를 확인하기 위해 공유 락(S-Lock)을 사용합니다. 이때 다른 트랜잭션에서 INSERT 작업을 해도 공유 락을 걸 수 없기 때문에 해당 트랜잭션 작업은 대기하게 됩니다. 중복된 값이 없다고 확인되면, InnoDB는 공유 락을 해제하고, 실제 삽입하는 과정에서 쓰기 락(X-Lock)으로 전환하여 삽입 작업을 완료합니다. 삽입 완료 후, X-Lock도 해제되면서 다른 트랜잭션이 이 레코드에 접근할 수 있게됩니다.

엔티티에 유니크 인덱스 적용

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Table(uniqueConstraint = {
	@UniqueConstraint(columnNames = {"user_id", "book_isbn"})
})
public class Rating extends BaseEntity {
	...
}

해당 엔티티에는 사용자와 도서에 관한 별점이 중복되지 않게 생성되어야 하기 때문에 해당 ID들을 유니크 복합 인덱스로 생성하여 설정했습니다.

 

@Test
@DisplayName("사용자가 동일한 도서에 대해 동시에 별점을 추가해도 하나의 별점만 생성된다.")
public void createRatingWithThreads() throws Exception {
	// given
	User user = userRepository.save(createUser());
	Book book = bookRepository.save(createBook());
	
	RatingCreateServiceRequest reqeust = RatingCreateServiceRequest.builder()
		.rating(4.5)
		.bookIsbn(book.getIsbn())
		.build();
		
	int threadCount = 2;
	ExecutorService executorService = Executors.newFixedThreadPool(threadCount);
	CountDownLatch latch = new CountDownLatch();
	
	// when
	for (int i = 0; i < threadCount; i++) {
		executorService.submit(() -> {
			try {
				ratingService.createRating(user.getId(), request);
			} finally {
				latch.countDown();
			}
		});
	}
	
	latch.await();
	
	// then
	List<Rating> ratings = ratingRepository.findAll();
	assertThat(ratings).hasSize(1);
}

해당 설정을 마치고 위의 테스트를 수행시켜보면 데이터베이스에 1개의 별점 데이터만 조회되는 것을 확인할 수 있습니다. 

DataIntergrityViolationException 처리

유니크 인덱스를 설정한 후 데이터 중복 저장 시, 데이터베이스 내부에서 중복에 대한 오류가 발생하여 위와 같은 예외가 발생합니다. 

// Service에서 try/catch 구문을 이용하여 처리
@Transactional
public RatingCreateResponse createRating(Long userId, RatingCreateServiceRequest request) {
	User user = userRepository.findById(userId)
		.orElseThrow(() -> new BusinessExeption(USER_NOT_FOUND));
		
	Book book = bookRepository.findById(request.getBookIsbn())
		.orElseThrow(() -> new BusinessException(BOOK_NOT_FOUND));
	
	if (ratingRepository.existByUserAndBook(user, book)) {
		throw new BusinessException(RATING_ALREADY_EXIST);
	}
	
	// 중복 데이터 처리
	try {
		Rating rating = ratingRepository.save(request.toEntity(user, book));
	} catch (DataIntergrityViolationException e) {
		throw new BusinessException(DATA_ALREADY_EXIST);
	}
	
	return RatingCreateResponse.of(rating, book);
}

@RestControllerAdvice
public class GlobalExceptionHandler {
	
	@ExceptionHandler(DataIntergrityViolationException.class)
	public ResponseEntity<ErrorResponse> handleDataIntergrityViolationException(
		DataIntergrityViolationException e
	) {
		// 오류 발생 시 리턴할 데이터를 생성하는 로직 작성
		...
	}
}

이를 해결하기 위해 서비스 로직에서 try/catch 구문을 사용해 예외를 처리하거나, @ControllerAdvice와 같은 공통 예외 처리 핸들러에서 예외를 처리할 수 있습니다. 저희 서비스에서는 @ControllerAdvice를 통해 예외를 공통 처리하는 방식을 선택하여 문제를 해결했습니다.