[Redis] 레디스 분산 락 이해하기

이전 글에 이어서 분산락 관리 라이브러리 선택 기준과 레디스를 통한 분산 락 적용과정에 대해 다뤄볼 예정이다.

 

---

☑️ Lettuce / Redisson

 

이 둘 모두 레디스의 분산 락 관리 라이브러리이다. 분산 락을 처음 구현했을 때 나는 단순한 분산 락만을 사용할 것이라면 Lettuce를 사용하여 분산락을 직접 구현하는 것이 라이브러리의 크기를 고려했을 떄 더 효율적일 것이라고 판단했다. 하지만 Lettuce에는 스핀락으로 인한 부하, Atomic한 타임아웃 설정 불가능 등 여러 단점이 존재했고 이러한 단점들을 보완한 라이브러리인 Redisson에 대해 알아봤다.

 

1. Atomic TimeOut

Redisson은 tryLock 메서드에 타임아웃을 지정할 수 있다. 아래와 같이 첫 번째 파라미터는 락 획득을 대기할 타임아웃을, 두 번째 파라미터에는 락이 만료되는 시간을 지정할 수 있다.

첫 번째 파라미터만큼의 시간이 지나면 false가 반환되며 두 번째 파라미터만큼의 시간이 지나면 락이 만료되어 사라지기 때문에 애플리케이션에서 직접 락을 해제해주지 않더라도 다른 스레드에서 락을 획득할 수 있다.

이로 인해 락이 해제되지 않은 채로 앱이 예기치 않게 종료되어 무한 루프에 빠질 수 있는 문제를 해결할 수 있다.

// RedissonLock의 tryLock 메서드
public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException

 

 

2. PUBSUB

`setnx`, `setex`와 같은 명령어를 통해 지속적으로 Redis에게 락이 해제되었는지 요청을 보내는 스핀 락 방식을 사용하는 Lettuce와 달리 Redisson은 pub/sub 기능을 통해 락 해제 시 알림을 클라이언트에게 보내 락 획득 가능 여부를 확인한다. 이를 통해 Redis에 가해지는 불필요한 트래픽을 줄일 수 있고, 락이 해제되면 메시지를 받은 클라이언트는 락 흭득을 다시 시도하게 된다. 또한 락 획득은 tryLock 메서드를 사용하여 경합이 없을 때 빠르게 수행되며, 실패 시 pub/sub을 통해 대기하면서 타임아웃시까지 재시도를 반복한다.

 

3. Lua Script

락 관련 연산은 원자적이어야 하기 때문에, 명령어가 섞이지 않도록 Lua 스크립트를 활용하여 Atomic한 연산을 보장할 수 있다. 락의 획득 및 해제 과정에서 여러 연산을 묶어 한 번에 처리하며, 특히 pub/sub 알림과 락 해제를 원자적으로 수행해야한다. 그렇지 않으면 락 획득이 가능하다고 응답받은 다음, 락 획득시도를 했는데 그 사이에 이미 다른 스레드에서 락을 획득해버려서 락 획득을 실패하는 경우가 생길 수 있다. 결론적으로, 이를 통해 성능을 유지하면서도 Redis에 가해지는 부하를 줄이고, 정확한 락 동작을 보장한다. Redisson은 이러한 Lua Script를 적극적으로 활용하고 있다.

 

String luaScript = 
    "if redis.call('exists', KEYS[1]) == 0 then " + 
    "redis.call('set', KEYS[1], ARGV[1]); " + 
    "redis.call('pexpire', KEYS[1], ARGV[2]); " + 
    "return 1; " + 
    "else " + 
    "return 0; " + 
    "end;";

// Lua script 실행코드
Object result = redisson.getScript().eval(RScript.Mode.READ_WRITE,
    luaScript, 
    RScript.ReturnType.INTEGER, 
    Collections.singletonList(lockKey), 
    lockValue, lockTTL);

 

 

☑️ 분산락 구현

 

