자바에서 동시성을 해결하는 다양한 방법과 Redis의 분산락

이번 포스팅은 사전지식으로 운영체제의 동기화 이론에 대해 알고 있어야 손쉽게 이해할 수 있으므로, 헷갈리시는 분들은 아래 포스팅을 먼저 읽고 이번 포스팅을 읽어주시면 감사하겠습니다.

[OS] 프로세스 동기화(Process Synchronization)

공유자원에 대해 동시에 여러 개의 프로세스가 접근하여 생기는 경쟁 상황(race condition)을 우리는 동시성 문제라고도 하며, 더 자세히는 동일한 하나의 데이터에 두 개 이상의 스레드, 혹은 세션에서 가변 데이터를 동시에 제어할 때 나타는 문제로, 하나의 세션이 데이터를 수정 중일 때, 다른 세션에서 수정 전의 데이터를 조회해 로직을 처리함으로써 데이터의 정합성이 깨지는 문제를 말합니다

백엔드 즉 서버개발자에게 이러한 동시성 문제는 매우 중요한데, 위의 포스트 서문애도 나와있듯이 동시성 문제를 처리하지 않으면 아래와 같은 상황이 발생하기 때문입니다.

동시성 문제의 대표적인 예

1. 공유 자원인 전역 변수 예금 10만 원이 있다고 가정한다.
2. 프로세스 P1은 예금 10만 원을 확인한 상황에서 프로세스 P2가 예금 5만 원을 입금하여 총 15만 원의 예금을 저장한다.
3. 하지만 프로세스 P1입장에서는 아직 예금이 10만 원 이기에 10만 원을 추가하더라도 15 + 10 = 25라는 결과가 아닌 10 + 10 = 20이라는 총예금이 저장되게 된다.

그렇다면 이제 어떻게 이러한 동시성 문제를 해결할 수 있을지 한번 재고시스템이라는 간단한 로직을 작성하여 정리해 보겠습니다. 

테스트 환경은 다음과 같습니다.

• Apple Silicon (M1)
• Java 11, Spring, JPA, Lombok
• JUnit5
• MySQL, Redis

코드는 깃허브에서 확인 가능합니다.

목차는 다음과 같습니다.

1. 재고시스템 기초 로직
2. 동시성을 고려하지 않은 로직
3. Java Synchronized 키워드를 활용한 동기화 로직
4. DB에서 제어하는 방법
   1. Pessimistic Lock을 활용한 동기화 로직
   2. Optimistic Lock을 활용한 동기화 로직
   3. Named Lock을 활용한 동기화 로직
5. Redis를 활용하는 방법
   1. Redis Lettuce을 활용한 분산 락 구현
   2. Redis Redission을 활용한 분산 락 구현

 

1. 재고시스템 기초 로직

먼저 Entity, Service, Repository는 다음과 같은 순서로 간단하게 구성했습니다.

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Stock {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
    private Long productId;
    private Long quantity;

    public Stock(final Long id, final Long quantity) {
        this.id = id;
        this.quantity = quantity;
    }

    public void decrease(final Long quantity) {
        if (this.quantity - quantity < 0) {
            throw new RuntimeException("재고 부족");
        }
        this.quantity -= quantity;
    }
    
}

@Service
@RequiredArgsConstructor
public class StockService {

    private final StockRepository stockRepository;

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

public interface StockRepository extends JpaRepository<Stock, Long> {

}

 

2. 동시성을 고려하지 않은 로직

먼저 동시성을 고려하지 않은 로직 먼저 살펴보겠습니다. 

@SpringBootTest
class StockServiceTest {

    @Autowired
    private StockService stockService;

    @Autowired
    private StockRepository stockRepository;

    @BeforeEach
    public void before() {
        Stock stock = new Stock(1L, 100L);
        stockRepository.saveAndFlush(stock);
    }

    @AfterEach
    public void after() {
        stockRepository.deleteAll();
    }

