동시성 제어를 Redisson과 AOP로 해결하기

[RTUnu12]

문제 상황

• 현재 구현된 동시성 제어일 경우 Lettuce 방식, 락이 해제될 때까지 계속해서 요청을 보내는 스핀 락입니다. 그렇기에 싱글 스레드 환경인 Redis일 경우 이 요청이 쌓이고 쌓여 큰 부하를 일으킬 수 있는 상황입니다.

Redisson

요청을 계속 보내지 말고, 그냥 기다렸다가 풀리는 방법은 없을까?

• 앞에서 말했다시피, Lettuce 방식은 계속 요청을 하는 방식이기에 부하가 발생할 수 있습니다. 그러면 한번 요청해서 자신의 차례가 올때까지 기다리는 것은 없을까요?
• Redisson 방식일 경우 위의 방식, 즉 PubSub 방식을 통해서 동시성 제어 문제를 해결합니다.
  • 즉, Publisher가 등록된 Subscriber에게 채널을 통해 키를 획득하는 방식이기에, Redis에 큰 부하를 일으키는 문제를 해결할 수 있습니다.

Spring Boot에서의 설정

• 의존성 추가 후, Redisson 객체에 대한 경로 및 빈 설정을 해주시면 간편하게 끝납니다.

implementation 'org.redisson:redisson-spring-boot-starter:3.16.3'

@Configuration
public class RedissonConfig {
    private static final String REDISSON_HOST_PREFIX = "redis://";

    @Bean
    public RedissonClient redissonClient(){
        Config config = new Config();
        config.useSingleServer().setAddress(REDISSON_HOST_PREFIX + "localhost:6379");
        return Redisson.create(config);
    }
}

일반적인 구현

• 원본 코드입니다. while문을 사용해 해제될 때까지 0.1초 간격으로 계속 요청을 하는 코드입니다.

    public ScheduleAssignResponseDto assignScheduleToGuest(String meetingUuid, ScheduleAssignRequestDto requestDto) {
        String key = "meeting-" + meetingUuid;
        while (!redisRepository.lock(key)) {
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        }

        try {
            return scheduleService.assignScheduleToGuest(meetingUuid, requestDto);
        } finally {
            redisRepository.delete(key);
        }
    }

• 기존의 코드였던 Lettuce 방식을 while문을 제거하고 특수한 메소드를 넣음으로써 다음과 같이 고칠 수 있습니다.

public ScheduleAssignResponseDto assignScheduleToGuest(String meetingUuid, ScheduleAssignRequestDto requestDto) {
    String key = "meeting-" + meetingUuid;
    RLock lock = redissonClient.getLock(key);
    boolean isLocked = false;
    try {
        isLocked = lock.tryLock(0, 10, TimeUnit.SECONDS);
        // tryLock(wateTime, leaseTime, timeUnit) : 락 요청 메소드
        // waitTime: 락 획득을 위해 기다리는 시간 (0)
        // leaseTime: 락을 임대하는 시간 (10)
        // timeUnit: 시간 단위 (seconds)
        //  획득을 요청했을 때 락을 획득할 수 없다면 0초만큼 기다리고,락을 획득했다면, 최대 10초만큼 락을 점유
        if (isLocked) {
            return scheduleService.assignScheduleToGuest(meetingUuid, requestDto);
        } else {
            log.info("락 획득 실패");
            throw new RuntimeException("락을 얻을 수 없습니다.");
        }
    } catch (InterruptedException e) {
        throw new RuntimeException(e);
    } finally {
        if (isLocked) {
            lock.unlock();
        }
    }
}

• 직접 구현해야 했던 Lettuce 방식 대신, Redisson 방식은 라이브러리이기에, 미리 구현된 객체를 넣고, tryLock만 넣어주면 끝납니다. 간편하죠?

불편한데요?

• 사실 그렇습니다. 위 코드의 문제점은 동시성 제어가 필요한 모든 코드에 저 메소드를 집어넣어 로직을 수정해야 한다는 겁니다.
• 분명히 간편하라고 만든 라이브러리인데...기존 방식보다 더 불편해진 모습입니다.
• 그렇기 위해 저희는 @Transactional처럼, 어노테이션만 추가함으로써 적용되는 방식을 생각해야 합니다.

AOP로 구현하기

공통 기능으로 만드는게 좋지 않을까?

• 답은, 위의 tryLock과 괄호 안 구성들을 공통 기능으로 만들어, 어노테이션으로 필요한 메소드에 적용하는 방식입니다.
• 답을 찾았으니, 구현을 시작해봅시다.

RedissonLock

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface RedissonLock {
    String value();
    long waitTime() default 5000L; // Lock 획득을 시도하는 최대 시간 (ms)
    long leaseTime() default 3000L; // 락을 획득한 후, 점유하는 최대 시간
}

• 기존의 tryLock() 메소드를 어노테이션으로 치환하였습니다.

RedissonLockAspect

@Slf4j
@Aspect
@Component
@RequiredArgsConstructor
public class RedissonLockAspect {
    private final RedissonClient redissonClient;
    private final TransactionAspect transactionAspect;

