선착순 시스템에서 발생하는 Race Condition을 해결하는 방법

해당 글을 작성하게 된 계기는 발급할 수 있는 쿠폰의 개수가 한정되어 있고, 현재까지 발급된 쿠폰의 수에 따라 선착순으로 쿠폰을 발급해야 하는 경우 어떻게 동시성을 처리할 수 있을까에 대한 호기심이었다.

우선 상황은 이러하다.

1. 서버가 여러 개로 싱글 스레드로 해결 불가능하다.
2. 서버가 1대인 상황이더라도, 선착순 쿠폰 생성 전체 로직을 싱글 스레드로 처리하는 것은 매우 비효율적이다.
3. Redisson의 RLock과 같은 방법은 현재 상황에 비효율적이다.

 

먼저 2번, 3번이 비효율적인 이유는 아래와 같다. (RLock에 대해서는 다음 포스팅을 참고해 주세요!)

 

 

쿠폰의 재고를 파악하고 재고가 남아있으면 신규 쿠폰을 생성한다라는 관점에서 굳이  재고조회부터 저장까지의 로직을 Lock 과정을 통해 처리한다면 Lock이 걸리는 구간이 길어져 성능에 문제가 발생할 수 있다.  

 

물론, 실무에서는 여러 가지 추가되는 비즈니스가 있겠지만 우선 간단하게 생각해 보면
Redis와 같이 싱글 스레드로 동작하는 공유자원에서 쿠폰을 발급하기 전에 현재까지 만들어진 쿠폰의 개수를 증감시켜 줄 수 있다. 

그리고 redis에서 리턴되는 발급된 쿠폰의 개수가 제한된 숫자보다 크다면 발급을 하지 않는 로직을 적용할 수 있다.

redis-cli에서 특정 key의 value를 증감시키는 명령어는 아래와 같다.

incr key:value

 

여기서 key는 현재까지 발급된 쿠폰의 개수이고, 서버의 요청 때마다 value는 1씩 증감시킬 수 있다.

 

 

Spring에서 코드를 작성한다면 Redis에 저장된 발급된 쿠폰의 개수를 추적하는 Repository를 생성하고
실제 아래 코드로 증감시킬 수 있다.

public Long increment() {
	return redisTemplate
    		.opsForValue()
           	 .increment("key_name")
}

 

 

추가적으로, 1인당 1개라는 제한이 생긴다면 어떻게 동시성을 처리해야 할지 생각해봐야 한다.

 

 

생각해 볼 수 있는 방법은 단순하게 쿠폰 발급 로직에 Lock을 이용하여 해결할 수 있겠지만 Kafka와 같은 데이터 스트리밍 도구를 사용한 경우에는 실제 Consumer가 쿠폰을 DB에 insert 하는 시간까지 텀이 발생하므로 적용하지 못할 수 있다.

 

따라서, 다른 방법으로 Redis에서 Set 자료구조를 이용하여 해결할 수 있다.
관련 redis-cli 명령어는 아래와 같다.

sadd key value

해당 명령어는 해당 key의 Set에 value가 없으면 추가된 value의 개수를 반환하고, 이미 value가 존재하면  0을 반환한다.

 

Spring에서 Set을 활용하기 위한 코드를 작성해 본다면 아래와 같다.

public Long addCouponSet(Long userId) {
	return redisTemplate
    		.opsForSet()
            	.add("key_name", userId.toString());
}

따라서 쿠폰 발급 로직에서는 redis에서 반환된 Long값이 1이 아닌 경우에는 예외가 발생하도록 처리할 수 있다.