<Spring> AOP 기반 분산락

📌 분산락 도입 배경

jmeter로 여러 유저가 동시에 같은 아키이빙에 스크랩하도록 해봤다.

하지만 count 업데이트가 이상했다.

분명히 유저 10명이 스크랩했는데, 스크랩 수는 10이 아니라 1이었다.

scrap

 

scrap count

동시성 문제가 발생한 것이다.

이로 인해 데이터 정합성이 깨지게 되었다.

이에 필자는 분산락을 도입해 이를 해결하고자 했다.

 

📌 동시성 문제

🔵 동시성

동시성은 여러 작업이 겹쳐서 실행되는 것을 말한다.

이때, 실제로 작업이 동시에 실행된다는 뜻은 아니다.

쉬운 예시로 CPU의 작업 방식을 들 수 있다. 

CPU의 코어에서는 특정 시점에 하나의 작업만 수행 가능하다.

하지만 CPU가 작업 간 전환을 빠르게 하기 때문에, 작업이 거의 동시에 실행되는 것처럼 보일 뿐이다.

 

🔵 동시성 문제

2명의 유저가 있고, 재고 감소 요청을 동시에 했다고 가정하자.

만약 서버에 동시성 처리가 되어있지 않다면, 어떤 상황이 벌어질까?

요청이 정상적으로 처리되지 않을 가능성이 높다.

 

개발하면서 동시성에 관한 문제는 흔히 접할 수 있다.

아래와 같은 예시가 있을 수 있다.

1. 같은 요청을 동시에 했을 경우 (흔히, 따닥이라 부른다)
2. 네트워크 혼잡 때문에, 두 요청이 동시에 도착한 경우
3. 대규모 트래픽이 몰릴 경우

우리는 이런 상황에 Race Condition (경쟁 상태)가 발생했다고 한다.

 

🔵 해결법

위에서 발생한 문제의 경우, 문제를 해결할 수 있는 방법은 다양하다.

1. Java Synchronized, ReentrantLock
2. DB Lock
3. Redis, Zookeeper 등 외부 인프라 이용한 분산락

하나하나 알아보자

 

📌 Java Synchronized

Java에서 동시성을 관리하기 위해 사용하는 메커니즘이다.

 

자바에 내장된 락으로서 이를 암묵적인 락(Intrinsic Lock) 혹은 모니터락(Monitor Lock)이라고 한다.

synchronized 구문을 통해 모니터 영역을 동기화할 수 있다.

public synchronized void decrease(Long id, Long quantity) {
    Stock stock = stockRepository.findById(id).orElseThrow();
    stock.decrease(quantity);
    stockRepository.saveAndFlush(stock);
}

위와 같이 사용할 경우 Race Condition을 해결할 수 있다.

하지만 다음과 같은 경우에서 Synchronized는 의도한 대로 작동하지 않는다.

 

1. @Transactional과 동시에 사용

@Transactional
public synchronized void decrease(Long id, Long quantity) {
    Stock stock = stockRepository.findById(id).orElseThrow();
    stock.decrease(quantity);
    stockRepository.saveAndFlush(stock);
}

위와 같이 사용될 경우 동시성 문제가 발생한다.

이는 @Transactional의 동작 방식과 관련 있다.

@Transactional은 프록시 방식으로 동작한다. 

그러므로 트랜잭션 시작 -> 락 설정 -> 서비스 호출 -> 락 해제 -> 트랜잭션 종료 순으로 진행된다.

만약 트랜잭션 종료 전, 다른 스레드가 같은 메소드에 접근하면 커밋되지 않은 데이터에 접근이 가능하다. 

동시성 문제가 발생 가능하다.

 

2. 다중 서버에서 사용

synchronized는 단일 프로세스에서 잘 작동한다.

하지만 다중 서버일 경우 이는 race condition을 해결하지 못한다.

이에 다중 서버의 환경에 적합하지 않은 방법이다.

 

📌 DB Lock

말 그대로 DB를 이용한 Lock이다.

다양한 방법이 있다.

1. Optimistic Lock : version을 이용하여 정합성을 맞추는 방법
2. Pessimistic Lock : Exclusive Lock을 이용하여 정합성을 맞추는 방법
3. Named Lock : 이름을 가진 Lock을 이용하여 Lock을 거는 방법

이 방법 이외에도, flag column을 이용한 방법도 있다.

이는 기존 연결된 DB를 이용하기 때문에, 추가적인 인프라 도입을 고려하지 않아도 된다.

 

하지만 이 방법을 선택하지 않았다.

