[Redis] 분산 비관적 락으로 동시성 이슈 해결하기

0. 동시성 이슈와 해결 방법

동시성 이슈는 여러 스레드나 프로세스가 동시에 같은 리소스에 접근하려 할 때 발생한다.

 

동시성 이슈를 해결하기 위해 여러가지 방법이 있다.

 

이번 프로젝트에서 발생한 동시성 이슈를 해결해 보려고 한다.

 

먼저, Spring Boot 환경에서 동시성 이슈를 해결할 수 있는 몇 가지 방법을 알아보겠다.

 

0-1. 락 (Lock)

락은 멀티 스레드 환경에서 공유 리소스에 대한 동시 접근을 제어하는 동기화 메커니즘이다.

 

락을 통해 데이터 일관성을 유지하고 Race Condition을 방지한다.

 

0-1-1. 낙관적 락 (Optimistic Lock)

낙관적 락은 데이터를 읽을 때 락을 걸지 않는다. 보통 버전 번호나 타임스탬프를 이용하여 데이터 변경을 감지한다.

 

충돌이 감지되면 예외를 발생시키고, 재시도를 실행한다.

 

보통 읽기 작업이 많고 충돌이 적은 환경에서 성능이 좋다.

 

동시성이 높고 Deadlock이 발생하지 않지만, 재시도 매커니즘에 의해 성능 저하의 우려가 있다.

 

0-1-2. 비관적 락(Pessimistic Lock)

충돌이 자주 일어나는 상황에서, 데이터를 읽거나 수정하기 전에 명시적으로 락을 거는 방법이다.

 

락을 획득하지 못했을 경우, 락이 해제될 때까지 대기한다.

 

데이터의 일관성을 강하게 보장할 수 있다.

 

0-2. 동기화(Synchronization)

Java에는 동시성을 제어할 수 있는 synchronized를 사용할 수 있다.

 

동기화된 영역에 한 번에 하나의 스레드만 접근할 수 있다.

 

public class Counter {
    private int count = 0;

    public synchronized void increment() {
        count++;
    }

    public synchronized int getCount() {
        return count;
    }

    public void incrementWithBlock() {
        synchronized(this) {
            count++;
        }
    }
}

 

synchronized를 통해 한 번에 하나의 스레드에 의해서만 실행될 수 있는 함수로 사용할 수 있다.

 

0-3. 원자적 연산(Atomic Operations)

원자적 연산은 java.util의 atomic을 사용하는 방법이다.

import java.util.concurrent.atomic.AtomicInteger;

public class SimpleAtomicExample {
    private static AtomicInteger counter = new AtomicInteger(0);

    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(SimpleAtomicExample::incrementCounter);
        Thread t2 = new Thread(SimpleAtomicExample::incrementCounter);

        t1.start();
        t2.start();

        t1.join();
        t2.join();

        System.out.println("Final count: " + counter.get());
    }

    private static void incrementCounter() {
        for (int i = 0; i < 1000; i++) {
            counter.incrementAndGet();
        }
    }
}

 

위 예시에서 AtomicInteger를 사용하지 않고 그냥 int를 사용했다면 Race Condition에 의해 최종 값은 2000이 되지 않았을 것이다.

 

0-4. 트랜잭션 격리 수준 조정

데이터베이스 수준에서 동시성을 제어하는 방법으로, 트랜잭션들이 서로에게 어느 정도의 영향을 미칠 수 있는지를 정의한다.

 

격리 수준이 높을수록 데이터 일관성은 향상되지만, 동시성은 낮아진다.

 

• READ UNCOMMITTED: 가장 낮은 격리 수준. 다른 트랜잭션의 커밋되지 않은 변경사항도 읽을 수 있다.
• READ COMMITTED: 커밋된 데이터만 읽을 수 있다.
• REPEATABLE READ: 트랜잭션 내에서 같은 쿼리를 실행하면 항상 같은 결과를 보장한다.
• SERIALIZABLE: 가장 높은 격리 수준. 트랜잭션을 완전히 분리하여 순차적으로 실행한 것과 같은 결과를 보장한다.

 

1. WAS 환경에서 가장 효율적인 해결 방법

