Redis 분산 락

redis는 자체적으로 락을 제공하는 기능이 아니라, Redis의 특징인 원자성과 Key-Value 데이터 모델을 활용해 락 기능을 구현하는 방식이다.

락을 설정(Lock)

Redis에서 가장 많이 사용하는 락 구현 메커니즘은 SET NX(Not Exists) 옵션을 활용하는 방식이다.
1
2

Boolean acquired = redisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, Duration.ofSeconds(LOCK_TIMEOUT_SECONDS));
- Key 생성 : 고유 식별 값 lockKey를 사용자가 만들어 락을 생성한다.
- Value 설정 : 락을 획득한 사용자의 고유 식별자(requestId)를 저장하여 누가 락을 가진 상태인지 추적한다.
- NX 옵션 : SET NX 옵션을 사용하여, 해당 키가 없을 때만 락을 생성한다. 이미 존재한다면 새로운 락을 생성하지 않아 충돌을 방지한다.
- TTL(만료 시간) : 락에 만료 시간을 설정(EX옵션)하여, 특정 시간 이후 Redis가 자동으로 해당 키를 제거한다 -> 데드락 방지를 목적으로

원자적 동작

Redis의 모든 명령은 기본적으로 단일 스레드로, 명령 실행이 완전히 끝날 때까지 다른 요청이 처리되지 않는다.
즉 Redis는 락을 생성하는 작업(키가 존재하지 않을 때 설정)을 원자적으로 처리하므로 동시성 문제를 방지할 수 있다.

락의 해제(Unlock)

Redis 락을 해제하려면
1. 자신의 락인지 확인: 락 보유한 사용자가 다른 사용자가 아닌 자신임을 검증하기 위해, GET 명령을 사용해 Key의 Value를 확인한다.
2. 락 해제 시도:
  - 이후, 올바른 식별자일 경우에만 DEL 명령을 사용하여 락을 해제한다.
  - 락 해제 두 단계를 분리하여 GET -> DEL 처리하면 원자성이 깨질 수 있다
  - 이 문제를 해결하기 위해 Lua 스크립트를 사용하는 방식을 사용할 수 있다

	String lockKey = LOCK_KEY_PREFIX + couponCode;  
	String script =  
	        "if redis.call('get', KEYS[1]) == ARGV[1] then " +  
	                "   return redis.call('del', KEYS[1]) " +  
	                "else " +  
	                "   return 0 " +  
	                "end";  
	  
	try {  
	    redisTemplate.execute(  
	            new DefaultRedisScript<>(script, Long.class),  
	            Collections.singletonList(lockKey),  
	            requestId  
	    );  
	} catch (Exception e) {  
	    log.warn("락 해제 중 에러 발생. lockKey: {}, requestId: {}", lockKey, requestId, e);  
	}

Redis 락의 전체 흐름

정리해서 전체적인 흐름을 알아보자

락 생성 시도
- SET NX 명령을 통해 락을 생성한다
- 락이 없으면 생성에 성공 True 반환
- 락이 존재하면 생성에 실패 False 반환
TTL 설정
- 락이 생성할 때 만료 시간(EX옵션)을 함께 지정한다
락 작업 중
- 락을 얻은 사용자는 안전하게 작업을 수행한다
- 락 작업 도중 장애가 발생하더라도 TTL 에 따라 자동으로 해제된다
락 해제
- 작업이 완료되면 락을 점유한 사용자가 Key의 Value를 확인하고 일치하면 DEL 명령으로 해제
- 락이 이미 만료되었다면, 다른 사용자가 락을 새로 생성 가능

쿠폰 발급 프로젝트에서 락 획득 구현 방식

데이터 통신 시간에 CSMA/CD라는 방식을 배웠다. 간단하게 설명하면 어떤 데이터를 보내기 전에 일단 듣고 아무도 안보낼때 보내어 충돌 확률을 줄이고 충돌이 났더라도 지수적으로 backoff를 하여 충돌이 날 수록 지수적으로 늘어나는 범위 안에서 random number를 골라서 던지는 방식으로 충돌이 생길 때 대응하는 일종의 방법론 같은 것이다.

