콘서트 서비스 동시성 제어 보고서

---

보고서 작성 배경

---

콘서트 서비스의 좌석 예약 및 포인트 충전 기능은 여러 유저가 동시에 요청을 보낼 수 있는 환경에서 동작합니다. 이때, 데이터의 일관성과 충돌 방지를 위한 동시성 제어는 필수적입니다. 이 글은 동시성 제어 방식으로 낙관적 락과 비관적 락을 적용한 경우의 성능을 비교하여, 최적의 동시성 제어 방식을 결정하기 위해 작성되었습니다.

기능 설명

---

• 좌석 예약: 여러 명의 유저가 동시에 동일한 좌석을 예약하려고 할 때, 한 명의 유저만 성공적으로 예약됩니다.
• 포인트 충전: 한 명의 유저가 포인트 충전을 동시에 호출할 경우, 순차적으로 충전되어야 합니다.

동시성 제어 방식

---

낙관적 락

• 낙관적 락은 데이터를 읽을 때는 락을 걸지 않고, 데이터를 업데이트할 때만 이전 데이터와 현재 데이터를 비교하여 충돌 여부를 판단합니다.
• 데이터 충돌이 드물게 발생한다고 가정합니다

낙관적 락의 작동 방식

• 데이터 수정 준비
  • 트랜잭션이 데이터를 수정할 때, 잠금 없이 데이터를 읽고 작업을 수행합니다.
• 검증 단계
  • 트랜잭션이 완료되기 전에 다른 트랜잭션이 해당 데이터에 접근하여 변경했는지를 확인합니다.
• 충돌 처리
  • 만약 다른 트랜잭션이 해당 데이터에 영향을 미쳤다면, 현재 트랜잭션은 실패하고 롤백됩니다.

낙관적 락의 장단점

• 낙관적 락의 장점
  • 락을 걸지 않기 때문에 트랜잭션 처리 속도가 빠르며, 동시에 여러 트랜잭션이 데이터에 접근할 수 있습니다.
  • 데이터베이스의 성능 저하를 최소화하고, 동시성을 높이는 데 유리합니다.
  • 데이터를 읽는 동안 다른 트랜잭션이 해당 데이터를 변경할 수 있기 때문에 데드락 발생 가능성이 낮습니다.
• 낙관적 락의 단점
  • 충돌이 발생했을 때 데이터를 다시 읽고, 업데이트해야 하는 추가 작업이 필요하다
  • 트랜잭션이 실패하고 롤백되는 경우가 발생할 수 있으므로, 일부 작업이 반복되어 비효율적일 수 있습니다.

비관적 락

• 비관적 락은 데이터를 읽을 때부터 해당 데이터에 대한 락을 걸어 다른 트랜잭션이 해당 데이터를 변경할 수 없게 합니다.
• 데이터를 읽을 때 SELECT FOR UPDATE와 같은 쿼리를 사용하여 데이터에 대한 락을 걸 수 있습니다.

비관적 락의 장단점

• 비관적 락의 장점
  • 데이터의 일관성을 보장합니다.
• 비관적 락의 단점
  • 성능 저하와 데드락 발생 가능성이 높습니다.

좌석 예약

