🎍

분산락으로 동시성 문제 해결하기(Redis, 네임드 락)

생성일

2023/03/23

태그

Redis

Spring

Transaction

Aop

MySQL

목차

배경

서비스를 개발하고 고도화가 진행되면 필연적으로 동시성 문제를 마주하게 되는데, 저희 모락도 예외는 아니었습니다. 기본적으로 웹 환경에서는 같은 시간에 여러 개의 요청이 들어올 수 있고, 스프링같은 멀티쓰레드 환경에서는 여러 쓰레드가 한 자원을 공유할 수 있어, 동시성 문제가 심할 때는 데드락이 발생할 수 있습니다. 저희 모락에서는 쿼리 성능을 위해 반정규화를 하여 업데이트를 하는 쿼리가 생겼고, 여러 쓰레드에서 한 레코드에 대해 공유락을 획득한 뒤 배타락 획득을 시도하여 데드락이 발생하였습니다. 이에 이전 게시물에서는 데드락 문제를 해결하기 위해 비관적 락, 낙관적 락 등에 대한 고민과 결론적으로 비즈니스 로직을 나눠 데드락을 회피하면서 문제를 해결하였습니다. 하지만 이렇게 비즈니스 로직으로도 완전하지 않을 수 있습니다. 지난 로직은 단순 데이터를 삽입하는 로직이었지만 선착순 투표와 같이 자원에 제한이 있을 때에는 정합성 문제가 여전히 발생할 수 있습니다. 그래서 동시성 문제를 조금 다른 방법으로 접근해보려고 합니다.

비즈니스 코드

선착순으로 약속잡기 선택을 10명만 할 수 있는 로직입니다.

public class AppointmentService {

		@Transactional
		public void selectAvailableTimesWithFirstCome(String teamCode, long memberId, String appointmentCode,
		                                                  List<AvailableTimeRequest> requests) {
	      Appointment appointment = findAppointmentInTeam(teamCode, appointmentCode);
	      if (appointment.isLimit()) {
	          return;
	      }
	      appointment.selectAvailableTimesWithFirstCome(
	              toStartDateTime(requests),
	              memberId);
	      appointmentRepository.updateSelectedCount(appointmentCode);
		}
}
Java
복사

@Entity
public class Appointment {

		// ... 
		private long selectedCount;
		private long limitCount;
		private Set<AvailableTime> availableTimes = new HashSet<>();
	
		public boolean isLimit() {
        return this.limitCount <= this.selectedCount;
	    }
	
		public void selectWithFirstCome(Set<LocalDateTime> localDateTimes, long memberId) {
        final List<AvailableTime> availableTimes = toAvailableTimes(localDateTimes, memberId);
        this.availableTimes.addAll(availableTimes);
	    }
}
Java
복사

위와 같은 코드에서 중요한 비즈니스 로직은 다음과 같습니다.

•

선착순 수(limitCount)를 보고 선착순 수가 다 찼는지 확인한다(isLimit()).

•

선착순 수가 아직 다 차지 않았다면 약속잡기 선택 인원을 추가한다(addAll()).

•

선택 인원을 +1한다(updateSelectedCount()).

이러한 로직에서 만약 100명의 멤버가 동시에 선택잡기를 요청한다면 결과가 어떻게 되는지 확인해보겠습니다.

테스트 코드

@Test
void 선착순_10명의_약속잡기에_100명이_동시에_선택한다() throws InterruptedException {
    ExecutorService executorService = Executors.newFixedThreadPool(100);
    CountDownLatch countDownLatch = new CountDownLatch(100);
    for (long i = 1; i < 101; i++) {
        long memberId = i;
        executorService.submit(() -> {
            try {
                appointmentService.selectAvailableTimesWithFirstCome(teamCode, memberId, appointmentCode, requests);
            } finally {
                countDownLatch.countDown();
            }
        });
    }
    countDownLatch.await();
    Appointment appointment = appointmentRepository.findByCode(appointmentCode).orElseThrow();
    assertThat(appointment.getSelectedCount()).isEqualTo(appointment.getLimitCount());
}
Java
복사

