[Spring] 데코레이터 패턴을 통한 동시성 문제 해결 및 비즈니스 로직과 동시성 관련 로직 간의 관심사 분리하기

개요

현재 지인 3분과 함께 동시성 문제에 대한 경험을 쌓기 위해 티케팅 서비스를 개발하는 프로젝트를 진행하고 있습니다.

GitHub - Tiketeer/Tiketeer-BE

해당 프로젝트를 시작하면서 달성하고자 했던 핵심 목표 중 하나는, 동시성 문제를 직접 겪어보고 이를 해결하는 방법론에 대한 학습과 이를 실제로 해결해본 경험을 갖는 것이었습니다.

저희 프로젝트 내에서 동시성 문제가 발생하는 지점은 바로 티케팅을 수행하는 로직입니다. 서버 상에는 한정된 수의 티켓이 존재하게 되는데, 이에 대해 티켓보다 더 많은 고객이 동시다발적으로 티켓을 획득하려는 과정에서 데이터 정합성 문제가 발생하는 것이죠. 저희 팀은 이 문제를 다양한 방법으로 접근해보기 위해 각자 비관적 락(P-lock), 낙관적 락(O-lock), 분산 락(D-lock)을 이용하여 문제를 해결해보는 과정을 거쳤습니다.

그리고 최종적으로 저희 상황에 가장 부합하는 하나의 방법론을 확정하기 위한 테스트 및 결과 분석 단계를 앞두고 있습니다.

저희는 자동화된 테스트를 원했고, 이를 위해 추가적인 개별 코드 수정 없이 코드 컨텍스트 외부에서 어떤 방법론을 사용하여 락을 수행할지 결정하고, 주입해주기를 원했습니다.

이러한 요구사항은 결국 객체지향 설계 원칙의 ‘개방-폐쇄 원칙’에 해당되는 문제이고, 따라서 확장 가능한 객체지향 설계가 필요한 상황이었습니다. 이를 위해 추가적인 아키텍쳐 미팅을 진행하고 결정된 아키텍쳐에 맞게 각자 로직을 구성하였습니다.

하지만 이 과정에서 다양한 문제들이 발생하여 최종적으로는 초기 논의했던 아키텍쳐와는 사뭇 다른 방식으로 개발이 진행되었습니다.

해당 글에서는 개발 중에 겪은 다양한 문제점들과 더불어 문제가 왜 발생했는지에 대한 고찰을 진행하고, 최종적으로는 문제 상황들을 고려한 새로운 아키텍쳐 개선안을 도출해내고자 합니다.

 

들어가기 앞서

글 내용에 대해 쉽게 이해하기 위해서는 락을 구현하는 방법론들의 종류와 그 특징을 알고 있는 편이 좋습니다.

이를 위해 각 방법론에 대해 간단히 다루면 아래와 같습니다.

• O-lock
  • 낙관적 락이라고 일컬어지는 방식입니다.
  • 테이블 내 버전 칼럼을 추가하고 해당 레코드가 수정될 때마다 이 값을 함께 수정하는 방식입니다.
    • 버전 칼럼의 경우, 단순 Integer 형식을 사용할 수도, 혹은 수정된 순간을 기록하는 Timestamp 형식을 사용할 수도 있습니다.
    • 일반적으로 JPA에서 제공하는 @Version 어노테이션을 통해 간단히 설정할 수 있습니다.
  • 로직 내에서 업데이트를 위해 읽어온 값을 DB로 다시 동기화하는 과정에서 초기 읽어왔던 버전 값과 동기화하는 순간의 버전 값이 다를 경우 발생하는 예외를 따로 처리하는 식으로 구현합니다.
    • 실행 쿼리 예시
    • UPDATE users SET name = "Jamal", version = version + 1 WHERE id = 10 and version = ?;
  • 애플리케이션 레벨에서 동시성에 대해 다루지 않고, 일단 쿼리를 날린 뒤 예외가 발생할 경우 그제서야 동시성 핸들링을 하는 방식으로 조회 시 어떠한 락도 사용하지 않기 때문에 성능 저하가 없지만 만약 동시성 문제가 발생한 상황이라면 네트워크 비용 + 예외 처리 비용 + 재요청 비용이 추가되어 성능적으로 큰 저하를 겪을 수 있습니다.