동시성 테스트 코드

    @Test
    public void 좌석_예약_동시성_제어() throws Exception {
        // Given
        int threadCount = 100;
        ExecutorService executorService = Executors.newFixedThreadPool(threadCount);
        List<Future<ReserveSeatsResponseCommand>> futures = new ArrayList<>();

        // When
        for (int i = 0; i < threadCount; i++) {
            final Long userId = (long) i + 1;
            ReserveSeatsCommand command = new ReserveSeatsCommand(userId, concertId, scheduleId, seatIds);
            Future<ReserveSeatsResponseCommand> future = executorService.submit(() -> {
                try {
                    return reservationFacade.reserveSeats(command);
                } catch (Exception e) {
                    log.error("Reservation failed: {}", e.getMessage());
                    return null;
                }
            });
            futures.add(future);
        }

        // 성공 및 실패 카운터
        int successCount = 0;
        int failureCount = 0;

        // 스레드가 완료될 때까지 대기
        for (Future<ReserveSeatsResponseCommand> future : futures) {
            ReserveSeatsResponseCommand reservation = future.get();
            if (reservation != null) {
                successCount++;
                log.info("Reservation successful: {}", reservation.getReservationId());
            } else {
                failureCount++;
            }
        }
        log.info("successCount: {}", successCount);
        log.info("failureCount: {}", failureCount);

        // Then
        assertEquals(1, successCount);
        assertEquals(99, failureCount);

        // 모든 스레드가 작업을 완료한 후 예약 상태 확인
        List<Seat> reservedSeats = seatRepository.findSeatsByScheduleId(seatIds, scheduleId);
        reservedSeats.forEach(seat -> {
            assertEquals(seat.getStatus(), TEMPORARILY_RESERVED);
        });

        executorService.shutdown();
    }

낙관적 락 적용 후 실행 결과

• 1000개의 스레드 테스트
  

비관적 락 적용 후 실행 결과

• 1000개의 스레드 테스트
  

낙관적 락과 비관적 락 테스트 비교

테스트 결과는 다음과 같습니다.

• 낙관적 락을 적용한 테스트: 6초 278밀리초
• 비관적 락을 적용한 테스트: 7초 105밀리초

낙관적 락을 사용한 경우는 재시도 기능이 없으므로, 충돌이 발생하지 않는 경우에 빠르게 처리할 수 있습니다. 반면, 비관적 락은 대기 후 데이터를 처리하는 방식으로, 전체 실행 시간이 더 걸렸습니다. 따라서, 실패 시 재시도하는 기능이 없는 상황에서는 낙관적 락이 더 효율적이라는 결론을 내렸습니다.

포인트 충전

동시성 테스트 코드

    @Test
    void 포인트_충전_동시성_제어() throws InterruptedException {
        int THREAD_COUNT = 1000;

        RechargeCommand command = new RechargeCommand(1L, 100L);

        ExecutorService executorService = Executors.newFixedThreadPool(THREAD_COUNT);
        CountDownLatch latch = new CountDownLatch(THREAD_COUNT);
        for (int i = 0; i < THREAD_COUNT; i++) {
            executorService.submit(() -> {
                try {
                    pointService.rechargePoint(command);
                } catch (Exception e) {
                    e.printStackTrace();
                } finally {
                    latch.countDown();
                }
            });
        }

        latch.await();
        executorService.shutdown();

        Point point = pointRepository.point(1L);
        
        // DB에는 1000 포인트가 저장되어있습니다.
        assertThat(point.getPointAmount()).isEqualTo(new BigDecimal("101000.00"));

    }

낙관적 락 적용 후 실행 결과

• 1000개의 스레드 테스트
  

비관적 락 적용 후 실행 결과

• 1000개의 스레드 테스트
  

테스트 결론

테스트 결과는 다음과 같습니다.

• 낙관적 락을 적용한 테스트: 6초 693밀리초
• 비관적 락을 적용한 테스트: 4초 770밀리초

포인트 충전 기능의 경우, 동시성 제어를 하면서 모든 요청에 충전이 보장되어야 하는 시나리오입니다. 만약 동시에 10번의 충전 요청이 들어온다면, 10번 모두 충전이 되어야 합니다.

비관적 락은 대기 후 데이터를 처리하는 방식으로, 충돌이 발생할 경우 즉시 다른 스레드가 대기하는 구조입니다. 반면, 낙관적 락은 충돌 후 재시도 작업을 수행하기 때문에 시간이 더 걸렸습니다. 재시도 횟수를 @Retryable(value = {OptimisticLockingFailureException.class}, maxAttempts = 10, backoff = @Backoff(delay = 100))로 설정했지만, 이로 인해 효율성이 떨어지는 결과를 가져왔습니다.

