🚀선착순 쿠폰 발급 시스템 - 5

---

배경

• 옛날에 24년 말에 쿠폰 발급 시스템을 만들었었는데 그 때 당시에는 나름 고민해서 구현했다고 생각했는데 다시 내가 한 내용들 정리하다보니 어우 너무 부족한 점도 많고 가장 중요한 부분인
  1. 왜 이런 문제가 있고
  2. 어떤 선택지를 왜?
  3. 실제 어떤걸 했고 트레이드 오프를 관리했는가?
  4. 어떤 지표로 검증했는가? -> 이런 것들이 자세하게 있지 않았던것 같다는 생각이 들었다. 예를 들어서 Redis를 도입한 이유가 이전 포스트를 보면 이런이런 장점이 있어서 썼어요라는 단순 결과 중심이라서 왜 썼어요에 대한 정확한 의도나 스토리가 없었던것 같다 정확한 지표나 데이터 없이
• 그래서 쿠폰 시스템 기존 코드들을 다시 읽어보면서 문제점이 있으면 수정을 하고
• 정확한 지표를 통해서 문제해결 과정을 자세히 경험해볼 생각이다.

---

순서

1. DB만 썼을 때 정합성과 응답시간과 처리량 측정
   • 이 단계를 통해서 Redis 없이 어디까지 버티는가?를 측정하고 Redis를 도입할 수 밖에 없었던 타당성을 만드는것을 목표로 한다.
2. Redis 전략 적용 + 분산락 버그 해결
   • 이 단계를 통해서는 Redis 도입을 했을때 새로운 동시성 문제를 발견해보고 해결까지 해보면서 어떤 부분을 고려해야했고 어떻게 해결했는지에 대한 것을 목표로 한다.
3. Redis를 도입했을 때 어떤 개선점이 있는지 측정
   • 이 단계를 통해서 응답시간 처리량 등이 어느정도 개선되었는지 최대 한계까지 부하테스트 시나리오를 진행해보는 것을 목표로 한다.
4. 순서 보장 문제 해결
   • 현재 구조의 한계인 순서 보장이 안될수 있는 가능성을 이전 부하테스트 단계에서 포착을 하여 어떤식으로 개선해볼 수있을지 해결책을 찾아보고 개선해본다
5. 최종 부하 테스트를 진행
   • 구조적 한계를 개선한 후 부하테스트 시나리오를 진행해보는 것을 목표로 한다.
6. Redis의 다양한 아키텍쳐
   • 단일 인스턴스 구조인 Redis 아키텍쳐를 다양한 시나리오에서 어떤 아키텍쳐를 도입해볼 수 있을지 고민 + 적용 해보는 것을 목표로한다
   • 가능하면 직접 환경 구축을 해봐서 테스트도 진행해본다

---

Phase 1 : DB만 썼을 때 정합성과 응답시간과 처리량 측정

흐름

• 이전 블로그에서 설명했지만
• DB의 PESSIMISTIC_WRITE만 적용해서(배타락) 다음과 같은 흐름으로 처리가 되는 형태

  1 2 3 4 5 6 7 8 9 10 11 12

  [요청 A, B, C 동시 진입] | 1. findByCodeAndIsDeletedFalse() → SELECT ... FOR UPDATE 실행 → A가 먼저 락 획득, B·C는 대기 | 2. coupon.issue() → remainStock-- (A 처리) → 트랜잭션 커밋 → 락 해제 | 3. B가 락 획득 → remainStock-- (B 처리) 4. C가 락 획득 → remainStock-- (C 처리)

• 이전 블로그에서는 한계를 그냥 이론적인 어떤 가능성 수준에서 처리를 했다면 실제 부하 테스트를 진행해보고 어떤 한계가 있는지 알아보자

  부하 테스트 시나리오

조건

1. 일단 선착순 쿠폰 발급 부하 테스트이기 때문에 사용자가 초반에 확 몰리고 몇초동안 트래픽이 유지되는 형태일것이라고 생각을 했다.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

VUs 100 | ┌──────────────────────────────┐ | / │ | / │ | / │ | / │ | / │ | / │ 0 |/_____________________________________|\ 0s 3s 33s 38s 구간 설명 - 0s ~ 3s : [오픈 직후 폭발적 유입 구간] 0 → VUS 까지 급격 램프업 - 3s ~ 33s : [경쟁 구간 / DB 포화 측정] VUS 유지 - 33s ~ 38s : [램프다운] VUS → 0