기존의 동시성을 회피하는 비즈니스 로직으로 진행했을 때, 결과를 한번 확인해 보겠습니다.

limitCount 는 10인데, 추가적으로 7개의 요청이 성공할 수 있었습니다. 이러한 문제가 발생한 이유는 무엇일까요?

조회하는 시점과 검증하는 시점에 시간적 차이가 있는 로직(Check-Then-Act 패턴)이기때문에 두 트랜잭션의 로직이 모두 성공하게 된 것입니다. 이러한 동시성 문제를 해결하기 위해 가장 먼저 생각난 방법은 비관락입니다. 조회하는 시점부터 배타락을 획득하기때문에 간단하게 동시성 문제를 해결할 수 있고, 앱 서버가 여러 대인 분산 환경에서도 적용이 가능합니다.

하지만 비관락은 해당 레코드에 락을 걸기때문에 다른 쓰레드는 배타락을 반납하는 동안 DB 서버 내부에서 계속 대기해야합니다. 무엇보다 선착순이 아닌 다른 로직에서 해당 레코드에 공유락 또는 배타락을 획득해야 하는 상황에서도 대기하기때문에 다른 로직에 영향을 줄 수 있다는 단점이 있습니다. 이에 따라 비관락은 사용하지 않기로 결정하였습니다.

분산락

기존의 방식이 아닌 새로운 방식으로 해결할 방식을 찾고 있었고, MySQL 8 교재를 공부하다가 분산락인 네임드락 을 알게 되었습니다. 그래서 분산락에 대해 조금 학습한 뒤 적용해 보고자 하였습니다.

분산 락은 DB에서 제공하는 락의 종류(공유락, 배타락, 레코드락 등)와는 개념적으로 다소 차이가 있습니다. DB에서 제공하는 락은 보통 레코드나 테이블과 같은 자원에 대해 락을 겁니다. 하지만 분산락에서는 로직, API 등과 같은 자원에 접근하려는 대상에 대해 락을 겁니다.

예를 들어, 압구정 현대 백화점의 나이키 매장에서 열 명만 입장이 가능한 제한이 있는 이벤트가 있다고 해보겠습니다. 기존의 비관락이라면 마지막 열 번째로 입장한 인원이 문을 잠그고 들어가, 안에서 인원이 문을 열고 나올 때까지 자원을 점유합니다. 그래서 이후에 도착한 인원은 문이 열릴 때까지 대기해야 합니다. 하지만 분산 락인 경우에는 문을 잠근다기 보다는 입장할 인원이 나이키 매장 이벤트를 위해 왔는지, 아니면 푸드코트 이용을 위해 왔는지 확인합니다. 그리고 푸드코트 이용자라면 그대로 들어가고, 나이키 매장 이벤트를 위해 왔다면 열 명이 이미 입장했는지 확인하는 검수자가 존재하고 이 검수자가 입장을 제한합니다.

‘검수자’로 활용되는 이러한 분산락으로는 MySQL의 네임드 락, Redis, Zookeeper 등이 있으며 이번 포스팅에서는 네임드 락과 Redis 를 적용해 보도록 하겠습니다.

네임드 락

가장 먼저 적용할 분산락은 MySQL 에서 지원하는 네임드 락입니다. select get_lock(key, time_out) 메서드를 통해 네임드 락을 이용할 수 있습니다. key 에 해당하는 인자는 앞서 예시에서 언급한 백화점에 이용하려는 목적과 같습니다. 그리고 time_out 은 대기할 최대 시간입니다. 락에 대한 정보는 검수자 역할을 하는 다른 테이블에 저장됩니다.

public interface AppointmentRepository extends Repository<Appointment, Long> {

		@Query(value = "select get_lock(:key, 1000)", nativeQuery = true)
    void getLock(String key);

    @Query(value = "select release_lock(:key)", nativeQuery = true)
    void releaseLock(String key);
}
Java
복사

