[Redis] 이커머스 서비스 - Redisson을 이용한 분산 락 구현으로 동시성 이슈 해결

📖 목차

 

 

 

---

Spring Boot를 기반으로 이커머스 서비스를 구현하면서 동시성 이슈가 발생했다.

Redis의 Redisson라이브러리를 이용해 동시성 이슈를 해결하는 방법에 대해 알아보자.                                                        

 

 

 

 

 

 

📌  동시성 제어란? 

  동시성 제어(Concurrency Control)란, 여러 스레드나 프로세스가 데이터를 공유하는 작업이 동시에 실행될 때 그 실행 순서나 조건을 제어하여 데이터의 무결성을 유지하고 예상치 못한 동작을 방지하는 것을 말한다. 여러 작업 간의 상호작용, 자원 공유, 경쟁 조건 등을 관리하여 프로그램의 안정성과 성능을 보장하는 데 중요한 역할을 한다.

 

 

 

 

 

📌  동시성 제어의 목적 

• 여러 사용자가 DB에 접근하더라도 데이터의 일관성을 보장하고 데이터의 무결성을 유지
• 위를 만족하며 데이터베이스 시스템의 성능과 효율성을 유지하는 것

 

 

 

 

📌  동시성 제어 기법

  동시성 이슈를 해결하기 위해 다양한 방법을 생각해 볼 수 있다. 동시성 제어 기법에는 여러 가지가 있는데 그중, Locking기법을 적용해보려고 한다. Locking기법은 데이터에 잠금(Lock)을 설정하면 다른 트랜잭션은 해당 데이터에 잠금이 해제(UnLock)될 때까지 접근, 수정, 삭제가 불가능하게 해놓은 방법이다.

• synchronized
  • 현재 접근하고 있는 메소드에 하나의 스레드만 접근할 수 있도록 보장 및 동작한다. 자바에서 지원한다.
  • 스레드 하나씩 순차적으로 데이터에 접근할 수 있도록 해준다.
  • 애플리케이션을 하나만 띄우는 경우는 무관하지만, 서버가 여러 대일 경우에는 여러 개의 인스턴스가 존재하는 것과 동일하기 때문에 실질적인 운영 환경에서는 데이터의 정합성을 보장할 수 없다.

 

• Pessimistic Lock(비관적 락)
  • 데이터에 Lock을 걸어서 정합성을 맞추는 방법이다. 데이터를 변경하기 전에 락을 획득한다.
  • 한 번에여러 개의 테이블을 수정하려고 했을 때, 하나의 트랜잭션으로 묶여있기 때문에 수정 하나가 실패하면 데이터베이스단에서 전체 자동 롤백이 일어나게 된다.
  • 동시에 여러 사용자가 데이터에 접근할 때 성능 문제를 발생시킬 수 있다.
  • 특히 데이터 베이스나 분산 시스템에서 사용될 경우, 락이 발생할 때 다른 작업이 대기해야 하므로 처리량이 감소할 수 있다.

 

• Optimistic Lock(낙관적 락) 
  
  • 비관적 락과 다르게 트랜잭션을 잡지 않기 때문에 충돌 감지를 할 수 있다. 성능적으로는 비관적 락보다 좋다.
  • 충돌이 발생하여 수정을 못한 부분에 대해서는 롤백에 대한 책임을 애플리케이션 단에서 지며, 애플리케이션에서 수동으로 롤백을 해줘야 한다.
  • 충돌이 많이 예상되거나 충돌이 발생했을 때, 비용이 많이 들 것이라고 판단되는 곳에서는 사용하지 않는 것이 좋다.
  • 엔티티에 @Version을 추가해주어야 한다. 조회와 갱신 시 버전 비교를 통해서 정합성을 맞춘다.

 

• Named Lock
  • 말 그대로 이름을 가진 Lock이다. 데이터베이스의 별도의 저장소에 이름을 가진 락을 저장하고, 해당 이름에 대한 락을 해제되기 전 까지는 다른 트랜잭션에서 락을 획득할 수 없다.
  • 보통 분산락에서 사용하는 방법이며, MySQL에서만 사용이 가능하다.
  • 락을 사용하기 위해 별도의 커넥션 풀을 관리해야 하고, 락에 관련된 부하를 RDS에서 받는다는 단점이 있다.

 