애플리케이션과 RDB에 부하를 최대한 적게 가져가고 싶었기 때문이다.

 

낙관적 락의 경우, 애플리케이션이 버전을 관리하며 이에 대한 처리 및 실패 시 후처리를 담당해야 하므로, 

트랜잭션 커밋에 있어서 복잡도가 증가한다.

 

비관적 락의 경우, 데드락의 위험이 높다고 생각했다.

이 위험성을 인지하고 서비스를 구현한다 하더라도, 나중에는 이 부분에 있어서 서비스 구현에 제약이 클 것이라고 생각했다.

 

Named 락의 경우, DB 자원을 더 사용해야 하는 문제가 발생한다.

락 해제 시점 관련 문제 때문에, 로직에 대한 트랜잭션과 DB lock에 대한 트랜잭션을 분리하여 사용해야 한다.

이에 락을 적용한 트랜잭션의 경우 DB 커넥션을 2개 사용해야 한다.

Redisson과 비슷하게 사용할 수 있는 방법이지만, DB 자원을 더 사용한다는 점을 고려하여 사용하지 않았다.

 

또한 이미 분산락을 구현 가능한 Redis라는 인프라 서비스를 도입하여 사용하고 있었다.

이에 필자는 DB Lock을 도입하지 않았다.

 

📌 외부 인프라를 이용한 분산락

분산락을 구현하는데 쓰이는 인프라 기술로 Redis와 Zookeeper를 들 수 있다.

결론부터 말하자면 필자는 Redis를 선택해서 구현했다.

Redis는 이미 사용하고 있었고, 싱글 스레드로 작동하기 때문에 동시성 처리에 적합할 거라 생각했기 때문이다.

또한 애플리케이션과 DB 부하를 줄일 수 있는 방법이라 생각했다.

 

그렇다면 Zookeeper는 왜 선택하지 않았을까?

이미 Redis를 사용하고 있었다는 점이 크게 작용했다. 

또한 Zookeeper를 도입하여 다른 관리 포인트를 추가하는 것이 부담으로 다가왔다.

 

📌 Redis를 이용한 분산락

Redis로 분산락을 이용하는 방법은 2가지 있다.

클라이언트로 Lettuce를 사용하기, 클라이언트로 Redisson을 사용하기

 

1. Lettuce

Lettuce는 기본적으로 락 기능을 제공하지 않는다.

때문에 사용자가 직접 setnx, setex 같은 명령어를 통해 분산락을 구현해야 한다.

이때 락은 Spin Lock 방식이다.

싱글 스레드인 Redis에 Spin Lock은 큰 부하로 이어질 수 있다.

또한 setnx가 expired time을 지정할 수 없어서 Lock 해제가 불가능하다. 

이 때문에 Dead Lock 발생 가능성이 존재한다.

 

2. Redisson

Redisson은 락 기능을 지원해 준다.

pub/sub 방식을 사용하여 락이 해제될 때마다 subscribe 하는 클라이언트들에게 알림을 주는 구조이다.

Lettuce에 비해 Redis에 부하가 더 적게 운영할 수 있다.

 

해당 서비스에 레디스를 이용한 서비스가 많았기에, 레디스에 주어지는 부하가 적은 방법을 선택해야 했다.

그래서 필자는 Redisson을 선택했다.

 

📌 AOP 기반 Redisson 분산락

🔵 Propagation.NEVER

Redisson 분산락을 인터넷에 검색할 경우, 트랜잭션 전파 속성을 REQUIRES_NEW를 사용하는 것을 볼 수 있다.

이 경우 롤백에 문제가 발생할 수 있다.

원래 트랜잭션에서 분산락 처리를 위해 새로운 트랜잭션을 만들면 2개의 트랜잭션이 존재한다.

이때, 어떤 한 트랜잭션이 실패하여 롤백된다고 가정해 보자.

그렇다면 다른 트랜잭션도 롤백할 수 있을까?

할 수 없다.

서로 독립된 트랜잭션이므로, 서로가 서로에게 영향을 미칠 수 없다.

 

이 문제를 락이 설정된 단일 트랜잭션을 이용한다면 동시성 문제를 해결할 수 있을 것이라 생각했다.

단일 트랜잭션이라면, 일부분의 작업이 실패하더라도 모두 롤백이 가능하기 때문에,

위에서 발생 가능한 롤백 관련 문제를 극복 가능할 것이다.

 

이를 구현하기 위해 전파 속성을 NEVER를 이용했다.

전파 속성 NEVER에 대한 설명에 선행 트랜잭션이 존재하면 에러를 발생시킨다라고 적혀있다.