네임드 락은 Spring Data JPA 나 JPQL 에서 지원하지 않기때문에 nativeQuery 로 직접 작성해야 합니다. 또한 nativeQuery 는 기본적으로 내부 트랜잭션을 이용하지 않습니다. 이에 따라 만약 트랜잭션이 필요하다면 @Transactional 어노테이션을 달아야 합니다. 하지만 락을 획득하고 해제하는 로직은 영속성을 이용할 이유가 없고, 이후의 비즈니스 로직과 같은 트랜잭션을 탈 필요가 없기때문에 여기서는 트랜잭션을 이용하지 않았습니다.

@Transactional
public void selectAvailableTimesWithFirstComeNamedLock(String teamCode, long memberId, String appointmentCode,
                                             List<AvailableTimeRequest> requests) {
    try {
        appointmentRepository.getLock(appointmentCode); // 획득!
        Appointment appointment = findAppointmentInTeam(teamCode, appointmentCode);
        if (appointment.isLimit()) {
            return null;
        }
        appointment.selectAvailableTimesWithFirstCome(
                toStartDateTime(requests),
                memberId,
                systemTime.now());
        appointmentRepository.updateSelectedCount(appointmentCode);
        return null;
    } finally {
        appointmentRepository.releaseLock(appointmentCode); // 해제!
    }
}
Java
복사

key 로는 약속잡기 코드를 넣어주어 해당 로직을 이용하는 약속잡기 코드가 같다면 대기하도록 하였습니다. 그리고 기존의 비즈니스 로직의 앞, 뒤에 네임드 락을 획득하고 해제하는 로직을 추가해 주었습니다. 이러한 획득/해제 로직을 통해 조회하기 전 락 획득을 하고 하나의 트랜잭션만 조회할 수 있도록 하였습니다. 그리고 테스트를 돌려 보면!

잘못 추가된 데이터의 수가 7개에서 1개로 줄어들긴 했지만 이번에도 테스트 통과에 실패합니다. 실패한 이유는 분산락 해제 시점과 @Transactional 을 이용한 트랜잭션 커밋 시점의 불일치 때문입니다.

스프링 AOP를 통해 선착순 메서드 시작하기 전과 끝나고 나서 트랜잭션을 처리하는 프록시가 동작하게 됩니다. 반면 락 획득과 해제는 선착순 메서드 내부에서 일어납니다. 이러한 이유로 트랜잭션 A 가 커밋되기 전 락 해제가 되고 이 락을 기다리던 트랜잭션 B 에서는 락을 바로 획득한 후 조회를 하기때문에 트랜잭션 A 가 커밋되기 이전의 값을 조회하게 된 것입니다. 그래서 락을 획득하고 해제하는 로직이 트랜잭션 범위의 밖에 있도록 facade 클래스를 만들어주도록 하겠습니다.

@Service
public class AppointmentFacade {

		public void selectAvailableTimesWithNamedLock(String teamCode, long memberId, String appointmentCode,
                                                  List<AvailableTimeRequest> requests) {
        try {
            appointmentRepository.getLock(teamCode);
            appointmentService.selectAvailableTimesWithFirstCome(teamCode, memberId, appointmentCode, requests);
        } finally {

            appointmentRepository.releaseLock(teamCode);
        }
    }
}
Java
복사

그리고 서비스 계층의 비즈니스 로직에서는 락을 획득하고 해제하는 로직을 제거하였습니다. 그리고 테스트 코드에서도 서비스 메서드 대신 Facade 클래스의 메서드로 테스트를 돌려 보면,

드디어 선착순 수에 맞게 데이터가 잘 삽입되었습니다!

네임드 락의 문제점