• P-lock
  • 비관적 락이라고 일컬어지는 방식입니다.
  • 데이터를 읽어올 때 SELECT ~ FOR UPDATE 문을 이용하여, 타겟 레코드에 배타락을 거는 방식으로 동작합니다.
  • 일반적인 트랜잭션 격리수준(READ COMMITED, REPEATABLE READ)에서는 MVCC로 인해 다른 트랜잭션에서 배타락이 걸린 레코드도 읽을 수 있으나(단순 조회), 데이터 수정이나 혹은 다른 SELECT ~ FOR UPDATE 문을 통해서는 동시 접근이 불가능해집니다. 이로 인해 성능의 저하가 발생할 수 있습니다.
• D-lock
  • 분산 락이라고 일컬어지는 방식입니다.
  • 해당 방식은 RDB, 서버 인스턴스, 스레드 등에 종속적이지 않고 오로지 락을 저장할 외부 저장소에만 의존을 합니다. 이로 인해 서버, RDB 등의 스케일아웃으로 인한 분산 환경에서도 자유롭게 활용이 가능합니다.
  • 일반적으로 인메모리 DB인 레디스를 락 저장소로 활용합니다.

 

기존 아키텍쳐

위 UML은 초기 미팅을 통해 구성한 일부 아키텍쳐에 대한 내용입니다.

CreatePurchaseUseCase 클래스에 실질적인 티켓 구매에 대한 비즈니스 로직이 작성되어 있는데, 이 때 동시성 문제가 발생할 수 있는 유저 - 티켓 배정 작업은 동시성을 다루는 TicketConcurrencyService에 위임하여 수행하는 구조로 작성되어 있습니다.

위 구조에서 트랜잭션 시작 지점까지 함께 표시하면 아래와 같습니다.

 

문제 발생

위 아키텍쳐를 기반으로 TicketConcurrencyService 인터페이스의 구현체를 팀원 분들께서 하나씩 담당하여 구현해주셨습니다.

그리고 실제 테스트를 진행해보니, 이 중 DB에 종속되는 방식으로 구현되는 비관적 락을 제외한 나머지 두 방법이 위 구조에서 문제를 발생시켰습니다.

저는 이 문제를 해결하기 위해 테스트 실행 시 발생하는 로그들을 일일이 따라가며 디버깅을 진행하였고 최종적으로는 문제가 발생하고 있는 부분들을 확인할 수 있었습니다.

실제 구현에 대한 간략한 설명과 발생했던 문제를 설명하면 아래와 같습니다.

• O-lock (낙관적 락)
  • 구현
    • CreatePurchaseUseCase에서 전파된 트랜잭션에 TicketOptimisticLockConcurrencyService.assignPurchaseToTicket 메서드가 참여하는 방식입니다.
    • 이 때 낙관적 락 방식에서 발생하는 예외를 assignPurchaseToTicket 메서드 내에서 try - catch로 잡아내고 @Retryable 어노테이션을 통해 FailOver를 수행하는 방식으로 구현을 진행했습니다.

    @Retryable(
    	retryFor = OptimisticLockingFailureException.class,
    	backoff = @Backoff(delay = 100),
    	maxAttempts = 100
    )
    public void assignPurchaseToTicket(UUID ticketingId, UUID purchaseId, int ticketCount) throws
    	ConcurrencyFailureException {
    	var purchase = purchaseCrudService.findById(purchaseId);
    	var tickets = ticketRepository.findByTicketingIdAndPurchaseIsNullOrderByIdWithOptimisticLock(
    		ticketingId, Limit.of(ticketCount));
    
    	if (tickets.size() < ticketCount) {
    		throw new NotEnoughTicketException();
    	}
    
    	tickets.forEach(ticket -> {
    		ticket.setPurchase(purchase);
    	});
    	ticketRepository.flush();
    }

  • 문제
    • 첫번째로, REPEATABLE READ 고립 레벨에서는 정상 동작하지 않습니다. 구체적으로는 해당 메서드에서 FailOver가 되더라도 상위 트랜잭션이 롤백되지 않기 때문에 처음 읽었던 버전이 변경되지 않는데, 그렇기 때문에 한번 실패할 경우 모든 재시도 횟수가 전부 소모되더라도 계속해서 OptimisticLockException이 발생합니다.
    • 두번째로, OptimisticLockException은 RuntimeException의 일종이기 때문에 현재 트랜잭션에 rollbackOnly 마킹이 되는데, 이 경우엔 정상 커밋이 되는 상황에서도 명시적인 롤백이 실행됩니다. 따라서 한번이라도 실패한 경우 재시도와는 관련없이 최종적인 결과는 항상 Rollback이 되는 문제가 있었습니다.