    @Test
    @DisplayName("race condition 일어나는 테스트")
    public void 동시에_100개_요청() throws InterruptedException {
    
        int threadCount = 100;
        //멀티스레드 이용 ExecutorService : 비동기를 단순하게 처리할 수 있또록 해주는 java api
        ExecutorService executorService = Executors.newFixedThreadPool(32);
        //다른 스레드에서 수행이 완료될 때 까지 대기할 수 있도록 도와주는 API - 요청이 끝날때 까지 기다림
        CountDownLatch latch = new CountDownLatch(threadCount);

        for (int i = 0; i < threadCount; i++) {
            executorService.submit(() -> {
                try {
                    stockService.decrease(1L, 1L);
                } finally {
                    latch.countDown();
                }
            });
        }

        latch.await();
        Stock stock = stockRepository.findById(1L).orElseThrow();
        assertEquals(0L, stock.getQuantity());

    }
}

초기에 ProductId가 1인 재품의 수량을 100개로 세팅하여 DB에 세팅시켰고, ExecutorService를 통해 32개의 고정된 스레드풀을 생성하여 submit메서드를 통해 멀티스레드로 동작하여 재고를 감소시키는 로직을 수행했습니다.

ExecutorService와 CountDownLatch에 대해 생소하신 분들을 위해 간략하게 정리하면 다음과 같습니다.

ExecutorService

• ExecutorService란, 병렬 작업 시 여러 개의 작업을 효율적으로 처리하기 위해 제공되는 JAVA API이다.
• ExecutorService는 손쉽게 ThreadPool을 구성하고 Task를 실행하고 관리할 수 있는 역할을 한다.
• Executors를 사용하여 ExecutorService 객체를 생성하며, 스레드 풀의 개수 및 종류를 지정할 수 있는 메서드를 제공한다.

CountDownLatch

• CountDownLatch란, 어떤 스레드가 다른 스레드에서 작업이 완료될 때 가지 기다릴 수 있도록 해주는 클래스이다.
• CountDownLatch를 이용하여, 멀티스레드가 남은 횟수의 작업을 모두 완료한 후, 테스트를 하도록 기다리게 합니다.
• CountDownLatch 작동원리
  1. new CountDownLatch(10); 의 형식으로 Latch 할 개수를 지정한다.
  2. countDown()을 호출하면 Latch의 카운터가 1개씩 감소한다.
  3. await()은 Latch의 카운터가 0이 될 때까지 기다린다.

위 로직의 수행 결과는 다음과 같이 실패로 나옵니다.

테스트 로직 수행 결과

100개의 재고를 1개씩 100번 감소시켰던 만큼 수행결과 0이라는 재고의 수량을 기대했으나 96이라는 터무니없는 수량이 남아있습니다. 이유는 서두에 명시했던 은행 입출금 예시인 race condition(경쟁상황)이 일어났기 때문인데, 두 개 이상의 스레드가 공유 자원에 대해서 동시에 변경하려고 했기 때문에 입니다.

race condition을 해결하기 위해서는 근본적으로 공유자원에 대해 하나의 스레드가 작업을 완료한 후에 다른 스레드가 접근할 수 있도록 설정해야 합니다.

 

3. Synchronized 키워드를 활용한 동기화 로직

먼저 Synchronized키워드를 이용하여 동시성 문제를 해결하는 방법입니다.

@Service
@RequiredArgsConstructor
public class StockService {

    private final StockRepository stockRepository;
    
    /**
     * synchronized 사용시 @Transactional과 동시에 사용하면 안된다.
     * Synchronized를 사용하는 이유는 해당 메소드를 한 쓰레드에서만 돌리기 위해서다.
     * 하지만, 트랜잭션이 같이 정의가 되어있다면 첫 번째 쓰레드가 끝나기 전 두 번째 쓰레드가 발동할 수도 있다.
     */
    public synchronized void decrease(Long id, Long quantity) {
        Stock stock = stockRepository.findById(id).orElseThrow();
        stock.decrease(quantity);
        stockRepository.saveAndFlush(stock);
    }
    
}

    @Test
    @DisplayName("synchronized 사용")
    public void 동시에_100개_요청() throws InterruptedException {
        int threadCount = 100;
        ExecutorService executorService = Executors.newFixedThreadPool(32);
        CountDownLatch latch = new CountDownLatch(threadCount);

        for (int i = 0; i < threadCount; i++) {
            executorService.submit(() -> {
                try {
                    stockService.decrease(1L, 1L);
                } finally {
                    latch.countDown();
                }
            });
        }

        latch.await();
        Stock stock = stockRepository.findById(1L).orElseThrow();
        assertEquals(0L, stock.getQuantity());
    }

테스트 로직 수행 결과

위와 같이 간단하게 Service로직에서 메서드에 synchronized 키워드를 추가하고, @Transactional을 제거함으로써 해결할 수 있습니다.

• synchronized를 이용하면 현재 접근하고 있는 메서드에 하나의 스레드만 접근할 수 있도록 작동합니다.
• 자바에서 지원하는 synchronized는,  현재 데이터를 사용하고 있는 해당 스레드를 제외하고 나머지 스레드들은 데이터 접근을 막아 순차적으로 데이터에 접근할 수 있도록 해줍니다.

synchronized를 사용할 때 @Transactional을 제거해주어야만 하는 이유는 @Transactional을 통한 선언적 트랜잭션 관리 방식은 기본적으로 프록시 방식은 AOP가 적용되기 때문입니다. 

TransactionStatus status = transactionManager.getTransaction(..);

try {
	target.logic(); // public synchronized void decrease 메서드 수행
    // logic 수행 이후 트랜잭션 종료 전에 다른 쓰레드가 decrease에 접근!
    transactionManager.commit(status);
} catch (Exception e) {
	transactionManager.rollback(status);
    throw new IllegalStateException(e); 
}

위 코드는 트랙잭션 프록시의 간단한 예제 코드입니다. 트랜잭션 프록시가 트랜잭션 처리 로직을 수행할 때 위 클래스를 새로 만들어 locic을 수행하게 됩니다. synchronized를 통해 서비스 로직의 decrease() 메서드를 한 스레드만 접근할 수 있도록 막더라도 Transactional에 의해 새로운 프록시로 수행되게 되어버리면 프록시 로직은 synchronized가 걸린 상태가 아니기 때문에 우리가 원하는 결과를 얻지 못하게 됩니다.

JAVA Sychronized의 문제점

synchronized의 사용은 간단하지만 다음과 같은 문제점을 가지고 있습니다.

• 자바의 Sychronized는 하나의 프로세스 안에서만 보장이 됩니다.
• 즉, 서버가 1대일 때는 문제가 없지만 서버가 여러 대 일경우 여러 개의 인스턴스가 존재하는 것과 동일하기 때문에 실질적인 운영 환경에서는 데이터의 정합성을 보장할 수 없습니다.

 

4. DB에서 제어하는 방법

이번 방법은 DateBase Lock을 이용하여 순차적인 접근으로 제어하는 방법입니다. 크게 다음과 같은 방법이 있으며, 조금 더 상세하고 DB단에서 직접 해결하는 방법은 다음 링크를 참고하면 좋을 것 같습니다. 링크: MySQL에서의 Lock

1. Pessimistic Lock(비관적 락)
2. Optimistic Lock(낙관적 락)
3. Named Lock(네임드 락)

1. Pessimistic Lock

• Pessimistic Lock이란 실제로 데이터에 Lock을 걸어서 정합성을 맞추는 방법입니다.
• Exclusive Lock(배타적 잠금)을 걸게 되면 다른 트랜잭션에서는 Lock 이 해제되기 전에 데이터를 가져갈 수 없게 됩니다.
• 자원 요청에 따른 동시성문제가 발생할 것이라고 예상하고 락을 걸어버리는 비관적 락 방식입니다.
• 하지만, Dead Lock(교착상태)에 빠질 위험성이 있으므로 유의해야 합니다.

Dead Lock(교착상태)는 이전 OS 정리 때 포스팅 한 적 있으니 참고하시면 감사하겠습니다.

[OS] 교착 상태(Deadlocks)

비관적 락(pessimistic lock) 도식도 1

위의 도식도의 수행 과정은 다음과 같습니다.

1. Transaction_1에서 table의 Id 2번을 읽음 ( name = Karol )
2. Transaction_2에서 table의 Id 2번을 읽음 ( name = Karol )
3. Transaction_2에서 table의 Id 2번의 name을 Karol2로 변경 요청 ( name = Karol )
4. 하지만 Transaction 1에서 이미 shared Lock을 잡고 있기 때문에 Blocking
5. Transaction_1에서 트랜잭션 해제 (commit)
6. Blocking 되어있었던 Transaction_2의 update 요청 정상 처리

비관적 락(pessimistic lock) 도식도 2

코드

public interface StockRepository extends JpaRepository<Stock, Long> {

