# 상품 재고 관리를 위한 분산 락 도입 ## 1. 배경 및 필요성 - 현재 이커머스 프로젝트에서는 상품 재고 관리에서 비관적 락을 사용하고 있다. - 그러나 비관적 락은 트랜잭션 격리 수준을 유지하고 동시성 문제를 완화하는 데 유리하나, 높은 트래픽과 경쟁 상황에서 성능 저하를 초래할 수 있다. - 이를 해결하고 시스템의 확장성을 높이기 위해 분산 락 도입을 고려하고 있으며, 특히 Redis 기반의 Lettuce와 Redisson 라이브러리의 사용을 검토하고 있다. ## 2. 분산 락 도입 시 고려 사항 - 분산 락은 여러 인스턴스 간의 락 관리를 가능하게 해 시스템 확장성과 성능을 동시에 개선할 수 있다. 다만, 효율적인 분산 락 구현을 위해서는 아래 사항들이 고려되어야 한다 - 일관성과 데이터 무결성: 락이 걸린 동안 동일한 자원에 대해 중복 처리가 발생하지 않도록 보장해야 한다. - 성능 및 지연 시간: 락 획득과 해제 시 빠른 성능을 보장해야 한다. - 분산 환경에서의 안정성 ## 3. Redis 기반 분산 락 구현 옵션 ### 3.1 Lettuce - 장점 - 분산락 기능을 제공하기 때문에 직접 구현할 필요가 없음 - 가벼운 라이브러리 - 단점 - spin lock 방식으로 lcok이 해제되었는지 주기적으로 retry 해야 해서 이 부분에서 부하가 커질 수 있다. ### 3.2 Redisson - 장점 - pub-sub 방식으로 lock이 해제되면 lock 해제를 기다리던 스레드들에게 알려주는 구조로 구현되어 있어 spin lock 방식과 비교해서 부하가 작음 - 단점 - Lettuce와 비교해서 무거운 라이브러리 - Lettuce와 비교해서 러닝 커브가 더 높다. ## 4. Lettuce / Redisson 선택 근거 - 재시도가 필요하지 않은 경우 Spring boot 에서 기본으로 사용하는 Lettuce를 사용하는 게 낫겠다. - 그러나 이커머스 재고 관리의 경우에는 아래의 이유로 재시도가 필요할 가능성이 크다. ### 1. 동시 접근 시 충돌 가능성 - 재고는 여러 사용자가 동시에 조회하고 업데이트할 수 있는 자원이므로, 락을 걸고 관리하는 상황이 자주 발생한다. 예를 들어, 두 명 이상의 사용자가 동시에 같은 상품을 구매하려고 시도하면 재고 차감 시점이 겹칠 수 있다. 이 경우 락을 걸어야 일관된 데이터를 유지할 수 있으며, 락을 획득하지 못한 스레드가 재시도하게 된다. ### 2. 빠른 응답을 요구하는 실시간 처리 - 이커머스 시스템에서 재고 차감은 빠르게 이루어져야 하며, 사용자 경험 측면에서도 딜레이를 최소화하는 것이 중요하다. 특히 많은 사용자가 같은 상품에 동시에 접근할 때는 재시도가 필요할 수 있다. 이때 Redisson의 pub-sub 방식은 락 해제를 기다리는 스레드들에게 알림을 줘 spin lock보다 부하가 적고 빠르게 처리할 수 있다. ### 3. 락 해제 후 안전한 재시도 - Lettuce의 경우 spin lock 방식으로 주기적으로 락 해제 상태를 확인하는데, 이는 재고 관리처럼 락 획득 요청이 많고 트래픽이 높은 상황에서는 부하가 커질 수 있다. 반면, Redisson은 락이 해제되면 대기 중인 스레드들에게 즉시 알림을 주므로 부하가 적고, 필요한 재시도에 안정적으로 대응할 수 있다. ## 5. 결론 재고 관리는 재시도가 필요한 상황이 빈번히 발생하므로, pub-sub 기반으로 부하가 적고 안정성이 높은 Redisson을 사용하는 것이 적합하다.