로직에 맞게 잘 삽입되고 DB 의 기능을 잘 이용하였지만, 네임드 락은 여전히 문제점을 안고 있습니다. 첫째로 일시적인 락에 대한 정보가 DB에 저장되고, 락을 획득하고 제거하는 쿼리가 매번 발생하여 DB에 불필요한 부하를 줄 수 있다고 생각했습니다. 둘째로 만약 facade 계층의 메서드에 로직이 추가되어 트랜잭션이 필요하다면, 서비스 계층의 비즈니스 로직에서는 새로운 트랜잭션을 위해 REQUIRES_NEW 가 필요합니다.

@Service
public class AppointmentFacade {

		@Transactional // 트랜잭션 생성
		public void selectAvailableTimesWithNamedLock() {
        try {
            appointmentRepository.getLock(teamCode);
            appointmentService.selectAvailableTimesWithFirstCome(teamCode, memberId, appointmentCode, requests);
						// 추가 로직
        } finally {

            appointmentRepository.releaseLock(teamCode);
        }
    }

@Service
public class AppointmentService {

		@Transactional(propagation = Propagation.REQUIRES_NEW) // requires new 추가
		public void selectAvailableTimesWithFirstCome() {
				// 비즈니스 로직 수행
		}
}
Java
복사

이러한 경우 동시에 10 개의 요청이 동시에 발생한다면 HikariCP Maximum Pool Size 로 인해 데드락이 발생합니다. HikariCP Maximum Pool Size 의 기본값은 10입니다. 분산락을 획득한 쓰레드가 requires new 를 만나 새로운 트랜잭션을 얻기 위해서는 커넥션을 새로 생성해야 합니다. 그리고 이 때 분산락을 획득하지 못한 쓰레드 9개는 이미 커넥션을 물고 락을 획득하기 위해 대기중입니다. 이 시점에서 이미 커넥션이 모두 찼기 때문에 분산락을 획득한 쓰레드는 새로 커넥션을 생성하지 못해 대기하게 되면서 데드락이 발생합니다. 이를 2개의 요청과 커넥션으로 단순화한다면 그림과 같습니다.

그렇다고 HikariCP Maximum Pool Size 를 늘린다면 놀고 있는 커넥션이 많게 되어 비효율적입니다. 이러한 이유들로 인해 네임드 락 대신 Redis 를 알아보았습니다.

레디스 분산락

Redis는 "키-값" 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 데이터베이스 관리 시스템입니다. 저장소, 캐시, 메세지 브로커 등으로 사용되며, 보통 메모리 캐싱 저장소로 활용됩니다.

Redis를 활용한 분산 락(Distributed Lock)을 활용하여 동시성을 제어할 수 있습니다. 기본적으로 디스크를 사용하는 DB보다 메모리를 사용하는 Redis가 더 빠르게 락을 획득 및 해제할 수 있고 휘발되기때문에, 앞서 언급드렸던 네임드 락이 가지는 첫번째 문제를 해결할 수 있습니다.

적용하기 전에 한 가지 고려해야 할 것이 있습니다. 자바의 Redis 클라이언트로는 Lettuce와 Redisson이 있는데 Spring Data Redis를 사용하면 기본적으로 지원하는 클라이언트는 Lettuce입니다.

하지만 Lettuce로 분산 락을 구현하려면 반드시 스핀 락의 형태로 구현해야 한다는 단점이 있습니다. 스핀 락은 락을 획득하기 위해 SETNX라는 명령어로 계속해서 Redis에 락 획득 요청을 보내야 하는 구조입니다. 때문에 필연적으로 Redis에 많은 부하를 가하게 됩니다. 이를 방지하기 위해 락 획득 요청 사이 사이마다 Thread.sleep을 통해 부하를 줄여줘야 하고, sleep 을 준다면 연속적인 락 해제/획득이 되지 않아 비효율적일 수 있습니다.

반면 Redisson을 이러한 문제를 가지지 않습니다. Redisson은 Lettuce처럼 스핀 락으로 락 획득 요청을 보내지 않고 메시지 브로커 기능을 통해 락을 획득하는 로직을 구현하고 있습니다. 만약 10개의 쓰레드 중 하나의 쓰레드가 락을 획득하면 대기하고 있는 9개의 쓰레드는 락 획득을 위해 특정 채널을 구독(subscribe)하고 있습니다. 그리고 락을 획득하고 있던 쓰레드의 로직이 완료되면 락을 해제합니다. 락이 해제되면 락이 해제되었다는 메시지를 대기 쓰레드들이 구독하고 있는 채널에 발행(publish)합니다. 이어서 대기 쓰레드 중 하나가 다시 락을 획득하고, 이 과정을 반복합니다. 이에 따라 Lettuce 대신, Redisson 을 활용하여 분산락을 구현하도록 하겠습니다.

Redisson을 사용하여 분산락 구현

우선 Redisson에 대한 의존성을 설정해주어야 합니다. 일반적으로 Redis를 사용할 때 많이 사용하는 Spring Data Redis는 기본 클라이언트로 Lettuce를 사용하기 때문에, Redisson은 추가적인 의존성이 필요합니다.

implementation 'org.redisson:redisson-spring-boot-starter:3.18.0'
Plain Text
복사

redisson-spring-boot-starter는 Spring Data Redis의 기능들을 포함하고 있기 때문에, 굳이 spring-boot-starter-data-redis를 implementation 할 필요가 없습니다.

Redisson에는 RLock이라는 객체가 존재합니다. 이 객체를 통해 락을 컨트롤할 수 있습니다.

@Service
@RequiredArgsConstructor
public class AppointmentFacade {

