[선착순이벤트] 선착순 이벤트 Redis vs 비관적락 성능 비교와 고가용성 측면 비교

선착순 이벤트 기능을 구현하면서, 대규모 트래픽 환경에서도 정확성과 성능을 동시에 만족하는 구조 설계하기 위해 두 방식의ㅜ특징을 정리해보고 성능을 비교해보고 고가용성 측면에서 테스트를 진행해보았습니다.

 

 

락 특징 정리

Redis 도입 장점 

 

확장 가능한 시스템을 위해 Redis 도입

비관적 락 방식은 DB 자체의 락을 활용하는 방식으로 하나의 트랜잭션이 데이터에 접근할 때 락을 걸고 트랜잭션 작업이 완료된 후 락을 해제하여 현재 작업을 하는 동안은 다른 트랜잭션이 접근하지 못하게 하는 방법입니다. 이 방법은 DB가 하나일 때는 문제가 없지만 확장성 측면에서 문제가 있습니다. 만약 DB가 병목 지점으로 판단되어 여러 대의 DB를 두어 이 문제를 해결하려고 할 때 DB의 락을 활용하는 방식은 분산되어 있는 DB의 데이터를 동기화하는 새로운 문제가 생길 수 있습니다.

 

DB 뿐 아니라 대량의 트래픽에 대한 처리량을 늘이기 위해 WAS를 Scale Out할 수 있는데 이때 DB가 하나라면 DB가 단일 장애지점 및 병목이 될 수 있어 WAS의 확장 효과를 누리지 못하는 문제가 있습니다.

또, 많은 이벤트 참여 요청이 DB 커넥션을 점유하여 이벤트 참여 요청이 아닌 일반 상품 조회 등의 API가 DB 커넥션을 사용하기 어려워 지연시간이 느려질 수 있는 문제가 있습니다.

 

이러한 문제를 해결하기 위해 실무에서는 Redis를 이용해 분산락을 적용하고 확장가능한 시스템을 구현할 수 있습니다. Redis를 WAS와 DB 사이에 두어 이벤트 참여 요청에 대해 Redis가 DB 접근 여부를 통제하여, DB 커넥션 사용량을 제어하고 데이터의 정합성도 보장할 수 있습니다.

 

 

성능 비교

Redis와 비관적락 성능 비교

 

 

 

 

고가용성 측면 비교

선착순 이벤트 기능이 다른 API에 비치는 영향 측정. 서비스는 선착순 이벤트 기능만 동작하지 않기 때문에 선착순 이벤트 기능이 다른 서비스에 영향을 많이 미친다면 선착순 이벤트를 위한 성능을 개선해도 전체적인 시스템의 입장에서는 부정적인 영향을 줄 수 있습니다.

그래서 선착순 이벤트 기능과 상품 조회 API를 동시에 부하테스트를 하면서 처리량과 지연시간을 테스트 해보고, 운영 모니터링을 통해 사용중인 쓰레드를 비교해 보았습니다. 

 

테스트 상황

 

 

 

락 설정 코드 이유

 

java

lock.tryLock(5, -1, TimeUnit.SECONDS);  // Watchdog ON

장점:

• ✅ 트랜잭션 중 락이 절대 해제되지 않음 (Watchdog이 자동 연장)
• ✅ 데이터 정합성 보장
• ✅ 동시성 제어 완벽

단점:

• ⚠️ Watchdog 스레드 오버헤드 (약간의 CPU 사용)