비관적 락을 통한 계좌이체 동시성 핸들링 (feat. @Transactional 학습 테스트)

JPA의 @Transactional 어노테이션에 대한 이해를 올릴 겸, 아래 레포를 생성하고 학습 테스트를 진행했다.

GitHub - One-armed-boy/transactional_test: 학습 테스트 of @Transactional

테스트 예제는 일반적으로 동시성 예제에 많이 등장하는 계좌 이체 컨텍스트를 간단하게 구현하고자 했다.

아래는 이를 위한 시퀀스를 말로써 정리한 내용이다.

1. 사용자 A를 조회
2. 사용자 B를 조회
3. 사용자 A에게 송금 요청이 들어온 X 만큼의 잔액이 존재하는지 확인
   • 존재한다면, 사용자 B의 잔액에 X를 더함
   • 존재하지 않는다면, 아무 일도 발생시키지 않음

이를 구현하기 위해, UserService 인터페이스를 생성하고 transfer 메서드를 아래처럼 구현해주었다.

public void transfer(String fromUserId, String toUserId, long money) {
  User fromUser = userRepository.findById(fromUserId).orElseThrow(EntityNotFoundException::new);
  User toUser = userRepository.findById(toUserId).orElseThrow(EntityNotFoundException::new);
  long fromBalance = fromUser.getBalance();

  if (fromBalance < money) {
    return;
  }
  fromUser.setBalance(fromUser.getBalance() - money);
  toUser.setBalance(toUser.getBalance() + money);
}

그 후 @Transactional 유무를 비교하기 위해 어노테이션을 붙여준 UserServiceWithTx와 붙이지 않은 UserServiceWithoutTx를 생성해주고 각각 아래 테스팅 메서드에 인자로 주입해주었다.

private void execTestLogic(UserService userService) throws InterruptedException {
    // given
    User user1 = new User("Jamal", 100);
    User user2 = new User("Nikola", 30);
    userService.addUser(user1);
    userService.addUser(user2);

    var numOfThread = 10;
    var moneyForTransfer = 20;
    CountDownLatch startLatch = new CountDownLatch(1);
    CountDownLatch endLatch = new CountDownLatch(numOfThread);

    // when
    for (int i = 0; i < numOfThread; i++) {
      new Thread(()->{
        try {
          startLatch.await();

          userService.transfer(user1.getUser(), user2.getUser(), moneyForTransfer);
        } catch (Exception e) {
          System.out.println(e.getMessage());
        } finally {
          endLatch.countDown();
        }
      }).start();
    }
    startLatch.countDown();
    endLatch.await();

    // then
    User user1After = userService.getUserById(user1.getUser());
    User user2After = userService.getUserById(user2.getUser());
    Assertions.assertThat(user1After.getBalance()).isEqualTo(Math.max(0, user1.getBalance() - numOfThread * moneyForTransfer));
    Assertions.assertThat(user2After.getBalance()).isEqualTo(Math.min(user1.getBalance() + user2.getBalance(), user2.getBalance() + numOfThread * moneyForTransfer));
  }

테스트 결과, 어노테이션이 없는 로직은 당연히 의도한대로 테스트가 실패했지만, 어노테이션이 있는 로직도 동일하게 실패했다.

어노테이션이 있는 로직도 실패하는 것은 의도와 벗어나기 때문에 이에 대한 원인 분석을 수행했다.

 

1차 테스트 실패 원인 분석

단순 @Transactional 만 걸어줄 경우, 트랜잭션 격리 수준은 DB의 기본 설정을 따라가는 것으로 이해했다.

테스트 용으로 Mysql을 사용하고 있었기 때문에 기본 격리 수준은 REPEATABLE READ가 된다.

이 경우 여러 트랜잭션이 동시 다발적으로 유저의 잔액 정보에 접근할 경우, 특정 트랜잭션에서 잔액을 수정하고 커밋을 하더라도 이미 잔액 정보에 접근한 트랜잭션에는 영향을 미치지 못한다. (나중에 안 사실이지만, 만약 영속성 컨텍스트를 활용하고 있다면 앞선 문제보다는 영속성 컨텍스트의 1차 캐싱으로 인한 문제가 더 우선되기는 한다.)

따라서 초기에는 트랜잭션 격리수준이 문제인가 싶어서, 아래처럼 격리수준을 SERIALIZABLE로 수정했다.

// @Transactional
@Transactional(isolation = Isolation.SERIALIZABLE)
public void transfer(...) {
  ...
}

다만 이 경우엔 데드락이 발생하여 스레드들 중 단 하나의 스레드의 수정만 반영이 되는 문제가 새롭게 발생했다.

 

