컬리, Redisson 기반 분산락으로 입고 서비스 동시성 문제 해결

컬리 풀필먼트 프로덕트 팀은 입고 서비스(RMS)에서 발생하는 동시성 문제를 해결하기 위해 Redisson 기반의 분산락을 도입했다. 카프카를 통한 중복 발주 수신이나 검수 시 더블 클릭, 이동 출고 시 다중 작업자의 동시 클릭 등으로 인해 잘못된 재고 트랜잭션이 생성되는 문제를 방지하기 위함이다.

기존 Application 예외 처리로는 멀티 인스턴스 환경에서 공통된 락을 적용할 수 없었으며, Redis를 선택한 이유는 팀 내 기존 기술 스택을 활용할 수 있고 MySQL 대비 커넥션 풀 관리 부담이 적어 RDS 부하를 줄일 수 있기 때문이다. 특히 Lettuce 대신 Redisson을 선택한 이유는 Lock 인터페이스 지원으로 타임아웃 설정이 용이하고, 스핀락 방식이 아닌 Pub/Sub 방식을 통해 락 해제 신호를 받아 Redis 부하를 최소화할 수 있기 때문이다.

분산락 컴포넌트 설계 및 구현

분산락 로직은 비즈니스 로직 오염을 방지하기 위해 AOP(Aspect-Oriented Programming) 기반으로 분리하여 구현했다. @DistributedLock 어노테이션을 통해 key, waitTime, leaseTime 등을 커스텀 지정할 수 있으며, **Spring Expression Language(SpEL)**을 활용해 동적으로 락 이름을 생성한다.

핵심적인 구현 포인트는 트랜잭션 커밋 이후 락 해제 처리다. AopForTransaction 클래스에 @Transactional(propagation = Propagation.REQUIRES_NEW)를 적용하여, 락 획득 후 실행되는 로직이 독립된 트랜잭션으로 동작하게 하고 트랜잭션 커밋이 완료된 후에 락을 해제하도록 설계했다. 이를 통해 락이 해제되었으나 데이터가 아직 DB에 반영되지 않아 발생하는 정합성 오류를 차단한다.

동시성 검증 테스트 결과

쿠폰 발급과 중복 발주 등록 시나리오를 통해 분산락의 효과를 검증했다. 쿠폰 100개를 100명의 고객이 동시에 발급 요청하는 테스트에서, 분산락을 적용하지 않은 경우 잔여 쿠폰이 79개로 데이터 정합성이 깨졌다. 반면 분산락을 적용한 경우 정확히 100개가 차감되어 잔여 0개를 기록하며 정상 처리됨을 확인했다.

또한 중복 발주 데이터 10개가 동시에 수신되는 시나리오에서도 분산락을 적용하면 existsByCode 검증을 통해 중복을 차단하고 단 1건만 등록되도록 보장했다. 이를 통해 입고 서비스의 데이터 정확성과 시스템 안정성을 크게 향상시켰다.