1. 쿠폰 재고는 10,000개로 고정을 했다. VU(50->100->200->500->1000)를 점진적으로 늘리면서 측정을 진행했다(여기서 VU는 동시 요청 수준으로 생각한다)
2. 0~38초동안 동시에 VU 수준의 요청이 계속 발생하고 이 과정에서 서로 다른 유저들이 계속 유입되며 경쟁하고 그중 쿠폰 재고만큼만 성공해서 재고가 소진된다.
3. HikariCP max-pool-size : 10, connection-timeout : 5000ms
4. MySql max-connections : 200
5. Tomcat 스레드 풀 : 200

시나리오 : DB 절대 처리량 한계

예상

HikariCP max=10 기준:

• 트랜잭션 1건 처리 시간 ~50ms → 이론 한계: 10 / 0.05 = 200 TPS
• VU=100~200에서 pending 커넥션 발생 예상
• VU=500+ 에서 connection-timeout(5000ms) 도달로 5xx 에러 급증 예상

결과

재고를 충분히 크게 고정하여 DB가 계속 쓰기 부하를 받도록 하고. VU를 단계적으로 올려 HikariCP 포화 지점을 찾는다.

VU	TPS	p50(ms)	p95(ms)	p99(ms)	에러율	발급수
50	519	79.61	115.76	136.69	0.00%	10,000
100	580	130.42	156.92	166.98	0.00%	10,000
200	590	254.85	317.59	335.34	0.00%	10,000
500	590	573.21	1,040	1,370	0.00%	10,000
1000	591	1,150	1,760	2,110	0.00%	10,000

• 지금 이 수치를 해석해보면
  1. VU 50 부터 100 200까지 TPS 증가하다가 그 이상의 VU에서는 더이상 TPS가 늘어나지 않는다 => 👌이 시스템의 DB 기반 처리 한계 = 590TPS
  2. Latency(지연시간)을 보면 TPS가 그대로인데 지연시간은 지속적으로 늘어난다 => 👌 DB가 더 못처리하는데 요청은 계속 들어오니까 요청들이 “대기열에 쌓이는 형태”
  3. 에러율이나 발급수를 보면 0.0%, 10,000개 => 👌시스템 장애는 발생하지 않았고 정상적으로 모든 재고가 소진되었다. 재고 이상의 요청 수는 정상적으로 비즈니스 실패로 처리되었다.

분석

포화지점: VU = 200

• VU 200 이후로는 TPS는 더이상 증가하지 않음 + 레이턴시만 선형 상승중 => 커넥션 풀 병목 패턴
• 커넥션 대기 큐에 쌓이 요청들이 응답 지연의 원인

결론

• TPS ≈ 동시처리 가능개수 / 트랜잭션 1건 처리 시간
  • HikariCP max = 10, 트랜잭션 1건 평균 약 ~17ms => 10 / 0.017 ≈ 이론적 최대 TPS 590 TPS

DB-only 구조는 정합성은 보장했지만, 모든 요청이 재고 확인과 차감을 위해 DB 커넥션 경쟁에 참여했다. 그래서 선착순 이벤트 처럼 짧은 시간에 트래픽이 집중되는 상황에서는 확장성이 낮았다. 실제 데이터에서 확인 할 수 있듯이 VU=200부터 HicariCP가 포화되어 TPS가 590 수준에서 고정되었고, 이후에는 처리량 증가 없이 지연만 증가했다.

DB-only 구조의 문제는 단순히 느린 것이 아니라, 모든 요청이 DB 커넥션을 점유해야만 성공/실패가 결정되는 구조이다. 즉 성공 가능성이 없는 요청까지 DB에 도달하면서 커넥션 풀을 경쟁 자원으로 만들어버린다..

따라서 선착순 이벤트에서 재고차감을 무거운 DB가 아니라 더 가벼운 인메모리 계층에서 먼저 처리해, DB 접근을 실제 성공 가능한 요청 수로 제한할 필요가 있음(DB에 도달하는 요청 수 자체를 줄이는것)

원자적 카운터 연산 + 분산 공유 상태 관리를 제공하는 Redis가 적합한 선택지라고 판단했다. 빠르기도 빠르지만 선착순 쿠폰은 “쿠폰 재고”를 관리하는게 매우 중요하기 때문에 원자적인 연산이 필요하다. 또 추후에 수평 확장까지 고려한다면 재고 상태를 공유할 수 있어서 선택을 하게 되었다.

---

Phase 2 : Redis 전략 적용 + 분산락 버그 해결