    @Around("@annotation(RedissonLock)")
    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("{} : 락 획득 실패", lockKey);
                throw new IllegalArgumentException();
            }
            log.info("{} : 로직 수행", lockKey);
            return transactionAspect.proceed(joinPoint);
        } catch (InterruptedException e){
            log.error("{} : 락 에러 발생", lockKey);
            throw e;
        } finally {
            log.info("{} : 락 해제", lockKey);
            // lock 객체가 제대로 생성되었을 경우에만 unlock
            if(lock != null && lock.isHeldByCurrentThread()) lock.unlock();
        }
    }
}

• Lock 획득 시도, Lock 획득 성공 후 처리, Lock 획득 실패 시 로직을 구현한 Aspect입니다.
• 즉, @RedissonLock 어노테이션이 메소드에 적용되면 위 기능이 동작하게 됩니다.
• 참고로, 재시도 로직은 Redisson에서 알아서 처리하기에 구현할 필요는 없습니다.
• TransactionAspect라는 클래스가 보일 텐데 밑에서 바로 설명합니다.

TransactionAspect

@Component
public class TransactionAspect {
    // leaseTime 보다 트랜잭션 타임아웃을 작게 설정
    // leaseTimeOut 발생 전에 rollback 시키기 위함
    @Transactional(propagation = Propagation.REQUIRES_NEW, timeout = 2)
    public Object proceed(final ProceedingJoinPoint joinPoint) throws Throwable {
        return joinPoint.proceed();
    }
}

• AOP에서 트랜잭션 분리를 위한 클래스입니다.
• @RedissonLock이 적용된 메소드일 경우 Propagation.REQUIRES_NEW 옵션을 지정해 부모 트랜잭션의 유무에 관계없이 별도의 트랜잭션으로 동작하고, 트랜젝션 커밋 이후 락이 해제되도록 설정해야 합니다.
• 하지 않을 경우 분산 락 트랜젝션이 부모와 동일한 트랜젝션에서 수행되면 부모 트랜젝션 종료 시점에 커밋 시점이 됩니다.
• 그러면 락은 해제되어도 커밋은 되지 않았기 때문에, 다른 스레드에서는 락을 획득할 수 있지만 변경 전의 데이터를 보게 됩니다.
• 즉, 동시성 환경에서 데이터 정합성이 보장되지 않는 문제가 발생합니다.
• 그렇기에 데이터 정합성 보장을 위해서는 락의 해제가 트랜잭션 커밋보다 뒤에 이뤄져야 합니다.
• 이를 위해 joinPoint를 넘겨 받아 새 트랜젝션에서 수행 시키는 TransactionAspect 클래스를 정의합니다.

기존 메소드에 적용

@RedissonLock(value = "#meetingUuid")
    public ScheduleAssignResponseDto assignScheduleToGuest(String meetingUuid, ScheduleAssignRequestDto requestDto) {
        // 이미 모임의 인원이 다 찼는가? (400 Bad Request)
        if (meetingRepository.checkMeetingFull(meetingUuid)) {
            throw new MeetingFullException();
        }

        // meetingId로 할당되지 않은 schedule 조회
        Schedule schedule = scheduleRepository.findNotAssignedScheduleByMeetingUuid(meetingUuid)
                .orElseThrow(ScheduleNotFoundException::new);

        // 모임의 일정 마감시간 이후 요청일 경우 예외 처리
        LocalDateTime now = checkMeetingEnded(schedule.getMeeting());

        schedule.changeAssignedAt(now);
        validateAndAssignSchedule(requestDto, schedule);

        return ScheduleAssignResponseDto.builder()
                .scheduleUuid(schedule.getScheduleUuid())
                .build();
    }

• @Transactional을 제거하고, 저희가 만들었던 @RedissonLock(value = "#적용할 파라미터 이름")을 메소드에 적용합니다.

테스트 결과

제한 인원이 5명인 모임을 생성합니다.

한번에 200명이 요청하는 시나리오를 만듭니다.

결과

• 5번의 요청만이 승인되는 모습을 볼 수 있습니다.

• 추가적으로, 실패한 요청들도 데드락으로 인해 발생하는 서버 에러인 500이 아닌, 생각하던 로직 그대로 400이 발생하는 것을 볼 수 있습니다.

참고

• 풀필먼트 입고 서비스팀에서 분산락을 사용하는 방법
• SpringBoot Redisson AOP 적용기 - 재고 동시성 제어
• Redis(Redisson) 분산락을 활용하여 동시성 문제 해결하기

[f1v3-dev]

@transactional - timeout

제가 조금 찾아보니까 해당 어노테이션에 timeout 을 설정하는 것은
그 시간 내에 커밋이 되는 것을 보장해주는 것으로 보여요.

해당 시간이 지날 때 까지 로직이 수행이 되지 않는다면 그 즉시, 롤백을 진행한다고 하네요?

더 나아가서 궁금한게 많은데, MySQL 의 기본 격리 수준이 REPEATABLE READ 인데 다른 트랜잭션에서 접근해서 변경된 데이터에 접근한다는게 될까 싶기도 해요

궁금한 내용

• 전파 옵션을 REQUIRES_NEW 를 통해 트랜잭션 분리로 얻는 이득은 무엇일까? (예상: 락을 거는 트랜잭션은 별도 관리)
• timeout 이후에 롤백이 되는데, 이게 락을 해제하는 시간보다 더 길어질 수 있을까?

등등 ,,