결과적으로, 비관적 락이 더 빠른 성능을 보였으며, 낙관적 락은 재시도 로직으로 인해 오히려 비효율적이었습니다.

레디스 분산락 테스트

레디스 분산락은 다음 글을 참고하여 설정하였습니다

@Slf4j
@Aspect
@Component
@RequiredArgsConstructor
public class RedissonLockAspect {

    private final RedissonClient redissonClient;

    @Around("@annotation(com.hhplu.hhplusconcert.common.annotation.RedissonLock)")
    @Transactional
    public Object redissonLock(ProceedingJoinPoint joinPoint) throws Throwable {
        MethodSignature signature = (MethodSignature) joinPoint.getSignature();
        Method method = signature.getMethod();
        RedissonLock annotation = method.getAnnotation(RedissonLock.class);
        String lockKey = method.getName() + CustomSpringELParser.getDynamicValue(signature.getParameterNames(), joinPoint.getArgs(), annotation.value());

        RLock lock = redissonClient.getLock(lockKey);

        try {
            boolean lockable = lock.tryLock(annotation.waitTime(), annotation.leaseTime(), TimeUnit.MILLISECONDS);
            if (!lockable) {
                log.info("Lock 획득 실패={}", lockKey);
                throw new Exception("Lock 획득 실패");
            }
            log.info("로직 수행");
            return joinPoint.proceed();
        } catch (InterruptedException e) {
            log.info("에러 발생");
            throw e;
        } finally {
            log.info("락 해제");
            lock.unlock();
        }

    }

}

@Service
@RequiredArgsConstructor
public class PointFacade {
    private final PointService pointService;

    @RedissonLock(value = "#command.getUserId()")
    public GetPointCommand rechargePoint(RechargeCommand command) {
       return pointService.rechargePoint(command);
    }
}

참고

Redis(Redisson) 분산락을 활용하여 동시성 문제 해결하기

분산락 적용 후 실행 결과

• 1000개의 스레드 테스트
  

테스트 결론:

분산 락을 통해 1000개의 스레드가 동시에 포인트 충전 로직을 수행하는 테스트를 진행한 결과, 락 획득 및 해제 시 발생하는 오버헤드로 인해 전체 실행 속도가 다소 느려지는 것을 확인했습니다. Redisson의 분산 락은 분산 환경에서 데이터의 일관성을 보장하는 데 유용하지만, 높은 트래픽 상황에서 발생하는 락 획득 시도의 경쟁으로 인해 지연이 발생할 수 있다는 점을 파악했습니다.

최종 결론:

비관적 락과 낙관적 락을 적용하여 동일한 테스트를 진행해본 결과, 각 방법에 따른 성능 차이를 비교할 수 있었습니다. 비관적 락의 경우, 자원 충돌이 예상되는 상황에서 안정적인 동시성 제어가 가능했으나, 데이터 충돌이 발생하지 않는 경우에는 불필요한 락 점유로 인한 성능 저하가 있었습니다. 반면, 낙관적 락은 데이터 충돌이 적은 환경에서 빠른 성능을 보였지만, 충돌이 발생하면 롤백을 반복해야 하므로 리소스 소모가 커질 수 있다는 점을 발견했습니다.

초기 설계 방침에 따라, 자원 충돌 가능성이 높은 좌석 예약 시스템에는 낙관적 락을 적용하여, 불필요한 락 점유를 최소화하며 빠른 성능을 보장하기로 했습니다. 반면, 포인트 충전 기능에는 비관적 락을 사용하여, 충돌이 발생할 가능성이 낮음에도 불구하고 일관성 유지가 중요한 기능에 안정적인 동시성 제어를 도입하기로 결정했습니다. 분산 락은 향후 확장성이 필요한 환경이나 별도의 네트워크 분산 환경에서 유용하게 사용할 수 있을 것으로 판단하여, 상황에 맞게 적용 방안을 고려할 계획입니다.