WAS환경, 특히 여러 서버가 동작하는 분산 환경에서는 분산 락(Distributed Lock)이 효과적이다.

 

Java의 기능을 사용하는 방법은 한계가 많고, 트랜잭션 격리 수준 설정은 높은 격리 수준에 의해 동시성이 크게 저하될 수 있다.

 

따라서 분산 비관적 락이 효율적이다.

 

2. Redis 클라이언트 선택

비관적 락은 Redis를 활용하여 구현할 계획인데, Redis는 여러 클라이언트가 있다.

 

2-1. Lettuce

• Spring Boot 2.0 이후 기본 Redis 클라이언트
• 비동기 지원, 뛰어난 성능
• 스레드 안전

2-2. Jedis

• 간단하고 직관적인 API로 사용이 쉬움
• 동기식 작업만 지원

2-3. Redisson

• 분산 락, 세마포어, 리더 선출 등 다양한 분산 객체 및 서비스 제공
• 비동기 및 반응형 인터페이스 지원

 

기본적으로 Jedis보다 Lettuce가 비동기를 지원하면서 성능이 더 우수하기 때문에, Jedis 보다 Lettuce가 더 좋은 선택이다.

 

2-4. Lettuce vs Redisson

Lettuce

Lettuce는 setnx(SET if Not eXist) 명령어를 통해 스핀 락을 구현하게 되는데, 만약 timeout을 지정하지 않는다면 무한 루프에 돌 수 있다.

 

timeout을 설정하더라도 락 획득을 무한정으로 시도하다 보면 Redis에 많은 부하가 걸리게 되고, 이는 성능 저하로 이어질 수 있다.

 

Redisson

 

Redisson은 Non-Blocking I/O 작업을 사용한다.

 

Redisson의 특징은 직접 Redis의 명령어를 제공하는 것이 아닌, Bucket, Map, Lock과 같은 구현체를 통해서 사용한다.

 

또한, Redisson의 구현체에는 타임아웃이 구현되어 있다.

package org.redisson.api;

Redisson의 구현체인 RLock에서 타임아웃 시간을 전달할 수 있다.

 

락 획득에 실패하게 된다면 false를 반환하게 된다.

 

추가로, Redisson은 Lettuce와 다르게 스핀 락을 사용하지 않고 Pub/Sub 구조로 락의 획득 가능 여부를 체크한다.

 

락이 해제되는 시점에 Subscriber들에게 락 획득 시도 가능음 알려줌으로써, Redis에 요청되는 부하가 줄어들게 된다.

 

Lua Script

Redisson은 Lua 스크립트로 atomic 연산을 지원하면서, 락의 획득 가능 여부와 확인의 원자성을 보장하게 된다.

 

트랜잭션은 명령어를 트랜잭션으로 묶는 기능이므로, 명령어의 결과를 받아서 다른 연산에 활용하는 atomic한 연산을 구현하기 어려운데, 

 

Lua 스크립트를 통해 쉽게 구현할 수 있다.

 

 

 

 

3. 구현

구현은 스프링 AOP와 SpEL을 활용했다.

 

3-1. 의존성

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

 

 

 

3-2. RedissonConfig

import org.redisson.Redisson;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class RedissonConfig {

    @Bean
    public RedissonClient redissonClient() {
        Config config = new Config();
        config.useSingleServer().setAddress("redis://localhost:6379");
        return Redisson.create(config);
    }
}

 

Redis 서버를 연결해주는 클라이언트를 빈으로 등록해둔다.

 

3-3. @RedissonLock

import java.lang.annotation.*;

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface RedissonLock {

    String value();

    long waitTime() default 5000L;

    long leaseTime() default 3000L;
}

 

락이 필요한 함수나 트랜잭션에 어노테이션을 붙여 사용할 용도의 인터페이스이다.

 

3-4. RedisLockSpELParser

public final class RedisLockSpELParser {

    public static Object getLockKey(String[] parameterNames, Object[] args, String key) {
        SpelExpressionParser parser = new SpelExpressionParser();
        StandardEvaluationContext context = new StandardEvaluationContext();

        for (int i = 0; i < parameterNames.length; i++) {
            context.setVariable(parameterNames[i], args[i]);
        }

        return parser.parseExpression(key).getValue(context, Object.class);
    }

}

 

