[싹틔움] 11/14 개발일지 쿠폰 발급 시 동시성 문제 해결 2 : 비관적 락, 분산 락 ( Redisson ), Redis, Lua Script 적용 및 의사결정

💡 이전 글

https://hanstory33.tistory.com/262

[싹틔움] 11/13 개발일지 쿠폰 발급 시 동시성 문제 해결 1 : 동시성 문제 발생 및 낙관적, 비관적,

 

💡 목표

비관적 락과 분산 캐시 시스템인 Redisson 을 이용한 분산락을 걸어 기존에 락을 걸지 않았던 방식과 비교해 Test 를 진행.

 

+ python script 를 활용해 총 발급된 쿠폰 수와 중복된 쿠폰 코드를 확인

 

📝 Test : DB 낙관적 락 ( Skip )

매 발급 마다 쿠폰의 상태를 변경해야하는 지금 상황에서는 충돌 발생 시 매 번 재시도를 해야하는 낙관적 락은 적합하지 않다고 판단

 

📝 Test : DB 비관적 락

- 강력한 락을 걸기 위해서 성능상 손해를 보더라도 비관적 락을 통해 테스트 진행

• Number of Threads (users) : 1000
• Ramp-up period (seconds) : 5
• Loop Count : 1
• 발급한 유효 쿠폰 수 : 300
• 실제 쿠폰을 발급받은 유저 수 : 300

@Lock(LockModeType.PESSIMISTIC_WRITE)

 

300 개의 쿠폰이 발급된 것으로 보아 동시성 문제가 해결된 것을 볼 수 있다.

 

 

평균 응답 속도 1609 ms 가 나왔고,  초당 처리수은 174.7 건으로 안정적인 값이 나왔다.

 

📚 결론

기존에 락을 걸기 전에 평균 응답 속도가 171 ms 였던 것에 비해 평균 응답속도가 1609 ms 성능적으로 약 841% 감소됐지만, 동시성 문제는 확실하게 해결된 것을 알 수 있었다.

---

📝 Test : 분산 락 - Redisson

- 기존 CouponService 트랜잭션을 CouponLockService 로 Rapping 해서 Redisson 을 활용해 락을 만들고 해제했다.

- 동시성을 보장하기 위해서 락 획득 시도 시간과 락 유지 시간을 지정해줬다.

- 시간을 지정하다보니 성능적으로 어느 정도 손해를 볼 수 밖에 없었다.

- 내 컴퓨터로 테스트를 했을 때 동시성 문제를 해결하면서 처리할 수 있는 최소 시간 설정이었다. 

// 락 획득 시도 시간 2초, 락 유지 시간 3초
boolean isLocked = lock.tryLock(2, 3, TimeUnit.SECONDS);

 

• Number of Threads (users) : 1000
• Ramp-up period (seconds) : 5
• Loop Count : 1
• 발급한 유효 쿠폰 수 : 300
• 실제 쿠폰을 발급받은 유저 수 : 300

📚 결론

Redisson 을 활용해 분산 락을 테스트 해보았는데, 동시성 문제를 해결하기 위해 락 획득 시도 시간과 락 유지 시간을 설정하는 과정에서 컴퓨터 성능 이슈로 과하게 설정이 된 것으로 보인다.

그 때문에 평균 응답속도가 2870 ms 라는 다소 아쉬운 결과가 나왔다.

Redis 환경에서 데이터가 주고 받아지기 때문에 더 빠른 결과가 나왔어야한다고 생각한다.

이후 추가로 이 과정을 더 테스트 해볼 예정이다.

---

📝 Test : Redis 적용 (락X)

- 락을 걸면 성능이 많이 안 좋아져서 락을 걸지 않고 Redis 를 사용하는 방법으로 테스트 해보았다.
- Redis 는 싱글 스레드 모델로 동작하기 때문에 여러 요청이 동시에 오더라도 각 요청이 순차적으로 처리될 것이라 예상하고 Redis 로만 테스트 진행했다.

• Number of Threads (users) : 1000
• Ramp-up period (seconds) : 5 / 10 / 15 / 20
• Loop Count : 1
• 발급한 유효 쿠폰 수 : 300
• 실제 쿠폰을 발급받은 유저 수 : 440 / 400 / 320 / 305

기존과 동일하게 1000 명의 유저가 5초 동안 요청을 보내도록 하니까 동시성 문제가 심하게 발생했다.

 

원인 분석 : 원자성 보장 부족

Redis는 기본적으로 명령어가 원자적으로 처리되지만, 복잡한 트랜잭션이나 다수의 명령어가 결합된 작업에 대해서는 원자성이 보장되지 않는다.

 

• 쿠폰의 잉여 수량을 확인.
• 수량이 남아있으면 쿠폰을 발급.
• 발급된 쿠폰 수량을 업데이트

현재 위와 같은 로직으로 중복 발급이 발생할 수 있다.

 

위 그래프를 보다시피 1000명의 유저가 20 초 동안 300개의 쿠폰발급을 시도한다고 가정했을 때 부터 동시성 문제가 거의 해결되었다.

📚 결론

redis 를 활용해 평균 응답속도가 8ms 로 대폭 상승했다.

성능적인 부분에서 기존 락을 걸었을 때 보다 Redis 만 사용했을 때 월등히 증가했는데, 동시성 문제 부분에서 높은 처리량을 보여주지는 못했다.

---

📝 Test : Lua Script 적용

- Redis 의 Lua Script 를 사용하면 여러 명령을 하나의 원자적 작업으로 묶어 실행할 수 있기 때문에 쿠폰 발급 메서드에서 실행되는 코드들을 Lua Script 를 작성하여 트랜잭션처럼 처리할 수 있다.

- Lua Script 를 사용해 Redis 의 성능적인 이점과 동시성 문제를 둘 다 해결할 수 있을 것이라 예상되어 테스트를 진행했다.

 

• Number of Threads (users) : 1000
• Ramp-up period (seconds) : 5
• Loop Count : 1
• 발급한 유효 쿠폰 수 : 300
• 실제 쿠폰을 발급받은 유저 수 : 300

단일 쿠폰 발급 요청 테스트 13 ms

평균 응답속도 16 ms

발급된 쿠폰이 300개임을 확인할 수 있는 redis insight

📚 결론

Redis의 Lua 스크립트를 활용한 결과, 평균 응답 속도가 16ms에 도달하여, Redis의 기본 사용에서 확인된 성능과 거의 동일한 높은 퍼포먼스를 유지했다.

이는 단순히 성능 향상에 그치지 않고, 동시성 문제까지 완벽하게 해결했다.

Redis Lua 스크립트를 활용해 효율적인 처리 속도를 제공할 뿐 아니라, 여러 요청이 몰릴 때도 안정적인 성능을 유지할 수 있도록 동시성 관리를 강화했다.

이를 통해 Redis는 대규모 트래픽 환경에서도 높은 처리량과 안정성을 보장하며, 특히 미션 크리티컬한 애플리케이션에서도 확실한 신뢰성을 제공한다.

---

💡 최종 의사 결정

• 그래프로 확인할 수 있듯이 동시성 문제를 완벽하게 해결한 세 가지 방법은 DB 비관적 락, Redisson을 활용한 분산 락, 그리고 Lua Script 활용이다.
• 이 중에서 Lua Script를 활용한 방식이 동시성 문제를 해결하면서도 가장 빠른 응답 속도를 보였기 때문에 가장 이상적이라고 할 수 있다.
• 실제로, 비관적 락 방식에서 1609ms의 응답 시간이 소요되었던 것에 비해,  Lua Script를 활용한 후에는 16ms로 성능이 대폭 향상되었다.