[TIL] 분산락

📌 분산락 이란?

 다수의 서버(또는 프로세스)가 동시에 같은 자원을 접근할 때, 발생할 수 있는 동시성 문제를 해결하기 위해 사용되는 동기화 매커니즘. ‘중앙화된 락 관리 시스템' 을 사용하여 분산된 환경에서 락을 걸고 관리한다.

• 락 관리 : 만료시간 설정, 락 갱신, 락 해제
• 장점: 서버 분산 환경에서도 프로세스들의 원자적 연산이 가능.

• 락을 획득한 프로세스 또는 스레드 만이 공유자원(or Critical Section)에 접근할 수 있도록 하는 것.
• 특정 자원에 대한 접근을 제어하기 위해 네트워크를 통해 락 설정

 

📌 분산락을 구현하는 여러가지 방법

• 정확히 말하자면, 락을 관리하는 중앙 관리 시스템을 무엇으로 할지

1) Zookeeper

 분산 서버 관리시스템으로 분산 서비스 내 설정 등을 공유해주는 시스템.하지만 추가적인 인프라 구성이 필요하고 성능 튜닝을 위한 러닝커브가 존재. 현재는 분산락 이외에 이용할 용도가 없으므로 이용하지 않는것이 좋다고 판단.

 

2) MySQL

MySQL은 추가적인 인프라 구성없이 문자열로 거는 User Level Lock으로 분산락을 직접 구현할 수 있다. 하지만 아래의 단점이 있다.

• 락을 자동으로 반납할 수 없어(timeout X) 명시적으로 락을 release 시켜야 한다.
• DB에서 락을 관리하기 때문에 DB에 부담이 여전히 존재한다.
• 락 획득 시도는 스핀락으로 구현해야하기 때문에 WAS에도 부담이 존재한다.

 

3) Redis (선택)

Zookeeper와 마찬가지로 별도의 인프라를 구축하고 관리해야하지만 아래의 장점이 있다.

• 인메모리 DB로 속도가 빠르다.(초당 100,000 QPS 의 속도)
• 싱글스레드 방식으로 동시성 문제가 현저히 적다.
• 캐시 저장소로 활용이 가능하다.(다양한 자료구조 지원)

 

😀 분산락 구현 방식으로 레디스를 선택한 이유

💡 팀에서 대기열을 구현 및 캐싱 기능을 위해 해당 기술 스택을 사용 중이어서, 추가 인프라 구축이 필요 없다는 것이 가장 컸다.

 

✅ 지금까지의 문제 & 앞으로의 목표

📍 문제

 

[ 결제 상품 재고 관리]

⇒ 비관적 락을 이용해 구현했었다.

• DB 자체에 락을 거는 방식이라 응답시간이 동시 200건 처리에 6초로 늦어짐.
• 동시 요청 건수를 늘리면, timeout으로 실패하는 요청이 많아짐
• DB 성능에 따라, 단일 병목지점이 되어버릴 수 있다.
• 트랜잭션이 정상적으로 종료되지 않으면, DB에 Lock이 걸린 상태로 남아있어 데드락의 위험성이 있었다. (이건 DBMS가 트랜잭션 timeout으로 처리함)

 

[ 대기열 순번 처리 ]

⇒ Redis의 Sorted Set을 이용해 구현한 대기열에서 현재 대기열에 있는 사용자를 조회하고 사용자수+1

• rank를 조회해서 리턴하는 과정에서 동시성 제어가 되지 않는 문제가 발생.
• 구체적으로는 사용자 A와 사용자 B가 동시에 구매하기 버튼을 눌렀을 때, 둘다 순번이 1로 떴다.

 

📍 목표

• Redis를 이용해 분산락을 구현해서 결제 상품 재고 관리시 응답속도 향상(정말 줄어드는지 체크 해봐야함)
• 대기열 동시성 제어

 

🐤 Redis를 이용한 분산락 구현

✔️ 대표적인 자바의 Redis 클라이언트

➡️ Jedis, Lettuce, Redisson

Lettuce

• Spring 2.x.x 이후부터, default로 사용되는 redis 클라이언트
• Lettuce로 분산락을 사용하기 위해서는 setnx , setex 등을 이용해서 분산락을 직접 구현해야함
• 개발자가 직접 retry, timeout과 같은 기능을 구현해야하는 번거로움이 있음

⇒ 스핀락이라는 일종의 polling 기법을 활용해서 Lock 획득을 시도 (주기적으로 계속 요청)

 

Redission (선택)

• RedLock 알고리즘을 자바로 구현한 라이브러리
• 별도의 Lock interface 지원. (락에 대해 timeout과 같은 설정 지원)

⇒ Redis의 pub/sub 기능을 사용해 Lock 획득을 재시도.

• Lock 획득을 실패하면, Redission은 특정 채널을 구독하고, Lock이 다시 획득할 수 있는 상태가 됐다는 이벤트를 받았을 때, 다시 Lock 획득 시도

 

😀 Redis client로 Redission 선택한 이유

💡 별도의 Lock interface를 지원해주는 점에서 개발의 편의가 있고, 락 획득 방식이 redis의 pub/sub 기능을 이용한다는 점에서 Lettuce 보다 서버에 부담이 적다고 판단하였다.

 

✅ Redission으로 Redis 클라이언트 설정하기

build.gradle에 의존성 추가

implementation 'org.redisson:redisson-spring-boot-starter:3.18.0'