해당 클래스는 SpEL(Spring Expression Language) 을 사용하여 동적으로 락 키를 생성하는 메서드를 갖고 있다.

 

3-5. RedissonLockAspect

@Slf4j
@Aspect
@Component
@RequiredArgsConstructor
public class RedissonLockAspect {

    private final RedissonClient redissonClient;

    @Around("@annotation(com.ddonghyeo.example.global.annotation.RedissonLock)")
    public Object redissonLock(ProceedingJoinPoint joinPoint) throws Throwable {
        MethodSignature signature = (MethodSignature) joinPoint.getSignature();
        Method method = signature.getMethod();
        RedissonLock redissonLock = method.getAnnotation(RedissonLock.class);

        //락 키 생성
        String lockKey =
                method.getName() + ":" + RedisLockSpELParser.getLockKey(signature.getParameterNames(),
                        joinPoint.getArgs(), redissonLock.value());

        long waitTime = redissonLock.waitTime();
        long leaseTime = redissonLock.leaseTime();

        RLock lock = redissonClient.getLock(lockKey);
        boolean isLocked = false;

        try {
            isLocked = lock.tryLock(waitTime, leaseTime, MILLISECONDS);
            if (isLocked) {
                log.info("[Redisson Lock] 락 획득 성공 ---> {}", lockKey);
                return joinPoint.proceed(); //락 획득에 성공했다면 원래 로직 실행
            } else {
                log.error("[Redisson Lock] 락 획득 실패 ---> {}", lockKey);
                throw new CustomException(CommonErrorCode.FAILED_TO_ACQUIRE_LOCK);
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            log.error("[Redisson Lock] 락 획득 중 인터럽트 발생 ---> {}", lockKey);
            throw new CustomException(CommonErrorCode.FAILED_TO_ACQUIRE_LOCK);
        } finally {
            if (isLocked) {
                lock.unlock(); //락 해제
                log.info("[Redisson Lock] 락을 해제하는데 성공 ---> {}", lockKey);
            }
        }
    }
}

 

미리 만들어두었던 RedisLockSpELParser를 통해 락 키를 생성하고 획득을 시도한다.

 

Redisson의 RLock 메서드 tryLock은 락 획득 실패 시 false를 리턴하기 때문에 이를 이용하여 락 키 획득 성공 여부를 판단한다.

 

만약 키 획득에 성공한다면 joinPoint.proceed() 를 통해 원래 실행하려 했던 로직을 실행한다.

 

3-6. 사용

이렇게 구현된 락은 아래와 같이 사용할 수 있다.

@RedissonLock(value = "#productId", waitTime = 5000L, leaseTime = 3000L)
public OrderResult createOrder(Long productId, Long userId, int quantity) {
    Product product = productRepository.findById(productId)
        .orElseThrow(() -> new ProductNotFoundException("Product not found"));

    if (product.getStock() < quantity) {
        throw new InsufficientStockException("Not enough stock");
    }

    product.decreaseStock(quantity);
    productRepository.save(product);

    Order order = Order.builder()
        .userId(userId)
        .productId(productId)
        .quantity(quantity)
        .status(OrderStatus.CREATED)
        .build();

    orderRepository.save(order);

    return new OrderResult(order.getId(), "Order created successfully");
}

 

다음과 같이 사용자가 주문을 시도할 때와 같은 동시성 이슈가 있는 메서드에 @RedissonLock을 사용한다.

 

 

4. 주의할 점

• leaseTime을 너무 짧게 설정한다면, 작업이 완료되기 전까지 해제될 수 있으므로 충분히 길게 설정하는 것이 좋다.
  • 반대로 너무 길게 설정한다면 시스템 장애 시 락이 오랫동안 해제되지 않을 수 있다.
• AOP를 사용했기 때문에 추가적인 프록시 로직이 실행된다. 동시성이 높을수록 과부하가 일어날 수 있다. 어떤 상황이든지 서버 상황에 맞게 구현해야 한다.

 

 

참고
https://javadoc.io/doc/org.redisson/redisson/latest/index.html
https://github.com/redisson/redisson/wiki/Table-of-Content
https://hyperconnect.github.io/2019/11/15/redis-distributed-lock-1.html