공유 자원에 대한 동시 접근을 제어하기 위해 우리는 락 메커니즘을 사용할 수 있고, 그중에서도 분산 서버 환경에서 동시성을 제어하기 위해 분산락을 사용할 수 있다. 분산락을 적용하는 것만으로도 대부분의 동시성 문제를 해결할 수 있다.
하지만 대규모 분산 환경에서는 외부 시스템과의 연결 문제, 네트워크 지연 문제 등 우리가 예측할 수 없는 예외 상황이 얼마든지 발생할 수 있다.
지금부터 예외가 발생할 수 있는 시나리오를 재현해보고, Redis 기반의 분산락과 JPA의 낙관적 락을 함께 적용해서 문제를 해결하는 과정을 알아보자. 또한 락을 사용하게 되면 비즈니스 로직에 락을 획득하고 해제하기 위한 코드가 침범하게 된다. 이를 방지하기 위해 락 관련 코드를 AOP로 추출하는 과정까지 진행해보도록 하자.
정상적인 상황에서는 트랜잭션이 시작할때 락을 얻고, 트랜잭션이 커밋되면 락을 해제한다. 그 이후에 락 획득을 대기하고 있던 다른 트랜랙션이 락을 얻게 되고 자신의 로직을 실행한다. 하지만 비즈니스 로직 내에서 비정상적으로 동작이 지연되는 경우들이 발생할 수 있다.
락 메커니즘을 사용할때 꼭 설정해야 하는 것중 하나가 락 타임아웃이다. 만약 락을 획득한 트랜잭션이 무한정 락을 소유하고 있을 수 있다면 어떻게 될까. 해당 트랜잭션에서 지연이 발생하거나, 분산 서버 환경에서 락을 들고 있는 서버가 죽어버린다면 락의 소유권은 영영 돌려받을 수 없게 된다. 다른 트랜잭션들은 락 획득을 위해 무한정 대기하게 되고 결국 데드락이 발생할 것이다.
락 타임아웃이 트랜잭션 작동 시간보다 길다면 문제는 발생하지 않는다. 하지만 트랜잭션 내 비정상적인 지연으로 인해 트랜잭션 커밋보다 락 타임아웃이 먼저 만료가 되면 문제가 발생한다.
먼저 락을 획득한 클라이언트 1의 트랜잭션이 진행 중인 상황에서 락 타임아웃이 발생했기에 계좌 잔액에 대한 갱신 손실이 일어난 케이스라고 할 수 있다. 작은 규모의 서비스에서는 거의 발생할 일이 없는 예외일지라도, 서비스의 규모가 커지고 MSA 환경에서 서비스 간의 네트워크 통신이나 외부 서비스 연동이 많아진다면 발생 가능성이 충분히 높은 케이스라고 생각한다.
위에서 살펴본 예외 시나리오를 실제 코드로 재현해보고, 갱신 손실을 막을 수 있는 방법을 살펴보자.
@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Account {
@Id
@Column(name = "account_id")
private Long id;
@Column(name = "account_no")
private String accountNo;
private Long balance;
public void withdraw(Long money)
{
if(this.balance < money)
{
throw new IllegalArgumentException("잔고가 부족합니다.");
}
this.balance -= money;
}
public Account(Long id, String accountNo, Long balance) {
this.id = id;
this.accountNo = accountNo;
this.balance = balance;
}
}계좌에서 돈을 인출하는 시나리오를 재현하기 위해 우선 Account라는 엔티티를 구성했다.
@Slf4j
@Service
@RequiredArgsConstructor
@Transactional
public class AccountService {
private final AccountRepository accountRepository;
private static boolean static_error = true; // ---- (1)
public void withdraw(Long id, Long money) throws InterruptedException {
Account account = accountRepository.findById(id).orElseThrow();
if (static_error) { // ----- (2)
static_error = false; // ------(3)
log.info("{} 쓰레드가 중간에 네트워크 에러가 발생해서 5초간 지연 발생", Thread.currentThread().getName());
Thread.sleep(5_000L); // ------ (4)
}
account.withdraw(money);
}
}AccountService에서는 withdraw 메서드를 통해 계좌에서 돈을 인출한다.
@Service
@Transactional
@RequiredArgsConstructor
public class AccountFacade {
private final RedissonClient redissonClient;
private final AccountService accountService;
public void withdraw(Long id, Long money) throws InterruptedException {
final RLock lock = redissonClient.getLock(String.valueOf(id)); // ------- (1)
try {
boolean available = lock.tryLock(10, 3, TimeUnit.SECONDS); // ------- (2)
if (!available) { // -------- (3)
throw new RuntimeException("Lock을 획득하지 못했습니다.");
}
accountService.withdraw(money); // --------- (4)
} catch (InterruptedException e) {
throw new RuntimeException(e);
} finally {
lock.unlock(); // ---------- (5)
}
}
}분산락을 적용하기 위한 Facade 계층을 추가했다.
주의깊게 봐야할 부분은 지연이 지속되는 시간과 redisson에서 락을 획득하려 시도하는 과정에 설정한 락 소유 타임아웃이다. 지연 지속 시간은 5초로 설정한 반면 락 소유 타임아웃은 3초로 설정했다. 즉, 첫번째로 락을 획득한 클라이언트는 트랜잭션이 커밋되기 전에 락 타임아웃으로 인해 락이 해제될 것이다. 위의 도표에서 살펴본 문제가 실제로 발생하는지 테스트를 통해 확인해보자.
@SpringBootTest
class LockTest {
@Autowired
private AccountFacade accountFacade;
@Autowired
private AccountRepository accountRepository;
// 테스트를 시작할때마다 계좌 엔티티를 새로 등록한다.
@BeforeEach
public void before()
{
Account account = new Account(1L,"842400-4324-3445",10_000L);
accountRepository.saveAndFlush(account);
}
// 테스트가 끝날때마다 계좌 테이블을 전체 삭제한다.
@AfterEach
public void after()
{
accountRepository.deleteAll();
}
@Test
public void 한쪽_트랜잭션중_지연이_발생하여_락이_먼저_풀리는_경우() throws InterruptedException {
int threadCount = 2; // 테스트하는 쓰레드의 개수는 2개이다.
CountDownLatch latch = new CountDownLatch(threadCount);
ExecutorService executorService = Executors.newFixedThreadPool(2);
for(int i = 0; i < threadCount; i++)
{
executorService.submit(() -> {
try {
accountFacade.withdraw(1L, 3_000L); // 클라이언트 1,2는 각각 3000원씩 인출을 시도한다.
} catch (InterruptedException e) {
throw new RuntimeException(e);
} finally {
latch.countDown();
}
});
}
latch.await();
Account account = accountRepository.findById(1L).orElseThrow();
Assertions.assertEquals(4_000L,account.getBalance()); // 3000원씩 2번 인출했으므로 잔액이 4000원이 남을 것으로 예상한다.
}
}클라이언트 1과 클라이언트 2가 각각 3000원씩 계좌에서 인출을 했다면 잔액은 4000원이 남아있어야 한다. 하지만 테스트 결과로는 잔액이 7000원 남아있다. 갱신 손실이 발생한 상황이다.
위에서 확인한 갱신 손실 문제는 분산락 매커니즘 만으로는 방지가 불가능하다. 이를 해결하기 위해서는 하나의 트랜잭션이 데이터를 변경 후 DB에 반영할때, 다른 트랜잭션에 의한 변경 사항이 있는지를 체크해야 하는데 JPA의 낙관적 락 매커니즘을 사용해서 구현할 수 있다.
분산락과 낙관적 락을 함께 사용한 예이다.
public class AccountFacade {
public void withdraw_with_optimistic_locking(Long id, Long money) throws InterruptedException {
// -------- (1)
while (true) {
try {
checkDistributeRedisLockAndExecute(id, money); // -------- (2)
log.info("{} 쓰레드가 계좌에서 인출 완료", Thread.currentThread().getName());
break; // ------- (3)
} catch (Exception e) {
log.info("{} 쓰레드가 인출 후, DB의 버전을 확인했을때 불일치가 발생해서 미반영 후 재시도", Thread.currentThread().getName());
Thread.sleep(2000);
}
}
}
private void checkDistributeRedisLockAndExecute(Long id, Long money) throws InterruptedException {
final RLock lock = redissonClient.getLock(String.valueOf(id));
try {
boolean available = lock.tryLock(10, 3, TimeUnit.SECONDS);
if (!available) {
throw new RuntimeException("Lock을 획득하지 못했습니다.");
}
accountService.withdraw_with_optimistic_locking(id, money);
} catch (InterruptedException e) {
throw new RuntimeException(e);
} finally {
lock.unlock();
}
}
}분산락과 낙관적락을 모두 적용한 경우를 테스트해보자.
@Test
public void 한쪽_트랜잭션중_지연이_발생하여_락이_먼저_풀리지만_낙관적락으로_방어한_경우() throws InterruptedException {
int threadCount = 2;
CountDownLatch latch = new CountDownLatch(threadCount);
ExecutorService executorService = Executors.newFixedThreadPool(2);
for(int i = 0; i < threadCount; i++)
{
executorService.submit(() -> {
try {
accountFacade.withdraw_with_optimistic_locking(1L,3_000L);
} catch (InterruptedException e) {
throw new RuntimeException(e);
} finally {
latch.countDown();
}
});
}
latch.await();
Account account = accountRepository.findById(1L).orElseThrow();
Assertions.assertEquals(4_000L,account.getBalance());
}
}클라이언트 1,2가 모두 3000원씩 차감한 결과 4000원의 잔액이 정상적으로 남게 되었다. 아래의 로그를 보면 클라이언트 2가 먼저 커밋됨으로써 버전이 변경되었고 클라이언트 1은 변경 사항 반영에 실패한 후, 재시도를 진행한 걸 알 수 있다.
대부분의 상황에서 분산락을 적용한 것 만으로도 동시성을 충분히 제어할 수 있을 것이다. 하지만 대규모 환경에서는 어떤 예외 사항이 발생할지 모르기때문에 데이터의 정합성을 위해 모든 상황을 가정하고 방어 수단을 만들어 놓는게 중요하다고 생각한다.
현재는 분산락과 낙관적락을 구현한 코드가 비즈니스 로직과 합쳐서 있는 것을 알 수 있다. 락을 획득하고 해제하는 코드는 모두 형태가 비슷하고 비즈니스 로직과 합쳐져서 비즈니스 로직의 가독성을 떨어뜨리고 있다. 다음 시간에는 AOP를 적용해서 락 매커니즘을 비즈니스 코드와 완전히 분리를 시켜보겠다.