이 말은 NEVER 전파 속성을 이용하면, 선행 트랜잭션이 없음을 보장할 수 있다.

그 후 REQUIRED를 통해 트랜잭션을 생성하면, 선행 트랜잭션이 존재하지 않은 상태에서 트랜잭션을 생성할 수 있다.

또한 이 트랜잭션에서 다른 트랜잭션을 발생시키지 않는다면, 단일 트랜잭션을 유지하는 것이 가능하다.

그러므로 필자는 NEVER 속성을 이용하여 분산락을 구현할 것이다.

 

🔵 AOP

락을 모든 로직에 적용하지 않는다.

특정 로직에만 적용해야 했다.

하지만 이를 적용하기 위해 분산락 로직을 매번 비즈니스 로직에 넣는다면, 비즈니스 로직이 오염될 가능성이 존재한다.

이 지점을 AOP를 사용하여 극복했다.

락이 필요한 부분에 @DistributedLock을 적용하면, 주어진 값에 따라서 락이 설정되도록 구현했다.

구현에 관한 자세한 내용은 다음을 보면 된다.

 

🔵 DistributedLock AOP

DistributedLock

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface DistributedLock {
    // 락 타입
    DistributedLockType lockType();

    // 분산락을 걸 파라미터 네임
    String[] identifier();
}

위에서 설명한 것처럼 AOP를 이용하기 위해 어노테이션을 구현했다.

이는 DistributedLock을 정의하는 어노테이션이다.

락 타입과, 파라미터 이름 인자로 받아서 다중 키에 대한 락에 대응했다.

 

DistributedLockAop

@Aspect
@Component
@RequiredArgsConstructor
public class DistributedLockAop {
    private final LockManager lockManager;

    @Around("@annotation(allchive.server.domain.common.aop.distributedLock.DistributedLock)")
    public Object lock(final ProceedingJoinPoint joinPoint) throws Throwable {
        MethodSignature signature = (MethodSignature) joinPoint.getSignature();
        Method method = signature.getMethod();
        DistributedLock distributedLock = method.getAnnotation(DistributedLock.class);
        return lockManager.lock(joinPoint, getKey(joinPoint, distributedLock));
    }

    private String getKey(ProceedingJoinPoint joinPoint, DistributedLock distributedLock) {
        MethodSignature methodSignature = (MethodSignature) joinPoint.getSignature();
        String[] methodParameterNames = methodSignature.getParameterNames();
        return REDISSON_LOCK_PREFIX
                + distributedLock.lockType().getLockName()
                + "-"
                + createDynamicKey(
                        methodParameterNames, joinPoint.getArgs(), distributedLock.identifier());
    }

    private String createDynamicKey(
            String[] methodParameterNames, Object[] methodArgs, String[] identifiers) {
        List<String> resultList = new ArrayList<>();
        for (String identifier : identifiers) {
            int indexOfKey = Arrays.asList(methodParameterNames).indexOf(identifier);
            Object arg = methodArgs[indexOfKey];
            if (arg == null) {
                throw InvalidLockIdentifierException.EXCEPTION;
            }
            resultList.add(arg.toString());
        }
        return String.join(":", resultList);
    }
}

DistributedLock 어노테이션의 실질적인 동작을 구현한 코드이다.

AOP에서는 키를 만드는 작업까지만 진행하고, Lock에 대한 구현은 LockManager가 처리한다.

키는 어노테이션에 주어진 인자 이름을 가진 파라미터 값을 가져와서 동적으로 키를 생성하도록 구현했다.

이로써 더 구체적인 값을 이용하여 락을 걸 수 있었고, 락을 설정할 수 있는 범위를 넓게 가져갈 수 있었다.

AOP가 처리하는 작업과 Lock을 실질적으로 설정하는 작업을 분리하기 위해,

Lock 설정 관련 작업은 LockManager가 진행했다.

 

LockManager

@Component
public interface LockManager {
    public Object lock(ProceedingJoinPoint joinPoint, String key) throws Throwable;
}

락을 담당하는 인터페이스이다.

 

LockManagerImpl

@Component
@RequiredArgsConstructor
@Slf4j
public class LockManagerImpl implements LockManager {
    private final RedissonClient redissonClient;
    private final TransactionTemplate txTemplate;

