분산락

Redisson에 대해 정리해보자. 프로젝트에 동시성 충돌문제로 락을 사용하고자 분산락을 적용했는데 왜 굳이 분산락을 사용해야할까?

그이유는

• Redis기반으로 master-slave 분산 데이터서버에서는 개별 서버에서 Lock으로는 동일한 리소스에 대한 접근을 막을 수 없게 된다. 막기 위해서는 모든 서버 노드가 락 정보를 공유하여 이미 락을 점유하여 해당 리소스를 사용하고 있는 노드가 있다면 다른 노드는 해당 리소스에 접근할 수 없다.
• 또한 직접 락 구현시, 락을 점유한 프로세스 가 죽으면 락도 영원히 갇히게 되어 절대 사용할 수 없게 되는 문제가 있는데 분산락은 TTL을 설정해서 일정 시간이 지나면 자동으로 락을 해제시킨다.
• 락 획득 재시도 로직과 락 획득 실패 처리에 대한 로직을 Redisson이 추상화한 로직을 제공하므로 직접구현시 발생할 에러문제를 사전에 방지할 수 있고 편리하다.

위 3가지가 있다. 이때 Redis도 개별 서버 인스턴스로 두며 락 코디네이터 역할을 맡긴다. Redis는 락 정보에 대한 정보를 저장하며 관리한다.

직접 락을 구현하는 것과 Redisson 같은 라이브러리의 분산락을 사용하는 것은 확실한 차이가 있습니다. 핵심은 멀티 서버 환경에서의 동시성 제어 안정성을 목표 사용하는 락입니다.

1. 직접 락 구현의 한계

• 단일 서버 환경에서는 synchronized 나 ReentrantLock 같은 자바 락으로 충분합니다.
• 하지만 서버가 여러 대일 때는?
  • A 서버와 B 서버가 동시에 같은 자원을 수정하려 하면, 각 서버의 메모리에 걸린 락은 서로를 인지하지 못합니다.
  • 즉, 프로세스/서버 단위의 락은 분산 환경에서는 소용이 없습니다.

2. 분산락(Redisson) 사용 이유

Redisson이 제공하는 분산락은 Redis를 중앙 조정자(coordinator)로 사용하여 모든 서버 인스턴스가 동일한 락 정보를 공유하게 합니다.

장점

1. 멀티 서버 동기화
   • 여러 서버가 동시에 같은 자원을 수정하려고 할 때, Redis에 락을 기록해 “나 먼저 잡았어”라고 알리기 때문에 충돌 방지.
2. 자동 만료(Lease Time)
   • 직접 락 구현하면, 락을 잡은 프로세스가 죽었을 때 락이 영원히 풀리지 않는 문제가 발생.
   • Redisson은 TTL(만료시간)을 설정해 장애 상황에서도 자동으로 락이 해제되도록 보장.
3. 고급 알고리즘 (RedLock 등)
   • 단일 Redis 서버가 죽으면 락 관리가 무너질 수 있기 때문에, Redisson은 여러 Redis 노드에 분산된 방식(RedLock)으로 락을 보장할 수도 있음.
4. 편의성과 안정성
   • 재시도 로직, 실패 처리, Pub/Sub 기반 알림 등을 직접 구현하면 복잡하고 버그 위험이 큼.
   • Redisson이 이를 안정적으로 추상화해서 제공.

3. 간단한 비교

방식	특징	한계
직접 락 (synchronized, ReentrantLock)	빠르고 간단, 단일 서버에서만 유효	멀티 서버 환경에서는 무용지물
분산락 (Redisson RLock)	Redis 기반으로 서버 간 공유, TTL 지원, 장애 대응	Redis 의존성 필요, 네트워크 비용 발생

4. 결론

단일 서버 환경 → JVM 락이면 충분

멀티 서버 환경 → Redisson 같은 분산락이 필수