    private final RedissonClient redissonClient;

		public void selectAvailableTimesWithFirstComeRedis(String teamCode, long memberId, String appointmentCode,
                                                       List<AvailableTimeRequest> requests) {
        RLock lock = redissonClient.getLock(String.format("firstCome:%s", appointmentCode));
        try {
            if (!lock.tryLock(10, 1, TimeUnit.SECONDS)) {
                System.out.println("락 획득 대기 시간이 만료되었습니다.");
            }
            appointmentService.selectAvailableTimesWithFirstCome(teamCode, memberId, appointmentCode, requests);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        } finally {
            lock.unlock();
        }
    }
}
Java
복사

앞선 네임드 락 로직과 마찬가지로 서비스 계층 대신 facade 계층의 메서드에 락을 획득하고 해제하는 로직을 만들어 주었습니다. getLock 을 통해 획득할 락 키를 설정할 수 있고, RLock 의 tryLock 메서드로 락을 획득하거나 대기할 수 있습니다. 첫 번째 파라미터는 락 획득을 대기할 타임아웃이고, 두 번째 파라미터는 락이 만료되는 시간을 표현합니다. 앞서 언급한 네임드 락과 유사하기때문에 흐름 설명은 넘어가도록 하겠습니다. 그리고 바로 테스트를 돌려 보면!

테스트가 정상적으로 통과하는 것을 볼 수 있습니다. 하지만 개선할 부분을 조금 더 생각해볼 수 있습니다. 서비스가 확장되어 위의 분산 락을 지속적으로 추가해야 하는 경우에, facade 클래스의 중복 로직이 계속해서 추가적으로 생길 수 밖에 없습니다. 이러한 중복 로직을 개선하기 위해서 AOP를 적용해 보도록 하겠습니다.

Annotation 기반의 분산락 AOP 구현하기

facade 메서드 내의 분산락을 획득하고 해제하는 로직을 스프링 AOP를 사용하여 간단하게 어노테이션 기반으로 분산락을 적용할 수 있습니다. 분산락 적용 로직은@Transactional 의 흐름과 마찬가지로 비즈니스 로직 시작과 끝에 적용됩니다. 이와 같이 AOP 로 해당 로직을 구현하면 어노테이션만으로 간단하게 분산락을 적용할 수 있고, 반복 로직을 제거할 수 있다는 장점이 있습니다.

먼저 적용하려는 어노테이션을 만들어 보겠습니다.

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface DistributedLock {

    TimeUnit timeUnit() default TimeUnit.SECONDS;

    long waitTime() default 10L;

    long leaseTime() default 1L;
}
Java
복사

앞서 tryLock() 의 파라미터로 넣었던 값을 기본값으로 넣었고 사용하는 메서드에서 이 값을 바꿀 수 있도록 하였습니다.

@Component
@RequiredArgsConstructor
@Aspect
@Order(value = 1)
public class DistributedLockAspect {