    @Lock(value = LockModeType.PESSIMISTIC_WRITE)
    Optional<Stock> findById(Long id);
    
}

@Service
@RequiredArgsConstructor
public class StockService {

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

    @Test
    @DisplayName("Pessimistic Lock(비관적 락) 사용")
    public void 동시에_100개_요청() throws InterruptedException {
        int threadCount = 100;
        ExecutorService executorService = Executors.newFixedThreadPool(32);
        CountDownLatch latch = new CountDownLatch(threadCount);

        for (int i = 0; i < threadCount; i++) {
            executorService.submit(() -> {
                try {
                    stockService.decrease(1L, 1L);
                } finally {
                    latch.countDown();
                }
            });
        }

        latch.await();
        Stock stock = stockRepository.findById(1L).orElseThrow();
        assertEquals(0L, stock.getQuantity());

    }

테스트 로직 수행 결과

위와 같이 Repository에서 DB 조회 시에 @Lock(value = LockModeType.PESSIMISTIC_WRITE)을 적용하여 트랜잭션이 시작할 때 Shared/Exclusive Lock을 적용하게 하여 사용할 수 있습니다.

결국 Pesimistic Lock이란, 데이터에는 Lock을 가진 스레드만 접근이 가능하도록 제어하는 방법입니다.

장점

• Pessimistic Lock은 동시성 충돌이 잦을 것으로 예상되어 동시성을 강력하게 지켜야 할 때 사용합니다.
• 충돌이 빈번하게 일어난다면 롤백의 횟수를 줄일 수 있기 때문에, Optimistic Lock보다는 성능이 좋을 수 있고, 가장 강력한 데이터 정합성 보장 방법입니다.

단점

• 데이터 자체에 Lock을 걸기 때문에 속도가 상대적으로 느린 편입니다.
• 서로 자원이 필요한 경우, 락이 걸려있으므로 Dead Lock(교착상태)에 빠질 가능성이 있습니다.

 

2. Optimistic Lock

• Optimistic Lock은 실제 Lock을 사용하지 않고, 데이터의 Version을 이용하여 데이터의 정합성을 준수하는 방법입니다.
• 먼저 데이터를 조회한 후에 update를 수행할 때 현재 내가 조회한 버전이 맞는지 확인하며 업데이트합니다.
• 자원에 Lock을 걸어서 선점하지 않고, 동시성 문제가 발생하면 그때 가서 처리하는 낙관적 락 방식입니다.
• 내가 조회한 버전에서 수정사항이 생겼을 경우에는 application에서 다시 조회 후에 작업을 수행하는 롤백 작업을 수행해야 합니다.

낙관적 락(Optimistic lock) 도식도 1

위의 도식도의 수행 과정은 다음과 같습니다.

1. A가 table의 Id 2번을 읽음 ( name = Karol, version = 1 )
2. B가 table의 Id 2번을 읽음 ( name = Karol, version = 1 )
3. B가 table의 Id 2번, version 1인 row의 값 갱신 ( name = Karol2, version = 2 ) 성공
4. A가 table의 Id 2번, version 1인 row의 값 갱신 ( name = Karol1, version = 2 ) 실패
5. Id 2번은 이미 version이 2로 업데이트되었기 때문에 A는 해당 row를 갱신하지 못함
6. 쿼리가 실패하면 다시 조회하여 버전을 맞춘 후 업데이트 쿼리를 날리는 과정을 반복

낙관적 락(Optimistic lock) 도식도 2

위 flow를 통해서 같은 row에 대해서 각기 다른 2개의 수정 요청이 있었지만 1개가 업데이트됨에 따라 version이 변경되었기 때문에 뒤의 수정 요청은 반영되지 않게 되었습니다. 이렇게 낙관적락은 version과 같은 별도의 컬럼을 추가하여 충돌적인 업데이트를 막습니다. version 뿐만 아니라 hashcode 또는 timestamp를 이용하기도 합니다.

코드

Pessimistic Lock과 마찬가지로 DB 조회 시에 @Lock(value = LockModeType.OPTIMISTIC)을 명시하여 적용할 수 있습니다.

public interface StockRepository extends JpaRepository<Stock, Long> {