• D-lock (분산 락)
  • 구현
    • CreatePurchaseUseCase에서 전파된 트랜잭션에 TicketDistributedLockConcurrencyService.assignPurchaseToTicket 메서드가 참여하는 방식입니다.
    • 이 때 낙관적 락 방식에서 발생하는 예외를 assignPurchaseToTicket 메서드 내에서 try - catch로 잡아내고 @Retryable 어노테이션을 통해 FailOver를 수행하는 방식으로 구현을 진행했습니다.

    public void assignPurchaseToTicket(UUID ticketingId, UUID purchaseId, int ticketCount) {
    	String lockName = ticketingId.toString();
    	RLock rLock = redissonClient.getLock(lockName);
    
    	final long waitTime = 10L;
    	final long leaseTime = 3L;
    	TimeUnit timeUnit = TimeUnit.SECONDS;
    	try {
    		boolean available = rLock.tryLock(waitTime, leaseTime, timeUnit);
    
    		if (!available) {
    			throw new TicketConcurrencyException();
    		}
    
    		var purchase = purchaseCrudService.findById(purchaseId);
    		var tickets = ticketRepository.findByTicketingIdAndPurchaseIsNullOrderById(
    			ticketingId, Limit.of(ticketCount));
    
    		if (tickets.size() < ticketCount) {
    			throw new NotEnoughTicketException();
    		}
    
    		tickets.forEach(ticket -> {
    			ticket.setPurchase(purchase);
    		});
    
    	} catch (InterruptedException e) {
    		throw new TicketConcurrencyException();
    	} finally {
    		TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
    			public void afterCompletion(int status) {
    				rLock.unlock();
    			}
    		});
    	}
    }

  • 문제
    • 이번에도 REPEATABLE READ 고립 레벨이 문제가 되었습니다. 구체적으로 위의 assignPurchaseToTicket 메서드를 직렬화한다고 해도 이미 그 상위 메서드인 CreatePurchaseUseCase.createPurchase에서 이미 조회가 일어나기 때문에 직렬화 직전에 스냅샷이 생성되게 되고 이로 인해 직렬화된 메서드 내에서도 모두 동일한 버전의 티켓들을 조회하게 됩니다. 따라서 동시성 문제가 해결되지 않습니다.

 

문제 해결 방안

낙관적 락 방식에서 발생하는 문제는 결국 Retryable을 통해 완전히 새로운 트랜잭션을 시작시켜야 해결할 수 있습니다. 또한 공유 락 방식에서 발생하는 문제는 최상위 트랜잭션에서 첫번째 조회가 발생하기 전에 공유 락 로직을 감싸야 해결이 가능합니다.

즉, 두 방식 모두 최상위 트랜잭션에 관련 로직이 동작하도록 코드를 수정하면 해결이 되는 문제인 것입니다.

따라서 로직의 통일성을 위해 락에 대한 확장 포인트를 TicketConcurrencyService 레벨에서 잡는 것이 아닌, CreatePurchaseUseCase 레벨에서 잡는 방향으로 코드를 수정하는 결론을 냈습니다.

 

문제 해결 방안 심화

가장 단순한 해결책은 아무래도 CreatePurchaseUseCase를 구체 클래스가 아닌 인터페이스로 변경하고 이들에 각각 비즈니스 로직과 동시성 제어 로직을 함께 추가하는 것입니다.

하지만 개인적으로 이 방식은 CreatePurchaseUseCase 인터페이스를 구현하여 새로 생겨날 3개의 구체 클래스에 중복 로직이 계속 발생할 것이라 생각했습니다. CreatePurchaseUseCase 내에는 동시성 제어 로직도 있지만, 비즈니스 로직도 존재하는 상황입니다.

// 티켓 구매 비즈니스 로직
public CreatePurchaseResultDto createPurchase(CreatePurchaseCommandDto command) {
	var ticketingId = command.getTicketingId();
	var count = command.getCount();

	var member = memberCrudService.findByEmail(command.getMemberEmail());

	purchaseService.validateTicketingSalePeriod(ticketingId, command.getCommandCreatedAt());

	var ticketing = ticketingService.findById(ticketingId);

	memberPointService.subtractPoint(member.getId(), ticketing.getPrice() * count);

	var purchase = purchaseRepository.save(Purchase.builder().member(member).build());

	// #1 락 종류에 따라 다른 메서드를 호출해야 함 
	var tickets = ticketRepository.findByTicketingIdAndPurchaseIsNullOrderById(ticketingId, Limit.of(count));

	if (tickets.size() < count) {
		throw new NotEnoughTicketException();
	}

	tickets.forEach(ticket -> {
		ticket.setPurchase(purchase);
	});

	return CreatePurchaseResultDto.builder()
		.purchaseId(purchase.getId())
		.createdAt(purchase.getCreatedAt())
		.build();
}