분산락은 횡단 관심사에 포함되기 때문에 AOP를 사용하여 구현한다면 메인 로직과의 분리함으로써 유지보수성을 높이고 직관적인 구현이 가능해진다. 또한 분산락은 특정 도메인에 한정되어 사용되는 것이 아니기 때문에 `execution`이나 `args` 포인트컷보다는 `annotation`을 사용했다. 이를 위해 먼저 애노테이션을 구현했다.

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface DistributedLock {

    String key();
    TimeUnit timeUnit() default TimeUnit.SECONDS;
    long waitTime() default 5L;
    long leaseTime() default 3L;
}

 

AOP를 구현할 때에 대부분의 경우 `@Around` 어드바이스를 사용하게 된다. 분산 락을 구현할 때는 메서드 호출 전후에 실행되어야하기 때문에 해당 어드바이스를 사용했지만, 이와 같은 경우가 아니라면 `@Before`, `@AfterReturning`과 같은 어드바이스를 사용함으로써 제약을 두는 것이 더 좋은 설계라는 것을 항상 염두해둬야한다.

 

 

 

DistributedLockAop.java

@Aspect
@Component
@RequiredArgsConstructor
@Sl4j
public class DistributedLockAop {
    private static final String REDISSON_LOCK_PREFIX = "LOCK:";

    private final RedissonClient redissonClient;
    private final AopForTransaction aopForTransaction;

    @Around("@annotation(com.dnd.matchup.aop.DistributedLock)")
    public Object lock(final ProceedingJoinPoint joinPoint) throws Throwable {
        MethodSignature signature = (MethodSignature) joinPoint.getSignature();
        Method method = signature.getMethod();
        DistributedLock distributedLock = method.getAnnotation(DistributedLock.class);

        String key = REDISSON_LOCK_PREFIX + distributedLock.key();
        RLock rLock = redissonClient.getLock(key);

        try {
            boolean available = rLock.tryLock(distributedLock.waitTime(), distributedLock.leaseTime(), distributedLock.timeUnit());
            if (!available) return false;
            return aopForTransaction.proceed(joinPoint);
        } catch (InterruptedException e) {
            throw new InterruptedException();
        } finally {
            try {
                rLock.unlock();
            } catch (IllegalMonitorStateException e) {
                log.info("Redisson Lock Already UnLock {}", key);
            }
        }
    }
}

 

위 코드에서는 먼저 `rLock`을 가져온 후 `tryLock`을 통해 애노테이션에 지정된 waitTime 까지 락 흭득을 시도한다. 이후 락을 흭득할 수 있다면 DistributedLock 애노테이션이 선언되어 있는 메서드를 별도의 트랜잭션으로 실행하기 위해 아래와 같이 전파 전략을 `REQUIRES_NEW`로 설정한 트랜잭션이 선언되어 있는 메서드를 실행한다.

 

 

 

AopForTransaction.java

@Component
public class AopForTransaction {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public Object proceed(final ProceedingJoinPoint joinPoint) throws Throwable {
        return joinPoint.proceed();
    }
}

 

위와 같이 트랜잭션을 분리할 경우 하나의 물리 트랜잭션내의 논리 트랜잭션이 추가된는 형태가 아니라, 별개의 물리 트랜잭션이 실행되게 된다. 그렇기 때문에 메인 로직의 트랜잭션이 롤백된다고 해도 락 트랜잭션에서는 흭득과 반납이 정상적으로 이루어지게되어 하나의 스레드가 락을 점유하고 있는 경우를 방지할 수 있다.

 

 

---

 

☑️ 결론

레디스를 이용한 분산락 방식은 레디스가 이미 인프라에 포함되어 있을 경우 좋은 선택지가 될 수 있다. 하지만 싱글 스레드로 작동하는 레디스의 특성상 단일 장애 지점이 될 가능성이 존재한다. 그렇기 때문에 이전 글에서 소개한 Replication이나 Sentinel 아키텍처의 사용이 권장된다. 해당 아키텍처에서는 특정 상황에 데이터 불일치 문제나 경쟁 상태가 발생할 수 있고 이는 레드락 알고리즘을 통해 해결할 수 있다