    @Lock(value = LockModeType.OPTIMISTIC)
    Optional<Stock> findById(Long id);
    
}

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Stock {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
    private Long productId;
    private Long quantity;
	
    // 버전 컬럼 추가!!
    @Version
    private Long version;
    
    public Stock(final Long id, final Long quantity) {
        this.id = id;
        this.quantity = quantity;
    }

    public void decrease(final Long quantity) {
        if (this.quantity - quantity < 0) {
            throw new RuntimeException("재고 부족");
        }
        this.quantity -= quantity;
    }
    
}

Entity에는 @Version을 통해 version 컬럼을 추가했습니다.

@Service
@RequiredArgsConstructor
public class StockService {

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

Service로직의 경우에는 기존의 로직과 차이가 없고, 지속적으로 DB 변경을 재시도하는 로직을 구현해야 했기 때문에 별도의 Helper 유틸리티와 같은 Facade를 아래와 같이 만들었습니다. 

@Component
@RequiredArgsConstructor
public class OptimisticLockStockFacade {

    private final StockService stockService;
	
 	/**
 	* Lock을 잡지 않으므로, Pessimistic Lock(비관적 락)보다 성능상 이점이 있을 수 있다.
 	* 하지만, 업데이트가 실패했을 경우 재시도 로직이 개발자가 직접 작성을 해주어야 한다.
 	* 또한 충돌이 빈번하게 일어난다면, Pessimistic Lock이 성능상 이점이 더 있을 수 있다.
 	*/
    public void decrease(Long id, Long quantity) throws InterruptedException {
        while (true) {
            try {
                stockService.decrease(id, quantity);
                break;
            } catch (Exception e) {
                Thread.sleep(1);
            }
        }
    }
}

Optimistic Lock에서 Version을 확인하는데, 만약 DB 변경 트랜잭션을 만들고자 하는 현재 스레드가 이전 Version을 가지고 있다면 트랜잭션을 보내지 못하고 1ms동안 기다리도록 설정했습니다.

    @Test
    @DisplayName("Optimistic Lock(낙관적 락) 사용")
    public void 동시에_100개_요청() throws InterruptedException {
        int threadCount = 100;
        ExecutorService executorService = Executors.newFixedThreadPool(32);
        CountDownLatch latch = new CountDownLatch(threadCount);

        for (int i = 0; i < threadCount; i++) {
            executorService.submit(() -> {
                try {
                    optimisticLockStockFacade.decrease(1L, 1L);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } finally {
                    latch.countDown();
                }
            });
        }

        latch.await();
        Stock stock = stockRepository.findById(1L).orElseThrow();
        assertEquals(0L, stock.getQuantity());
    }

테스트 로직 수행 결과

장점

• 충돌이 자주 일어나지 않는다는 가정 하에, 별도의 Lock을 걸지 않으므로 Pessimistic Lock보다는 성능적 이점을 가질 수 있습니다.

단점

• 업데이트가 실패했을 시, 재시도 로직을 개발자가 직접 작성해 주어야 합니다.
• 충돌이 빈번하게 일어난다면, Roll Back 처리를 해주어야 하기 때문에, Pessimistic Lock이 더 성능이 좋을 수 있습니다.

 

3. Named Lock

• Named Lock은 이름을 가진 Metadata Lock입니다.
• 이름을 가진 Lock을 획득한 후, 해지될 때까지 다른 세션은 이 Lock을 획득할 수 없게 됩니다.
• 주의할 점은, 트랜잭션이 종료될 때 Lock이 자동으로 해지되지 않기 때문에, 별도로 해지해주거나 선점시간이 끝나야 해지됩니다.
• Mysql에서는 getLock( )을 통해 획들 / releaseLock()으로 해지할 수 있습니다.

Named Lock 도식도

위의 도식도의 수행 과정은 다음과 같습니다.

1. Named Lock은 Stock에 락을 걸지 않고, 별도의 공간에 Lock을 건다.
2. session-1 이 1이라는 이름으로 Lock을 건다면, session 1 이 1을 해지한 후에 Lock을 얻을 수 있다.

주의할 점은 Named Lock을 활용할 때 데이터소스를 분리하지 않고, 하나로 사용하게 되면 connection pool이 부족해지는 현상이 발생해 Lock을 사용하지 않는 다른 서비스까지 영향을 끼칠 수 있다는 문제가 있습니다.

Named Lock을 활용하면 분산 락을 구현할 수 있고, Pessmistic  Lock의 경우 타임아웃을 구현하기 까다롭지만, Named Lock은 손쉽게 구현할 수 있습니다. 하지만 트랜잭션 종료 시에 Lock 해제와 데이터 소스 분리 시 세션 관리를 수동으로 진행되어야 한다는 불편한 점이 있습니다.

코드

public interface LockRepository extends JpaRepository<Stock, Long> {