• Lettuce
  • redis를 dependency에 추가하면 별도의 라이브러리 설치 없이 사용할 수 있다.
  • 스핀 락 방식으로 동시에 많은 스레드가 락 획득을 대기 중이라면, redis 서버에 부하를 발생시킬 수 있다.
  • redis에 값이 존재하지 않으면 세팅하게 하고, 값이 세팅되었는지 여부를 리턴 값으로 받아 락을 획득하는 데 성공한다. 락을 점유하는 시간이 짧으면 유리하지만 스레드가 락을 오래 점유하고 있는 경우 CPU에 부담을 줄 수 있다.
  • 락의 만료 시간을 지정할 수 없기 때문에 락 획득에 대한 재시도가 필요 없는 경우에 사용하면 좋다.

 

• Redisson
  • 별도의 라이브러리를 추가해야 사용할 수 있다.
  • Pub/Sub기능을 사용하여 스핀 락이 redis에 주는 엄청난 트래픽을 줄였다.
  • 락의 만료 시간을 지정할 수 있어, 락 획득을 재시도해야 하는 경우에 사용하면 좋다.

 

 

 

 

 

✔️ 위의 방법들 중, 나는 Redisson 라이브러리를 사용하여 동시성 제어를 구현했다.

  팀 프로젝트로 이커머스 서비스를 구현하게 되었는데, 이커머스의 특성상 여러 사용자가 동시에 한 가지 상품을 구매하기 위한 요청이 많을 것이고, 여러 사용자가 동시에 한 가지의 상품에 대해 주문을 생성을 요청하면 잘못된 트랜잭션이 생성될 수 있다고 판단하였다. 이러한 동시성 이슈를 해결하기 위해 방법을 찾아보던 중, 마침 인프라에 redis가 구축되어 있었고 redis의 여러 기능 중에  분산 락을 적용하게 되었다.

 

 

 

 

 

 

📌  동시성 제어 적용 전

• 테스트 시나리오: 초당 100번의 요청을 했을 때, 상품의 재고는 100개 -> 0개, 주문은 100개 생성되어야 한다.
• 테스트 결과: 3초 동안 총 300번의 요청을 한 결과, 상품의 재고는 100개-> 0개로 줄었고, 주문은 107개가 생성되었다.

<7번 상품의 재고를 100개로 설정한다.>

 

<재고는 0개가 되었지만, 주문은 107개가 생성되었다.>

 

 

 

• 테스트 시나리오: 초당 100번의 요청을 했을 때, 상품의 재고는 1000개 -> 900개, 주문은 100개 생성되어야 한다.
• 테스트 결과: 3초 동안 총 300번의 요청을 한 결과, 상품의 재고는 1000개-> 727개로 줄었고, 주문은 281개가 생성되었다.

<7번 상품의 재고를 1000개로 설정한다.>

 

<재고는 727개가 되었지만, 주문은 281개가 생성되었다.>

 

  여러 번의 요청을 보냈을 때, 동시성 이슈로 인해 줄어든 상품의 재고 수와 주문의 생성 개수가 맞지 않는다. 데이터의 정합성이 깨진 것이다. 이를 분산 락을 이용한 동시성 제어를 통해 해결해 보도록 하자.

 

 

 

 

 

 

📌  Redisson을 이용한 분산 락 구현하기 

 

  Spring에서 Redisson을 사용하려면 build.gradle에 다음과 같이 의존성을 추가해주어야 한다.

dependencies {
  // redisson
  implementation 'org.redisson:redisson-spring-boot-starter:3.23.2'
}

 

 

 

  RedissonClient를 사용하기 위해 Redis Config를 설정해 준다.

@Configuration
@EnableRedisRepositories
public class RedisConfig {

    @Value("${spring.data.redis.host}")
    private String redisHost;

    @Value("${spring.data.redis.port}")
    private int redisPort;

    private static final String REDISSON_HOST_PREFIX = "redis://";

    @Bean
    public RedissonClient redissonClient() {
        RedissonClient redisson = null;
        Config config = new Config();
        config.useSingleServer().setAddress(REDISSON_HOST_PREFIX + redisHost + ":" + redisPort);
        redisson = Redisson.create(config);

        return redisson;
    }