    public Object lock(ProceedingJoinPoint joinPoint, String key) throws Throwable {
        RLock rLock = redissonClient.getLock(key);
        log.info("lock : {}", key);
        try {
            boolean available = rLock.tryLock(LOCK_WAIT_TIME, LOCK_LEASE_TIME, TimeUnit.SECONDS);
            if (!available) {
                return false;
            }

            TransactionCallback txCallback =
                    status -> {
                        try {
                            return joinPoint.proceed();
                        } catch (Throwable e) {
                            throw TxTemplateExecutionFailException.EXCEPTION;
                        }
                    };
            return executeTransaction(
                    status -> executeTransaction(txCallback, PROPAGATION_REQUIRED),
                    PROPAGATION_NEVER);
        } catch (InterruptedException e) {
            throw InterruptRedissonException.EXCEPTION;
        } finally {
            try {
                log.info("unlock : {}", key);
                rLock.unlock();
            } catch (IllegalMonitorStateException e) {
                throw AlreadyRedissonUnlockException.EXCEPTION;
            }
        }
    }

    private <T> Object executeTransaction(TransactionCallback<T> block, int propagationBehavior) {
        txTemplate.setPropagationBehavior(propagationBehavior);
        return txTemplate.execute(block);
    }
}

LockManager의 구현체로 앞서 말한 것과 같이 Lock에 대한 작업을 수행한다.

작업 수행 순서는

락 설정 -> tx NEVER -> tx REQUIRED -> 작업 -> 커밋 -> 락 해제

이다.

 

트랜잭션 관련 작업 모두가 락의 내부에서 진행되어야 한다.

이런 상황이 있다고 가정해 보자.

만약 커밋이 변경은 했고 락이 해제되었지만 커밋되지 않은 상황을 다른 유저의 입장에서 보면,

락이 해제되었으므로 이 작업을 본인이 수행할 수 있는 것이다.

즉, 커밋된 데이터를 기반으로 작업하는 게 아니라 커밋 이전 데이터를 기반으로 작업하게 된다.

동시성 문제가 발생한다.

락 내부에서 트랜잭션이 전부 진행되지 않으면 이러한 일이 발생한다.

이러한 상황을 트랜잭션 작업 모두가 락 내부에서 이루어지도록 하면 해결 가능하다.

락 내부에서 작업을 모두 다 할 경우 다른 트랜잭션이 현재의 트랜잭션의 영향을 받지 않으므로, 동시성을 유지할 수 있다.

그러므로 락 내부에서 트랜잭션 작업이 모두 진행되어야 한다.

 

또한 트랜잭션 NEVER로 실행 후, 트랜잭션 REQUIRED를 또 실행했다.

이유는 NEVER의 특성에 있다.

NEVER는 선행 트랜잭션이 없음을 보장해 준다.

하지만 트랜잭션이 없을 때, 새로운 트랜잭션을 만들어주지 않는다.

그러므로 이어진 트랜잭션 작업들은 독립적인 트랜잭션으로 처리되어 버린다.

로직 내부 트랜잭션을 하나로 묶어주는 작업이 필요했고, 이를 REQUIRED로 처리했다.

 

위 두 과정을 통해 락이 설정되고 선행 트랜잭션이 존재하지 않은 상태에서 트랜잭션을 생성하여 로직을 처리할 수 있었다.

 

위 코드는 아래와 같이 사용될 것이다.

@DistributedLock(
        lockType = DistributedLockType.ARCHIVING_PIN,
        identifier = {"archivingId", "userId"})
public void execute(Long archivingId, Boolean cancel, Long userId) {
    validateExecution(archivingId, userId, cancel);
    archivingDomainService.updatePin(archivingId, userId, !cancel);
}

 

이와 같은 방법을 통해 필자가 원했던 AOP 기반 분산락을 구현할 수 있었다.

 

📌 마무리

위와 같은 방법으로 문제라 생각했던 지점을 극복할 수 있었다.

 

하지만 이 방법이 완벽한 방법은 아니라 생각한다.

아래와 같은 문제가 있을 수 있다고 생각한다.

1. 서비스 로직 전체에 적용해야 한다.
   트랜잭션이 설정된 상태에서 수행되는 로직의 수행 시간이 길어진다면, 락 설정 시간이 길어진다.
   이는 곧 해당 락에 관련된 서비스에 작업이 불가능하다는 말이고,
   이로 인해 전체적인 서비스 품질이 저하될 수 있다.
2. NEVER 설정 값 때문에, 비즈니스 로직 수행 중 일부분에만 적용할 수 없다.
   이를 처리하기 위해선 비동기 처리를 통해 일부분만 실행해야 한다.
   롤백 문제를 해결하기 위해 고안한 방법이 오히려 롤백 관련 문제를 발생시킬 수 있어진다.

 

더 좋은 방법이 있을지 고민해 봐야겠다.