    @Query(value = "select get_lock(:key, 3000)", nativeQuery = true)
    void getLock(String key);

    @Query(value = "select release_lock(:key)", nativeQuery = true)
    void releaseLock(String key);
    
}

@Component
@RequiredArgsConstructor
public class NamedLockFacade {

    private final LockRepository lockRepository;
    private final StockService stockService;
	
    /**
    * Named Lock은 주로 분산 락을 구현할 때 사용한다.
    * Pessimistic Lock은 타임아웃을 구현하기 굉장히 까다롭지만, Named Lock은 손쉽게 구현할 수 있다.
    * 이외에도 데이터 삽입시에 정합성을 맞춰야 하는 경우에도 사용할 수 있다.
    * 하지만 이 방법은 트랜잭션 종료시에 락 해제와 세션 관리를 직접 잘 해줘야하므로 주의해서 사용해야하고, 사용할 때는 구현방법이 복잡할 수 있다.
    */
    @Transactional
    public void decrease(Long id, Long quantity) {
        try {
            lockRepository.getLock(id.toString());
            stockService.decrease(id, quantity);
        }finally {
            // Lock 해제
            lockRepository.releaseLock(id.toString());
        }
    }
}

@Service
@RequiredArgsConstructor
public class StockService {

    private final StockRepository stockRepository;
    
    // 부모의 트랜잭션과 별도로 실행되어야 함
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void decrease(Long id, Long quantity) {
        Stock stock = stockRepository.findById(id).orElseThrow();
        stock.decrease(quantity);
        stockRepository.saveAndFlush(stock);
    }
    
}

여기서 중요 로직의 설명은 다음과 같습니다.

• StockService는 부모의 트랜잭션과 별도로 실행되어야 하기 때문에 propergation을 별도로 생성해 줍니다
• 부모의 트랜잭션과 동일한 범위로 묶인다면 Synchronized와 같은 문제인 DataBase에 Commit 되기 전에 Lock이 풀리는 현상이 발생합니다.
• 그렇기 때문에 별도의 트랜잭션으로 분리해서 DataBase에 정상적으로 Commit이 된 후에 락을 해제해 주도록 합니다.
• 핵심은 Lock을 해제하기 전에 DataBase에 Commit이 되도록 하는 것입니다.

그리고 Connection Pool의 수를 늘려줍니다.

spring:
  jpa:
    hibernate:
      ddl-auto: create
    show-sql: true
  datasource:
    driver-class-name: org.h2.Driver
    url:  jdbc:h2:tcp://localhost/~/test
    username: sa
    password:
    hikari:
      maximum-pool-size: 40 	// here

    @Test
    @DisplayName("Named Lock 사용")
    public void 동시에_100개_요청() throws InterruptedException {
        int threadCount = 100;
        ExecutorService executorService = Executors.newFixedThreadPool(32);
        CountDownLatch latch = new CountDownLatch(threadCount);

        for (int i = 0; i < threadCount; i++) {
            executorService.submit(() -> {
                try {
                    namedLockStockFacade.decrease(1L, 1L);
                } finally {
                    latch.countDown();
                }
            });
        }

        latch.await();
        Stock stock = stockRepository.findById(1L).orElseThrow();
        assertEquals(0L, stock.getQuantity());
    }

테스트 로직 수행 결과

장점

• Named Lock 은 주로 분산락을 구현할 때 사용합니다.
• Pessimistic 락은 timeout을 구현하기 굉장히 힘들지만, Named Lock은 비교적 손쉽게 구현할 수 있습니다.

단점

• Named Lock 은 트랜잭션 종료 시에, Lock 해제와 세션관리를 잘해주어야 하므로 주의해서 사용해야 합니다.
• 실제 업무 환경에서는 구현방법이 복잡할 수 있습니다.

 

5. Redis를 활용하는 방법

Redis란 key-value 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비 관계형 인메모리 DBMS입니다. Redis의 다양한 특징 중에서도 Single Threaded 한 특징 즉, 한 번에 하나의 명령만 처리할 수 있는 특징 때문에 동시성 문제를 해결하는데 많이 사용됩니다.

Java의 Redis Client는 아래와 같이 크게 세 가지가 있습니다.

• Jedis
• Lettuce
• Redisson

이 중에서 Jedis는 성능이 많이 좋지 않기 때문에 Lettuce와 Redisson을 비교해서 정리하겠습니다. Jedis와의 성능 비교는 조졸두님의 블로그에 자세히 설명되어 있습니다. 링크: https://jojoldu.tistory.com/418

1. Lettuce

• Setnx 명령어를 활용하여 분산락을 구현 (Set if not Exist - key:value를 Set 할 떄. 기존의 값이 없을 때만 Set 하는 명령어)
• Setnx는 Spin Lock방식이므로 retry 로직을 개발자가 작성해 주어야 합니다.
• Spin Lock 이란, Lock을 획득하려는 스레드가 Lock을 획득할 수 있는지 확인하면서 반복적으로 시도하는 방법입니다.

락을 획득한다는 것은 “락이 존재하는지 확인한다”, “존재하지 않는다면 락을 획득한다” 두 연산이 atomic 하게 이루어져야 합니다. Redis에 기반한 Lettuce 방식은 “값이 존재하지 않으면 세팅한다”라는 setnx(set when not exists) 명령어를 지원합니다. 이 setnx를 이용하여 레디스에 값이 존재하지 않으면 세팅하게 하고, 값이 세팅되었는지 여부를 리턴 값으로 받아 락을 획득하는 데에 성공했는지 확인합니다.

Spin Lock 과정

Named Lock과 달리 Redis를 사용하면 트랜잭션에 따라 대응되는 현재 트랜잭션 풀 세션 관리를 하지 않아도 되므로 구현이 편리합니다. 앞서 말했듯 Spin Lock 방식이므로 Sleep Time이 적을수록 Redis에 부하를 줄 수 있어서 thread busy waiting의 요청 간의 시간을 적절히 주어야 합니다.

코드

dependencies {
    //redis 의존성 추가
    implementation 'org.springframework.boot:spring-boot-starter-data-redis'
}

@Component
@RequiredArgsConstructor
public class RedisLockRepository {