이걸 듣는 순간 아! Redis의 분산락도 lock을 얻는 과정에서 충돌이 생길 수 있고 이 방법을 적용하면 효율적으로 이미 검증된 방법을 사용하여 충돌을 해결할 수 있겠다 라고 생각이 들어 바로 적용해 보기로 했다.

하지만 CSMA/CD의 방식을 모두 구현한 것은 아니다. 이유는 환경이 다르기 때문인데 CSMA/CD는 단일 네트워크 채널상의 충돌을 감지 및 해결을 하기에 랜덤 윈도우를 점차적으로 늘려 충돌 빈도 자체를 줄이는데 중점이라면 Redis 락의 경우 분산 환경에서 동시성을 제어를 위해 설계되었고, 재시도 타임아웃과 지터 축소를 통해 락 성공 가능성을 높이는데 중점이 있다.

그래서 충돌 완화, 지수적 백오프, 랜덤화 이 세가지의 어떤 아이디어는 빌려오지만 이것을 구현하는데는 차이가 있다.

충돌 감지 방식
- Redis 락은 충돌을 감지라기 보다는 경합상황이 해소되지 않는다면 재시도를 한다. 살짝 간접적으로 충돌을 감지
재시도 방식
- Redis 락은 재시도를 하다가 일정 시간안에 락을 얻지 못하면 시도를 중단하고 락 생성 실패를 반환
- 이유는 최대한 빠른 락 획득 또는 시간 초과 예외 처리가 주요한 요구사항이기 때문이다.
지터의 역할

지터 : 지수 백오프에서 대기 시간을 조정하기 우해 적용하는 랜덤값
- CSMA/CD는 충돌이 많을 수록 랜덤 간격 내에서 선택하는 범위가 커진다
- 하지만 Redis락의 경우 반대로 재시도 획수가 많아질수록 지터 범위를 점차 줄인다
- 이유는 초기에는 경합상황이 비교적 많지만 시간이 지남에 따라 다른 클라이언트들이 자연스럽게 종료(락 해제, TTL 만료) 되기 때문이다
- 지터의 축소로 오히려 락 획득 성공률 자체를 높이게 된다
락 키 생성
- 쿠폰코드를 기반으로 유니크한 키를 생성한다.
- ex) coupon:lock:COUPON123
타임아웃(획득 제한 시간) 및 백오프 초기화 설정
- backoffTime : 재시도 간 대기 시간 초기값
- deadline : 락 획득 시도를 언제까지 반복 할지에 대한 설정
락 획득 시도
- isLockHeld()를 통해 현재 락 키가 이미 존재하는지 확인
- key가 없다면 NX와 EX 옵션을 사용하여 락 획득 시도
- 락을 획득 했다면 true 반환
락 획득 실패 시 재시도
1. 재시도 종료 조건
  - deadline이 초과되었는가?
  - 재시도 횟수retryCount가 최대에 도달했는가?
2. 지수 백오프 적용
  - 실패 횟수에 따라 대기시간(backoffTime)이 점진적으로 증가
  - calculateBackoffTime() 에 랜덤 지터(jitter)를 추가해 충돌 방지
3. 백오프만큼 대기 후 재시도:
  - 재시도 횟수가 늘어나면 늘어날 수록 대기 시간 자체는 늘리 돼 범위(지터) 자체는 줄여 효율적으로 락 획득을 가능 하도록 구현

재시도 횟수	승수(대기 시간 증가율)	지터 범위(%)
1회	x1.5	±15%
2회	x2.0	±13.6%
3회	x2.5	±12.5%
4회	x3.0	±11.5%

후에 테스트를 진행하면서 지터 범위를 조정해봐야겠다.