    @Bean
    public RedissonConnectionFactory redisConnectionFactory(RedissonClient redissonClient) {
        return new RedissonConnectionFactory(redissonClient);
    }
}

 

 

 

 

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

    String key(); // 락의 이름

    TimeUnit timeUnit() default TimeUnit.SECONDS; // 락의 시간 단위

    long waitTime() default 5L; // 락을 기다리는 시간

    long leaseTime() default 3L; // 락 임대 시간
}

 

 

 

  Redisson을 이용한 로직은 다음과 같다. 어노테이션 선언 시 수행되는 AOP클래스이다.

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

    private static final String REDISSON_LOCK_PREFIX = "LOCK: ";
    private static final long RETRY_DELAY = 3L; // 재시도 사이의 대기 시간
    private static final long MAX_RETRY_COUNT = 5L; // 최대 재시도 횟수

    private final RedissonClient redissonClient;
    private final AopForTransaction aopForTransaction;

    @Around("...")
    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 + CustomSpringELParser.getDynamicValue(
            signature.getParameterNames(),
            joinPoint.getArgs(),
            distributedLock.key());

        RLock rLock = redissonClient.getLock(key);

        // 락 획득 시도 및 재시도 로직
        int retryCount = 0;
      
        while (retryCount < MAX_RETRY_COUNT) {
            try { // 락을 획득하려고 시도하고, 정의된 시간이 지나면 잠금을 해제한다.
                boolean available = rLock.tryLock(distributedLock.waitTime(),
                    distributedLock.leaseTime(), distributedLock.timeUnit()); 

                if (available) {
                    System.out.println("Lock acquired with key: " + key);
                    try {
                        return aopForTransaction.proceed(joinPoint);
                    } finally {
                        if (rLock.isLocked() && rLock.isHeldByCurrentThread()) {
                        // isLocked(): 특정 락이 현재 Redis 서버에 락 되어 있는지 여부를 확인
                        // isHeldByCurrentThread(): 특정 락을 현재 스레드가 보유하고 있는지 여부를 확인
                            System.out.println("Lock released with key: " + key);
                            rLock.unlock();
                        }
                    }
                } ... {
                    // 락 획득 실패 시 대기하고 재시도하는 로직
                }
            } catch (InterruptedException e) {
                log.error("DistributedLock lock interrupted");
                System.out.println("DistributedLock lock interrupted");
                throw new InterruptedException(e.getMessage());
            }
        }
        throw new IllegalStateException("DistributedLock lock failed after retries");
    }
}

 

 

 

  동시성 환경에서의 데이터 정합성을 보장하기 위해 Propagation.REQUIRES_NEW 옵션을 지정했고, 트랜잭션 커밋 이후에 락이 해제되게 처리했다.

@Component
public class AopForTransaction {

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

 

 

 

  분산 락을 구현한 어노테이션을 적용하여 테스트를 진행해 보자.

@Service
@RequiredArgsConstructor
@Component
public class OrderService {
...

    @DistributedLock(key = "#orderProducts.![productId].toString()")
    public OrderInfo createOrder(
        Long memberId,
        Long receiverId,
        Long totalAmount,
        PayType type,
        List<OrderProduct> orderProducts
    ) {
	...
        OrderEntity saved = orderJpaRepository.save(orderEntity);

        historyService.createHistory(saved.getId(), orderProducts);

        return ...
    }

 

 

 

 

 

 

 

📌  동시성 제어 적용 후

• 테스트 시나리오: 초당 100번의 요청을 했을 때, 상품의 재고는 100개 -> 0개, 주문은 100개 생성되어야 한다.
• 테스트 결과: 3초 동안 총 300번의 요청을 한 결과, 상품의 재고는 100개-> 0개로 줄었고, 주문은 100개가 생성되었다.

<동일하게 7번 상품의 재고를 100개로 설정한다.>

 

<재고는 0개로 감소하였고, 그에 따라 주문은 100개가 정상적으로 생성되었다.>

 

 

 

• 테스트 시나리오: 초당 100번의 요청을 했을 때, 재고 1000개 -> 900개, 주문은 100개 생성되어야 한다.
• 테스트 결과: 3초 동안 총 300번의 요청을 한 결과, 재고는 1000개 -> 700개, 주문은 300개가 생성되었다.

<동일하게 7번 상품의 재고를 1000개로 맞춰준다.>

 

<재고는 700개로 감소하였고, 그에 따라 주문은 300개가 정상적으로 생성되었다.>

 

 

 

여기까지 동시성 이슈가 일어났을 때 Redisson을 사용한 분산 락의 구현에 대해 알아보았다.

 

 

 

 

 

📌  참고

풀필먼트 입고 서비스팀에서 분산락을 사용하는 방법 - Spring Redisson

 

 

레디스와 분산 락(1/2) - 레디스를 활용한 분산 락과 안전하고 빠른 락의 구현

 

[Redis] 분산 락 (feat. Redisson)

 

8. Distributed locks and synchronizers