    private final RedisTemplate<String, String> redisTemplate;

    public Boolean lock(final Long key) {
        return redisTemplate
            .opsForValue()
            .setIfAbsent(generateKey(key), "lock", Duration.ofMillis(3_000));
    }

    public Boolean unlock(final Long key) {
        return redisTemplate.delete(generateKey(key));
    }

    private String generateKey(final Long key) {
        return key.toString();
    }
    
}

@Component
@RequiredArgsConstructor
public class LettuceLockStockFacade  {

    private final RedisLockRepository redisLockRepository;
    private final StockService stockService;
	
   /**
   * 구현이 간단하다.
   * Spring Data Redis를 이용하면 Lettuce가 기본이기 때문에 별도의 라이브러리를 사용하지 않아도 된다.
   * Spin Lock 방식이기 때문에 동시에 많은 스레드가 Lock 획득 대기 상태라면 Redis에 부하가 갈 수 있다.
   * 실무에서는 재시도가 필요한 Lock의 경우에는 Redission을 활용하고, 그렇지 않을 경우에는 Lettuce을 활용한다.
   * 재시도가 필요한 경우?: 선착순 100명 까지 물품을 구매할 수 있을 경우
   * 재시도가 필요하지 않은 경우?: 선착순 한명만 가능, Lock 획득 재시도 할 필요가 없음
   */
    public void decrease(final Long key, final Long quantity) throws InterruptedException {
        while (!redisLockRepository.lock(key)) {
            Thread.sleep(50);
        }

        //lock 획득 성공시
        try{
            stockService.decrease(key,quantity);
        }finally {
         //락 해제
            redisLockRepository.unlock(key);
        }
    }
    
}

Spin Lock방식으로 Lock 얻기를 시도하고, Lock을 얻은 후, 재고 감소 비즈니스 로직을 처리합니다. 그 후 Lock을 해제하는 방법으로 구현합니다.