과연 이 로직들이 어떤 락을 사용하느냐에 따라 바뀌어야 할 이유가 있을까요? 개인적으로 내린 결론은 “불필요하다.”입니다. 이에, 아래의 요구사항들을 정의하고 어떤 아키텍쳐를 가져가면 좋을지 고민을 시작했습니다.

• 낙관적 락 로직
  • 이전에 발생했던 문제의 해결을 위해, Retryable이 Transaction 생명주기를 완전히 감싸는 형태가 되어야 함.
  • 위 로직의 #1에서 낙관적 락 전용 TicketRepository.findByTicketingIdAndPurchaseIsNullOrderByIdWithOptimisticLock 메서드를 호출해야 함.
• 비관적 락 로직
  • 위 로직의 #1에서 비관적 락 전용 TicketRepository.findByTicketingIdAndPurchaseIsNullOrderByIdWithPessimisticLock 메서드를 호출해야 함.
• 공유 락 로직
  • Redisson을 통한 공유 락 획득 - 반환 흐름이 Transaction 생명주기를 완전히 감싸는 형태가 되어야 함.
  • 위 로직의 #1에서 락이 적용되지 않은 TicketRepository.findByTicketingIdAndPurchaseIsNullOrderById 메서드를 호출해야 함.

위 요구사항을 종합하면, 1) 확장 포인트인 동시성 제어 로직이 비즈니스 로직을 감싸야 하고, 2) 비즈니스 로직 내에 어떻게 후보 티켓을 가져올지에 대한 방법론을 주입해줄 수 있어야 합니다.

이를 통해 저는 요구사항을 만족시키기 위한 방안으로 객체지향 디자인 패턴의 데코레이터 패턴을 떠올렸습니다.

아래는 데코레이터 패턴의 이해를 돕기 위한 아키텍쳐 예시입니다.

https://sourcemaking.com/design_patterns/decorator

 

이를 통하면 코어 로직은 그대로 내버려 둔 채 코어 로직을 감싸는 일련의 작업(동시성 제어)들에 대한 확장을 편하게 가능합니다. 또한 데코레이터 레이어에서 코어 로직을 호출할 때 메서드 인자로 후보 티켓들을 조회하는 방법론에 대한 함수형 인터페이스를 전달하는 DI를 통해 락에 따라 다른 티켓 조회 방법론에 대한 요구사항을 만족시키고자 했습니다.

 

수정 아키텍처

수정된 아키텍처는 위와 같습니다.

간략히 설명을 덧붙이자면, CreatePurchaseUseCaseCore 내에 메인 비즈니스 로직이 포함되고 이를 감싸는 데코레이터 객체인 CreatePurchaseUseCaseOLock, CreatePurchaseUseCasePLock, CreatePurchaseUseCaseDLock이 각각 존재합니다. 또한 각각의 동시성 제어 방법론에서 사용되어야 할 TicketRepository 메서드를 주입해주기 위해 ListTicketStrategy라는 함수형 인터페이스를 생성하고 각각의 데코레이터에서 코어 로직을 호출할 때 직접 주입해주는 방식으로 로직이 작성되어 있습니다.

구체적인 코드는 아래 링크를 통해 확인이 가능합니다.

Tiketeer-BE/src/main/java/com/tiketeer/Tiketeer/domain/purchase/usecase/decorator at develop · Tiketeer/Tiketeer-BE

 

결론

리팩토링 후 코드 라인 수가 많이 줄어든 모습

기존에 동시성 문제를 해결하기 위해 구축한 CreatePurchaseUseCase - TicketConcurrency 구조에서 발생하는 추가적인 동시성 이슈에 대한 핸들링은 물론, 데코레이터 패턴을 통한 리팩토링으로 로직 상의 변하지 않는 부분(코어 비즈니스 로직)과 변하는 부분(동시성 제어 방법론)을 효과적으로 분리하여 결론적으로는 코드의 재사용성과 유지보수성이 뛰어난 아키텍쳐를 구성할 수 있었습니다.