2차 테스트 실패 원인 분석 (with Second Lost Updates Problem)

Mysql의 경우 가장 최근에 발생한 데드락을 확인할 수 있기 때문에 이를 이용하여 왜 데드락이 발생했는지 분석할 수 있었다.

이를 보면 상황을 아래처럼 정리할 수 있다.

1. 모든 스레드들은 자신이 업데이트 해야 할 레코드들을 조회한다. 이 때 격리수준에 의해 레코드에 S 락을 건다.
2. 그 후, 순차적인 업데이트를 위해 레코드 하나에 대해 X 락을 획득하고자 한다.
3. 이 때, 다른 스레드에서도 해당 레코드에 대한 S 락을 이미 획득한 상황이고 마찬가지로 다른 스레드에서도 해당 레코드에 대한 X 락을 요청할 것이기 때문에 데드락 상태에 빠진다.

이 문제는 Mysql 내에서 SERIALIZABLE 격리수준을 구현하는 방식이 Select 문을 Select for share(S 락 획득)로 수정하여 실행시키는 방식이기 때문에 발생하게 된다. 즉, 트랜잭션 격리수준을 통해서는 완전히 해결할 수 없는 문제인 것이다.

(이후에 안 사실은, 위 계좌이체 예시처럼 여러 트랜잭션이 동시다발적으로 특정 레코드에 대한 조회, 수정 작업을 수행하는 상황에서 발생하는 문제를 Second lost updates problem(두번의 갱신 분실 문제)이라고 하고 이는 트랜잭션 격리수준 만으로는 해결할 수 없는 문제로 유명하다는 것이다.)

 

해결책 모색

JPA에서는 두번의 갱신 분실 문제를 위해 추가적으로 락을 활용할 수 있다.

이 때 활용할 수 있는 락의 종류로는 낙관적 락과 비관적 락이 있는데, 두 락의 특징과 장단점은 아래와 같다.

낙관적 락 (Optimistic Lock)

• 방식
  
  • 엔티티에 Version 칼럼을 추가하고, 영속성 컨텍스트 내의 버전 값과 실제 DB의 버전 값을 비교하여 다른 트랜잭션에 의한 레코드 수정이 발생했는지 확인하는 방식으로 동작한다.
  • 만약 버전 값이 다르다면, 예외를 발생시킨다.
• 장점
  • DB 레이어의 락을 사용하지 않기 때문에, 트랜잭션 충돌이 적은 환경에서는 좋은 성능을 보여준다.
  • 마찬가지로 DB 레이어의 락을 사용하지 않기 때문에, 상대적으로 데드락 문제에서 자유롭다.
• 단점
  • 예외 발생 시 예외 처리 로직을 추가로 작성해주어야 한다. (ex. Fail over 로직)
  • 트랜잭션 충돌이 잦은 환경에서는 트랜잭션 단위로 롤백이 빈번해지고 이로 인한 트랜잭션 재실행이 많아지기 때문에 성능이 급격하게 나빠질 가능성이 있다.

비관적 락 (Pessimistic Lock)

• 방식
  • 엔티티에 대한 추가적인 칼럼 소요 없이, DB 레이어의 락을 통해 문제를 해결한다.
  • 조회 시 Select for update 쿼리를 수행하여 X 락을 획득하여 동시성 문제를 해결한다.
• 장점
  • 개발자의 로직 개발 소요가 적다.
  • DB 레이어의 락을 활용하기 때문에 트랜잭션 전체가 재실행되지 않고 잠시 대기만 하는 방식을 통해, 트랜잭션 충돌이 빈번한 상황에서 비교적 더 좋은 성능을 발휘할 수 있다.
• 단점
  • 조회에도 X 락을 걸기 때문에 해당 레코드를 참조하는 서버 내 다른 모든 쿼리의 성능이 나빠질 가능성이 있다.
  • 여러 테이블 간 조회가 필요할 경우, 데드락 문제가 발생할 수 있다.

나는 단순 학습 테스트를 수행하는 컨텍스트였기 때문에, 비관적 락을 선택하여 문제를 해결했다.

이를 위해 Repository 내 비관적 락을 수행하는 업데이트용 유저 조회 메서드를 새로 생성하는 수고가 존재했지만 낙관적 락을 선택했을 경우보다는 훨씬 나은 듯.

@Repository
public interface UserRepository extends JpaRepository<User, String> {
  @Transactional
  @Lock(value = LockModeType.PESSIMISTIC_WRITE)
  Optional<User> findForUpdateByUser(String id);
}

다만 실제 현업에서 같은 상황을 겪게 된다면 그 땐 더 많은 요소를 고려해봐야 할 것으로 보인다.