    @Test
    @DisplayName("Lettuce Lock 사용")
    public void 동시에_100개_요청() throws InterruptedException {
        int threadCount = 100;
        ExecutorService executorService = Executors.newFixedThreadPool(32);
        CountDownLatch latch = new CountDownLatch(threadCount);

        for (int i = 0; i < threadCount; i++) {
            executorService.submit(() -> {
                try {
                    lettuceLockStockFacade.decrease(1L, 1L);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                } finally {
                    latch.countDown();
                }
            });
        }

        latch.await();
        Stock stock = stockRepository.findById(1L).orElseThrow();
        assertEquals(0L, stock.getQuantity());

    }

테스트 로직 수행 결과

Spin Lock 방식에는 다음과 같은 여러 가지 문제점이 있습니다.(https://hyperconnect.github.io/2019/11/15/redis-distributed-lock-1.html)

1. Lock의 타임아웃이 지정되어 있지 않습니다.

위의 코드와 같이 스핀 락을 구현했을시에 락을 획득하지 못하면 무한 루프를 돌게 됩니다. 만약 특정한 애플리케이션에서 tryLock을 성공했는데 불운하게도 어떤 오류 때문에 애플리케이션이 종료되어버리면 어떻게 될까요? 다른 모든 애플리케이션까지 영원히 락을 획득하지 못한 채 락이 해제되기만을 기다리는 무한정 대기상태가 되어 전체 서비스의 장애가 발생하게 될 것입니다.

그래서 일반적인 로컬 스핀 락과는 다르게 일정 시간이 지나면 락이 만료되도록 구현해야 합니다. 그러려면 expire time을 설정해주어야 합니다. 하지만 위의 코드에서는 “락을 사용 중인지 확인”, “락을 획득” 연산을 하나로 묶기 위해 setnx 명령어를 사용했습니다. 이 명령어는 expire time을 지정할 수 없기에 이 문제를 해결하기가 힘듭니다.

또한 무한정으로 락의 획득을 시도한다면 문제가 될 수 있습니다. 만약 연산이 오래 걸릴 경우 대부분의 스레드가 락을 대기하는 상태가 되어 클라이언트에 응답하는 속도가 늦어지고, 동시에 레디스에 엄청난 트래픽을 보낼 수 있기 때문입니다. 그래서 락을 획득하는 최대 허용시간을 정해주거나, 최대 허용 횟수를 정해주는 것이 좋습니다. 만약 락을 획득하는 데에 실패한다면 연산을 수행할 수 없는 상태이기에 Exception을 던집니다.

2. Redis에 많은 부하를 가하게 됩니다.

위의 코드는 스핀 락을 사용했지만 사실 스핀 락을 사용하면 레디스에 엄청난 부담을 주게 됩니다. 스핀 락은 지속적으로 락의 획득을 시도하는 작업이기 때문에 레디스에 계속 요청을 보내게 되고 레디스는 이런 트래픽을 처리하느라 부담을 받게 됩니다.

스핀 락을 사용하면서 레디스에 부담을 덜 주기 위해 50ms만큼 sleep 하면서 tryLock을 수행하도록 했지만, 이 또한 50ms마다 계속 레디스에 요청을 보내는 것이므로 작업이 오래 걸릴수록, 요청 수가 많을수록 더 큰 부하를 가하게 됩니다.

만약 300ms가 걸리는 동기화된 작업에 동시에 100개의 요청이 왔다고 가정해 보겠습니다. (분산 락이므로 서버의 대수는 무관합니다.)

처음으로 락을 획득하는 데 성공한 1개의 요청을 제외하고, 나머지 99개의 요청은 작업이 완료되는 300ms 동안 무려 레디스에 594회의 락 획득 요청을 하게 됩니다. 즉 1초 동안 약 2000회라는 많은 요청을 레디스에 보내게 됩니다.

또한 일회성이 아니라 모든 작업이 완료될 때까지 지속적으로 레디스에 부하를 가하기 때문에 요청이 지속적으로 들어오는 환경이라면 이러한 비효율성은 더욱 커집니다.

만약 레디스에 부담을 덜 주기 위해 sleep 시간을 300ms로 늘린다면 어떨까요? 50ms가 걸리는 작업에 이 동기화를 적용하면 락을 획득하지 못할 경우 50ms 걸리는 작업을 하기 위해 300ms를 대기해야 하는 다른 비효율적인 상황이 생기게 됩니다.

 

2. Redisson

• Pub-sub 기반으로 Lock 구현 제공
• Pub-Sub 방식이란, 채널을 하나 만들고, 락을 점유 중인 스레드가, Lock을 해제했음을, 대기 중인 스레드에게 알려주면 대기 중인 스레드가 Lock 점유를 시도하는 방식입니다.
• 이 방식은, Lettuce와 다르게 대부분 별도의 Retry 방식을 작성하지 않아도 됩니다.

Redisson 점유 과정

코드

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-redis'
    // redisson 의존성 추가
    implementation group: 'org.redisson', name: 'redisson-spring-boot-starter', version: '3.19.0'
}

@Component
@RequiredArgsConstructor
public class RedissonLockStockFacade {

    private final RedissonClient redissonClient;
    private final StockService stockService;
	
   /**
   * Lock 획득 재시도를 기본으로 제공한다.
   * pub-sub 방식으로 구현이 되어있기 때문에 Lettuce와 비교했을 때 Redis에 부하가 덜 간다.
   * 별도의 라이브러리를 사용해야 한다.
   * Lock을 라이브러리 차원에서 제공해주기 때문에 사용법을 공부해야 한다.
   * 실무에서는 재시도가 필요한 Lock의 경우에는 Redission을 활용하고, 그렇지 않을 경우에는 Lettuce을 활용한다.
   * 재시도가 필요한 경우?: 선착순 100명 까지 물품을 구매할 수 있을 경우
   * 재시도가 필요하지 않은 경우?: 선착순 한명만 가능, Lock 획득 재시도 할 필요가 없음
   */
    public void decrease(final Long key, final Long quantity) {
    
        RLock lock = redissonClient.getLock(key.toString());

        try {
            // 획득시도 시간, 락 점유 시간
            boolean available = lock.tryLock(5, 1, TimeUnit.SECONDS);

            if (!available) {
                System.out.println("lock 획득 실패");
                return;
            }

            stockService.decrease(key, quantity);
            
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }finally {
            lock.unlock();
        }
    }
    
}

Redisson은 Lettuce와 달리 별도의 인터페이스이기 때문에 gradle 의존 패키지 설치 및 별도의 Facade 작성이 필요합니다.