    private final RedissonClient redissonClient;

    @Around("@annotation(com.morak.back.core.support.DistributedLock)")
    public Object lock(final ProceedingJoinPoint joinPoint) throws Throwable {
        String appointmentCode = (String) joinPoint.getArgs()[2];

        RLock lock = redissonClient.getLock(String.format("firstCome:%s", appointmentCode));

        MethodSignature signature = (MethodSignature) joinPoint.getSignature();
        Method method = signature.getMethod();
        DistributedLock lock = method.getAnnotation(DistributedLock.class);

        try {
            if (!rLock.tryLock(lock.waitTime(), lock.leaseTime(), lock.timeUnit())) {
                return false;
            }
            Object returnValue = joinPoint.proceed();
            rLock.unlock();
            return returnValue;
        } catch (final Exception e) {
            Thread.currentThread().interrupt();
            throw new InterruptedException();
        }
    }
}
Java
복사

@DistributedLock
public void selectAvailableTimesWithFirstCome() {
}
Java
복사

facade 에 있던 락 획득/해제 로직을 Aspect 내부로 옮겼습니다. 이외에도 호출된 메서드의 파라미터에서 key 로 사용할 약속잡기 코드를 가져오고, 어노테이션에 적용된 값을 가져와 함께 사용해 주었습니다.

여기서 중요한 부분은 @Order 부분인데요, 빈 등록하는 순서를 트랜잭션 인터셉터보다 먼저 등록되게 하여 @Transactional 에 의한 트랜잭션을 생성하고 커밋하는 로직보다 범위가 크게 만들어줘야합니다.

@Order 없이 빈을 등록하면 위의 이미지처럼 트랜잭션 인터셉터가 먼저 등록되어 트랜잭션이 열리고 나서 락을 획득합니다. 이러한 흐름은 앞서 언급한 문제인, 커밋 이전 분산락 해제 문제를 마주하기때문에 @Order 로 가장 먼저 빈 등록이 되게 설정하여야 합니다.

마무리

하나의 서버에서 발생하는 문제 뿐만 아니라, 여러 대의 서버인 분산 환경에서 발생할 수 있는 동시성 문제를 확인하고 이를 해결할 수 있는 방법으로 분산락을 적용해 보았습니다. 적용해본 분산락으로는 MySQL 의 네임드 락과 레디스의 메세지 브로커를 이용한 분산락입니다.

네임드 락의 장점으로는 추가적인 리소스가 필요하지 않습니다. 다른 소프트웨어를 사용하지 않고도 기존의 DB 인 MySQL 로 분산락을 구현할 수 있는 장점이 있습니다. 하지만 단점으로는 락에 대한 정보가 테이블에 따로 저장되어 무거워질 수 있고, 실제 DB 에 락으로 인한 커넥션 대기가 발생하기때문에 성능상 단점이 있습니다.

반면 레디스의 메세지 브로커를 이용한 분산락은 락에 대한 정보는 휘발성이 있고, 메모리에서 락을 획득하고 해제하기때문에 가볍다는 장점이 있습니다. 다만 새로운 기술을 위한 학습과 리소스가 필요로 하다는 단점이 있습니다. 하지만 레디스에 대한 기본적인 정보가 있다면 더욱 활용도가 큽니다. 레디스의 가장 잘 알려진 용도는 캐싱 서버입니다. 그래서 서비스가 확장되고 요청 수가 더욱 많아지면 select count 나 세션 정보를 레디스의 캐싱 서버로 이용할 수 있어 확장성에 더욱 용이합니다. 종합적으로 봤을 때, 비즈니스와 서버 자원의 가용성 등의 상황에 맞게 선택해서 사용해야 합니다.