Redisson Lock을 활용한 동시성 제어

[YurimYang]

안건

• 카카오페이를 활용해서 결제를 진행하는 과정에서, 사용자가 많이 결제를 시도할 때 생기는 문제를 방지하기 위해 Lock을 활용하고자 한다. (동시성제어)
• 동시성 제어를 위해 다양한 방안을 직접 개발해보면서 Optimistic Lock의 Deadlock 문제, Pessimistic Lock의 조회성능문제를 확인할 수 있었다.
• 마지막으로 Redisson Lock을 활용하여 최대한 효율적으로 동시성을 제어해보고자 한다.

진행방안

Redisson이란

• Lettuce와 다르게 Lock을 획득하지 못했을 때 재시도 횟수가 적어서 Redis에 부하가 적음
• Lock 관련 Class를 따로 제공 ⇒ Rlock 제공 ⇒ 별도로 class를 만들 필요가 없다.
• Pub-sub방식

  • 로직 실행 전후로 Lock 획득, 해제 해주는 Class가 필요

    ⇒ 채널을 하나 만들고, Lock을 점유 중인 스레드가 Lock을 해제했음을 대기중인 스레드에게 알려주면, 대기중인 스레드가 Lock 점유를 시도하는 방식
    

Redisson Lock 진행 방안

1. Redisson Lock Implementation (의존성 설정)

//Redis
implementation 'org.springframework.boot:spring-boot-starter-data-redis'
//redisson
implementation group: 'org.redisson', name: 'redisson-spring-boot-starter', version: '3.23.1'

---

2. Redisson Lock 을 활용한 Service Code 작성

    @Override
    @Transactional
    public PaymentSuccessResponse approvePaymentWithLock(String pgToken) {
        Long memberId = securityUtil.getCurrentMemberId();
        String key = REDIS_CACHE_KEY_PREFIX + memberId;
        PaymentRedisDto paymentInfo = getPaymentInfo(key);

        RLock lock = redissonClient.getLock(REDIS_LOCK_KEY_PREFIX + paymentInfo.productId());

        try {
            if (!lock.tryLock(500, 5_000, TimeUnit.MICROSECONDS)) {
                throw new RuntimeException();
            }
            Product targetProduct = productRepository.findById(paymentInfo.productId())
                .orElseThrow();
            checkOutOfStock(targetProduct);

            return approvePayment(pgToken, memberId);
        } catch (InterruptedException e) {
            throw new RuntimeException();
        } finally {
            if (lock != null && lock.isLocked()) {
                lock.unlock();
            }
        }
    }

• RLock lock = redissonClient.getLock();
  └ key이름에 해당하는 RLock 인스턴스를 가져온다 (Redisson에서 lock을 사용하기 위해 Rlock 인터페이스 제공)
• boolean lock.tryLock(long waitTime, long leaseTime, TimeUnit unit)
  • waitTime : 락을 획득하기 위한 대기 시간
  • leaseTime : 락을 임대하는 시간
  • unit : 시간 단위
  • 즉, leaseTime만큼 락을 가지고 있고, 락을 갖지 못한 스레드들은 waitTime만큼 기다리고 leaseTime이 지나면 자동으로 락이 해제된다.
  • approvePaymentWithLock() 메소드의 try문을 확인하면, lock을 갖고 있지 않으면 RuntimeException을 보내도록 하고 있다.
  • lock을 갖게 되면 product를 찾아서 stock을 -1한다.(checkOutOfStock)

---

3. 결과

• 이번에는 Jmeter를 사용해서 Thread를 여러개 보내는 test를 진행했다.
• Number of Thread : 실행할 Thread의 수 (즉, 몇명의 사용자가 동시에 호출을 하는지)
• Ramp-up Period(in seconds) : 전체 쓰레드가 전부 실행되는데까지 걸리는 시간
• Loop Count : 각 Thread가 몇번씩 실행을 할 것인가
  
• 즉, 100개의 스레드가 10초안에 수행되야하므로 1개의 스레드가 0.1초 안에 실행된다.
  
• 실제로 하나의 Thread만 성공하고, 나머지 Thread는 "상품 재고가 부족합니다"라는 error message가 뜨는 것을 확인할 수 있었다.

---

4. lettuce와 비교

• Min/Max : Thread가 기다리는 최소/최대 시간
  
• Lettuce는 최대 시간이 24865ms이다. 이는 스핀락의 영향으로 계속해서 lock 점유를 시도하기 때문이다.
• 특히, Lettuce는 만료시간을 제공하고 있지 않기 때문에 lock을 잡고 잇는 상태에서 만약 장애가 발생하면, 다른 서버들은 아예 lock을 점유할 수 없는 문제도 생길 수 있다.
  
• 그에 비해 Redisson은 최대 시간이 ms이다. lock을 획득하지 못했을 때 재시도 횟수가 lettuce에 비해 적어 Redis에 부하도 적다.

---

결론

• Optimistic Lock의 Deadlock 문제, Pessimistic Lock의 조회성능문제, Lettuce의 스핀락문제를 직접 경험해보면서, Redisson은 Redis의 부하도 적고 Thread 대기 시간도 줄기 때문에 Redisson을 사용해 동시성 제어를 완료했다.
• 완벽하게 100% 동시성을 처리하기에는 어려울 수 있으나, 여러가지 방안을 직접 사용해보면서 최적으로 동시성을 제어할 수 있는 방안을 확인해볼 수 있었다.
• 팀원 : @Kwonminwoo