    @Test
    @DisplayName("Redisson Lock 사용")
    public void 동시에_100개_요청() throws InterruptedException {
        int threadCount = 100;
        ExecutorService executorService = Executors.newFixedThreadPool(32);
        CountDownLatch latch = new CountDownLatch(threadCount);

        for (int i = 0; i < threadCount; i++) {
            executorService.submit(() -> {
                try {
                    redissonLockStockFacade.decrease(1L, 1L);
                } finally {
                    latch.countDown();
                }
            });
        }

        latch.await();
        Stock stock = stockRepository.findById(1L).orElseThrow();
        assertEquals(0L, stock.getQuantity());

    }

테스트 로직 수행 결과

이제는 오픈소스 레디스 클라이언트인 Redisson이 분산 락을 어떻게 설계했는지 소개하며 어떻게 이 문제점들을 해결했고, 보다 빠른 성능을 내게 되었는지 설명하겠습니다.

Redisson은 Lettuce와 비슷하게 Netty를 사용하여 non-blocking I/O를 사용합니다. Redisson의 특이한 점은 직접 레디스의 명령어를 제공하지 않고, Bucket이나 Map같은 자료구조나 Lock 같은 특정한 구현체의 형태로 제공한다는 것입니다.

1. Lock에 타임아웃이 구현되어 있습니다.

Redisson은 tryLock 메소드에 타임아웃을 명시하도록 되어있습니다. 첫 번째 파라미터는 락 획득을 대기할 타임아웃이고, 두 번째 파라미터는 락이 만료되는 시간입니다.

첫 번째 파라미터만큼의 시간이 지나면 false가 반환되며 락 획득에 실패했다고 알려줍니다. 그리고 두 번째 파라미터만큼의 시간이 지나면 락이 만료되어 사라지기 때문에 애플리케이션에서 락을 해제해주지 않더라도 다른 스레드 혹은 어플리케이션에서 락을 획득할 수 있습니다.

이로 인해 락이 해제되지 않는 문제로 무한 루프에 빠질 위험이 사라집니다.

// RedissonLock의 tryLock 메소드 시그니쳐
public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException

2. 스핀 락을 사용하지 않습니다.

Redisson은 기본적으로 스핀 락을 사용하지 않기 때문에 레디스에 부담을 주지 않습니다. 그럼 어떻게 락의 획득 가능여부를 판단할까요?

Redisson은 pubsub 기능을 사용하여 스핀 락이 레디스에 주는 엄청난 트래픽을 줄였습니다. 락이 해제될 때마다 subscribe 하는 클라이언트들에게 “너네는 이제 락 획득을 시도해도 된다”라는 알림을 주어서 일일이 레디스에 요청을 보내 락의 획득가능여부를 체크하지 않아도 되도록 개선했습니다.

또한 Redisson은 최대한 레디스와 애플리케이션에 부하를 주지 않도록 신경 쓴 모습이 보입니다. 아래는 Redisson의 Lock 획득 프로세스입니다.

1. 대기 없는tryLock 오퍼레이션을 하여 락 획득에 성공하면 true를 반환합니다. 이는 경합이 없을 때 아무런 오버헤드 없이 락을 획득할 수 있도록 해줍니다.
2. pubsub을 이용하여 메시지가 올 때까지 대기하다가 락이 해제되었다는 메세지가 오면 대기를 풀고 다시 락 획득을 시도합니다. 락 획득에 실패하면 다시 락 해제 메시지를 기다립니다. 이 프로세스를 타임아웃 시까지 반복합니다.
3. 타임아웃이 지나면 최종적으로 false를 반환하고 락 획득에 실패했음을 알립니다. 대기가 풀릴 때 타임아웃 여부를 체크하므로 타임아웃이 발생하는 순간은 파라미터로 넘긴 타임아웃시간과 약간의 차이가 있을 수 있습니다.

 

정리

Lettuce

• 구현이 간단하다
• Spring data redis를 이용하면 lettuce가 기본이기 때문에 별도의 라이브러리를 사용하지 않아도 된다.
• Spin Lock 방식이기 때문에 동시에 많은 스레드가 lock 획득 대기 상태라면 redis에 부하가 갈 수 있다.

Redisson

• 락 획득 재시도를 기본으로 제공한다.
• pub-sub 방식으로 구현이 되어있기 때문에 lettuce와 비교했을 때 redis에 부하가 덜 간다.
• 별도의 라이브러리를 사용해야 한다.
• lock을 라이브러리 차원에서 제공해주기 때문에 사용법을 공부해야 한다.

 

참고

1. https://www.inflearn.com/course/동시성이슈-재고시스템
2. https://hyperconnect.github.io/2019/11/15/redis-distributed-lock-1.html
3. https://jypthemiracle.medium.com/weekly-java-%EA%B0%84%EB%8B%A8%ED%95%9C-%EC%9E%AC%EA%B3%A0-%EC%8B%9C%EC%8A%A4%ED%85%9C%EC%9C%BC%EB%A1%9C-%ED%95%99%EC%8A%B5%ED%95%98%EB%8A%94-%EB%8F%99%EC%8B%9C%EC%84%B1-%EC%9D%B4%EC%8A%88-9daa85155f66
4. https://velog.io/@minnseong/Spring-synchronized%EB%A1%9C-%ED%95%B4%EA%B2%B0%ED%95%A0-%EC%88%98-%EC%9E%88%EC%9D%84%EA%B9%8C
5. https://thalals.tistory.com/370