비동기 구조 1단계: Redis Set 적용
앞서 Redis 도입을 위한 설계를 진행하였다. 이번 내용은 Redis를 활용하여 쿠폰 요청 처리 시스템(coupon-api)의 기능을 구현한다.
기능1: 쿠폰 발급 검증(CouponIssueRedisService.java)
•
Set 데이터 구조를 활용하여 쿠폰 발급 요청의 중복 여부와 발급 가능 수량을 검증한다.
•
Set은 중복 데이터를 허용하지 않으므로, 사용자 발급 요청을 자연스럽게 필터링할 수 있다.
•
이를 통해 중복 발급 방지와 총 발급 수량 관리를 효과적으로 처리할 수 있다.
기능2: 발급 요청 처리(AsyncCouponIssueServiceV1.java) - 비동기 구조
•
발급 가능 여부 검증
◦
사용자의 발급 요청에 대해 결과를 처리한다.
•
발급 성공 대상 저장
◦
Redis Set에 사용자 ID를 저장하여 중복 요청을 방지한다.
◦
쿠폰 ID와 사용자 ID를 JSON 형식으로 변환하여 Redis List에 저장한다. 이후 MySQL 트랜잭션과 연계(coupon-consumer)하여 발급 정보를 처리한다.
소스코드 구현
구조 및 구현
(공통)/coupon-BE/coupon-core/
└── src/main/java/com/example/couponcore/
├── repository/redis/
│ └── RedisRepository.java // Redis 명령어를 활용한 레포지토리
├── service/
│ ├── CouponIssueRedisService.java // 발급 수량 및 중복 검증 서비스
│ ├── AsyncCouponIssueServiceV1.java // 비동기 쿠폰 발급 요청 처리 서비스
└── util/
└── CouponRedisUtils.java // Redis 키 관리 유틸리티
테스트
└── src/test/java/com/example/couponcore/service/
├── CouponIssueRedisServiceTest.java // 발급 검증 로직 테스트
└── AsyncCouponIssueServiceV1Test.java // 비동기 요청 처리 로직 테스트
Java
복사
파일명 | 내용 |
RedisRepository.java | Redis 명령어를 활용해 중복 검증, 발급 요청 저장을 처리하는 레포지토리 |
CouponIssueRedisService.java | 쿠폰 발급 검증 로직 서비스 - 수량 및 중복 요청 검증 |
AsyncCouponIssueServiceV1.java | 발급 요청 처리 비동기 서비스 - 쿠폰 발급 요청 처리와 Redis 작업을 담당 |
CouponRedisUtils.java | Redis 키 관리를 위한 유틸리티 |
소스코드
RedisRepository.java
CouponIssueRedisService.java
AsyncCouponIssueServiceV1.java - 1차
AsyncCouponIssueServiceV1.java - 2차
CouponRedisUtils.java
CouponIssueRedisServiceTest.java
AsyncCouponIssueServiceV1Test.java
성능테스트
1단계: Redis set 적용 (v2.1.2)
버전 정보
버전 | 변경 사항 |
v2.1.1 | Redis Set 적용 |
v2.1.2 | Redis Set + Distributed 분산 락 추가 적용 |
테스트 결과
•
테스트 환경: Local 환경에서 성능 테스트 3회 실시, 평균 값 도출
소스코드
버전정보 | 인프라 환경 | 쿠폰 발급 수량 비교
(정상발급확인) | #Request | #Fails | Failures | Average
(ms) | RPS | MySQL
CPU(%) | Redis
CPU(%) |
v2.1.1 | localhost | 불일치 | 1074037 | 183 | 0.01% | 935.413 | 1069.73 | 167.0 | 9.71 |
v2.1.2 | localhost | 일치 | 330135 | 371 | 0.01% | 1699.80 | 582.55 | 95.11 | 20 |
v2.1.1 부하테스트 결과
v2.1.2 부하테스트 결과
테스트 결과 요약
•
v2.1.1 Redis Set만 적용:
◦
사용자 중복 방지와 발급 요청 저장은 가능했지만, 정상 발급 수량과 요청 수량의 불일치 발생
◦
평균 응답 시간: 935.413ms
◦
RPS(Requests Per Second): 1069.73
◦
MySQL CPU 사용률이 높은 상태(167.0%), Redis는 상대적으로 낮음(9.71%)
•
v2.1.2 Redis Set + Distributed Lock 적용:
◦
중복 요청 및 발급 수량 일관성을 유지하며, 정상 발급 확인
◦
평균 응답 시간: 1699.80ms로 증가했으나, 안정적인 처리
◦
RPS: 582.55로 감소했으나, MySQL CPU 부담이 크게 줄어듦(95.11%)
◦
Redis CPU 사용률은 증가(20.0%)했으나, 분산 락 처리로 인해 일관성 확보
결론
•
Redis를 활용한 쿠폰 발급 시스템은 효율적인 데이터 처리와 높은 신뢰성을 기반으로 설계되었으며, 비동기 로직과 분산 락을 통해 대규모 트래픽 환경에서도 안정적으로 동작할 수 있도록 구현되었다.
•
성능 테스트 결과, Redis Set만 적용한 초기 버전(v2.1.1)은 요청 처리량이 높았지만 발급 수량의 불일치 문제가 발생했다. 이후 Redis Set과 분산 락을 추가한 개선 버전(v2.1.2)에서는 발급 수량의 일관성을 확보하고 MySQL CPU 부하를 줄이는 데 성공했으나 RPS는 다소 감소하는 결과를 보였다.
•
향후 방향으로는 정적 데이터를 Redis Cache에 적용하여 데이터 접근 속도를 최적화하고, 락 범위를 최소화하거나 Redis 명령어를 최적화하여 요청 처리 속도를 더욱 높이는 방안을 고려하고 있다.
Q&A
List를 쓴 이유는?
Redis에서 키가 필요한 이유는?
Utils로 따로 뺀 이유는?
Related Posts
Search
