🚀AWS ECS Fargate를 활용한 할인 쿠폰 발급 시스템 - 3

---

2단계 : Redis 도입

이 전편에서 확인했던 것처럼 비관적 락의 한계는 분명히 존재했다. 이를 해결하기 위한 방법으로 나는 redis를 도입해보려고 한다.

Redis

레디스는 key, value 데이터 구조 저장소로 다양한 인메모리 데이터 구조 집합을 제공한다는 특징이 있다.

왜 Redis?

레디스를 선택한 이유는

1. 높은 성능 메모리이기 때문에 아주 빠른 응답 시간을 제공한다. 그래서 쿠폰 발행 같은 매우 빠른 요청을 처리해야 하는데 DB 디스크에서 락 획득 vs 메모리에서 락 획득/해제 처리 중 당연히 메모리에서 즉시 락 획득 하고 해제가 매우 빨라서 대기 시간 때문에 생길 수 있는 한계들을 최소화할 수 있다.
2. 분산 환경 지원 레디스는 Redisson같은 분산락을 구현하기 위한 구현체들을 제공하는데 이를 통해 분산 락을 안정적으로 구현해 놓았다.

   분산락(Distributed Lock) : 여러 서버나 프로세스가 공유 자원에 접근 할 때, 오직 하나의 서버나 프로세스만 해당 자원에 접근할 수 잇도록 제어하는 메커니즘

3. 유연한 락 관리 락의 획득 부터 락의 유효시간 지정이라든지 데드락 상황을 예방하기 위한 기능등을 제공한다.

우선 redis의 빠른 처리 속도와 DB 부하 감소를 하면서 효과적으로 동시성 처리를 하기 위해 Redis는 쿠폰의 재고 관리를 하는 소스로 사용하는 용도로 사용한다.

비관적 락만 사용했을 때와 Redis와 함께 사용했을때의 차이는

1. 처리 속도
   • 비관적 락 : 모든 요청이 DB락을 얻기 위해 대기해야한다.
   • Redis + DB : Redis에서 빠르게 재고 확인과 감소가 이루어지므로, 재고가 없는 경우 DB 트랜잭션 없이 즉시 실패 응답이 가능
2. 동시성 처리
   • 비관적 락 : DB 수준에서 순차적으로 처리된다
   • Redis + DB : Redis에서 먼저 빠른 재고 체크가 이루어져서, 실제 DB 트랜잭션이 필요한 요청만 DB에 도달한다
3. 리소스 사용
   • 비관적 락 : 모든 요청이 DB 커넥션을 필요로 한다.
   • Redis + DB : 레디스에서 걸러진 요청은 DB 커넥션을 사용하지 않는다

=> 결론적으로 Redis를 도입하므로써 불필요한 DB 커넥션을 크게 줄일 수 있고, 시스템의 전체적인 성능이 향상된다.

어떻게 Redis 적용?

1편에서 Redis 의존성 추가를 하고 설정 클래스까지 작성을 해봤다. 🚀AWS ECS Fargate를 활용한 할인 쿠폰 발급 시스템 - 1 | Sung Jae’s Blog

쿠폰 발급하는 시나리오를 정리해보자

1. 쿠폰 발급 요청
2. 중복 발급 검증
3. 쿠폰 발급을 위한 분산 lock획득
4. 재고 확인 및 처리
5. 쿠폰 발급 처리
6. 락 해제
7. 결과 반환 의 순서대로 쿠폰이 발급이 된다. 여기서 가장 핵심이 되는 부분은 3~6이라고 볼 수 있다. 3~5 각 단계는 어떤식으로 구현했는지 알아보자

쿠폰 발급을 위한 분산 lock획득

• acquireLock 메서드를 호출하여 Redis를 통해 분산 락을 획득한다.
• 만약 락 획득에 실패하면
  • 발급 이력이 기록되고
  • fail 응답을 반환한다.

락을 획득하면

재고 확인 및 처리

• Redis의 쿠폰 재고를 감소시킨다.
• 재고 감소에 실패한다면
  • 실패 카운트를 증가시키고
  • 실패 이력을 저장하고
  • fail 응답을 반환한다.

쿠폰 발급 처리

![[Pasted image 20241213155720.png]]

• Redis에서 재고를 감소시킨 후 실제 DB에서 실제로 쿠폰을 발급한다.
  • 데이터베이스의 쿠폰 상태를 변경하여 발급 가능한 상태를 감소한다.
  • 쿠폰 발급 기록을 저장한다

테스트

현재 아직 AWS에 서버를 배포한 상태가 아니기 때문에 러프하게 로컬에서 테스트를 진행 해봤다.

1. 동시성 제어가 잘되는지
2. Redis와 데이터베이스를 결합한 재고 처리가 정상적으로 처리 되는지 를 중점으로 테스트를 진행했다.

테스트는

• 쿠폰 10000개
• 총 요청 개수 1000번
• 동시 요청수 1000번

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

@Test void performanceTest() throws InterruptedException { // given ExecutorService executorService = Executors.newFixedThreadPool(THREAD_POOL_SIZE); CountDownLatch latch = new CountDownLatch(TOTAL_THREAD_COUNT); long currentTime = System.currentTimeMillis(); // when for (int i = 0; i < TOTAL_THREAD_COUNT; i++) { final long userId = i; // 변수 캡처를 위해 final로 선언 executorService.submit(() -> { try { CouponIssueRequest request = new CouponIssueRequest( code, userId, requestIp); couponService.issueCoupon(request); } catch (Exception e) { // 예외 발생 시 로깅 System.err.println("Error processing request: " + e.getMessage()); } finally { latch.countDown(); } }); } System.out.println("Total time: " + (System.currentTimeMillis() - currentTime) + "ms"); // then latch.await(); executorService.shutdown(); // 스레드 풀 정리 // 결과 검증 Coupon updatedCoupon = couponRepository.findByCode(code).orElseThrow(); int issuedCount = couponIssueRepository.countByCouponCode(code); assertThat(updatedCoupon.getRemainStock()).isEqualTo(Math.max((STOCK_COUNT - TOTAL_THREAD_COUNT), 0)); assertThat(issuedCount).isEqualTo(Math.min(STOCK_COUNT, TOTAL_THREAD_COUNT)); }

redis 재고도 정상적으로 1000개만 발급 되었다.

다음 편은 Redis에 대해 좀 더 심층적으로 공부한 내용들을 포스팅할 예정이다.