[TASK:1단계:1] 대규모 트래픽 선착순 시스템 한계(현재 구조에서의)

[oownahcohc]

현재 시스템의 병목 구간

현재 시스템은 "데이터 정합성"을 최우선으로 하여, RDBMS의 비관적 락에 의존함.
이에 따라 다음과 같은 문제가 발생함.

• 비관적 락의 한계
  • 모든 요청은 DB의 특정 Row 하나를 잡기 위해 대기함.
• Blocking I/O
  • 락을 획득할 때까지 스레드가 대기
  • 이는 DB Connection Pool 고갈 → 사용자 요청 스레드 대기 → 전체 시스템 처리량 저하 로 이어짐

발생 가능한 위험 시나리오

1. 재고 1만개, 유저 10만명 같은 상황 → 주문 예약 서비스가 DB 커넥션을 모두 점유

   • 현재 TPS 로는 품절까지 수 분 소요 예상.
   • 후순위 유저는 대기 시간이 상당히 늘어남.
   • 이에 따라 Timeout 발생 → 유저 이탈 등의 문제 발생
   • 연관 없는 기능들도 DB 접속 불가로 전체 서비스 마비 가능.

2. 유저의 새로고침 연타

   • 응답이 늦자 유저가 재요청(새로고침 or 주문 연타)
   • 기존 요청은 DB 락 대기 중이고, 신규 요청이 또 스레드를 점유함.

3. 빈 재고 조회하는 문제 (?)

   • 재고가 0 인 상황에도 비관적 락을 잡고 쿼리를 날리는 중.

참고

• Test/#16/k6 performance test : 선착순 재고 차감 주문 예약 생성 기능 성능 테스트 #18

[oownahcohc]

위험 시나리오별 대응

1. 재고 1만개, 유저 10만명 같은 상황 → 주문 예약 서비스가 DB 커넥션을 모두 점유

   • DB 락이 아닌 Redis 분산 락을 사용. 인메모리 이므로 락의 획득/릴리즈가 빠를 것으로 예상 (추가적인 공부 필요)

2. 유저의 새로고침 or 주문 연타

   • 멱등키를 헤더에 포함하도록 하여, 동일 유저의 중복 요청을 차단

3. 빈 재고 조회하는 문제 (재고 0일 때도 비관락으로 데이터 가져오므로)

   • "Redis 분산 락 + DB 낙관적 락" 조합으로 해결할 수 있을 것으로 예상 (비관적 락 제거)

의사 결정 정리 링크

대규모 트래픽 환경에서의 선착순 예매 시스템 : 동시성 제어 전략

[Byeongju-Kong]

redis를 도입하는건 좋은데, 동일한 형태의 tx에 대해 수십만의 요청이 들어올텐데,
하나의 요청이 tx를 처리하는 동안 다른 요청들은 tx를 대기해야할 것 같아요.
tx 전체에 락을 거는 것은 동일하고, lock을 어디에 거는 것만 달려졌어요.
결국 달라진건, 비관적 lock을 잡는데 드는 비용만 달라졌어요.

tx의 모든 행위에 락을 잡을 필요가 있을지 생각해보면 좋을 것 같아요.
우리가 lock을 잡는 이유는 재고를 atomic 하게 관리하기 위함입니다.

tx 전체에 lock을 잡아서 atomic하게 재고를 관리하는 것이 아니라,
재고만 atomic 하게 관리할 수 있는 방법을 생각해보면 좋을 것 같아요.

[oownahcohc]

넵 이해했습니다.

• lock 을 잡는 범위를 줄이고,
• 도입하고자 했던 redis 를 활용해서 재고 차감을 atomic 하게 관리하고
• 실제 DB 재고 차감 및 주문 생성은 기존 tx 를 사용해서 처리 (이때 DB 재고 차감에 select..for update 는 제거)
• DB tx 실패 시 redis 재고에 대한 보상 필요

위 방식처럼 Redis 를 1차 저장소 개념으로서 사용하게 되면, 말씀 주신 문제를 제일 간단하게 해결할 수 있을 것 같아요.

[ch0ijihwan]

위 방식처럼 Redis 를 1차 저장소 개념으로서 사용하게 되면, 말씀 주신 문제를 제일 간단하게 해결할 수 있을 것 같아요.

요 고민을 잘 남겨주시면 좋을 것 같습니다

[oownahcohc]

[공유] 대규모 트래픽 선착순 재고 시스템 성능 및 정합성 개선기

1. 문제 인식: RDBMS 비관적 락의 한계

• 현상: 데이터 정합성을 위해 SELECT ... FOR UPDATE를 사용했으나, **DB 커넥션 풀 고갈(Blocking I/O)**로 전체 시스템 마비.
• 문제점:
  • 재고가 없는 상황에서도 락 대기열 발생.
  • 주문뿐만 아니라 무관한 다른 서비스까지 영향이 전파될 가능성을 내포.
  • 단순 DB 락만으로는 수십만 건의 트래픽을 감당 불가하다고 판단.

2. 1차 시도: Redis 분산락 도입 (피드백 전)

• 접근: Redis 분산락 + DB 낙관적 락으로 DB 부하를 줄이려 함.
• 피드백: "Tx 전체에 락을 거는 건 비관적 락과 비용 차이만 있을 뿐 똑같다. 락의 범위를 '재고 차감' 단위로 줄여라."

3. 2차 시도: Redis Lua Script + JPA 조회 시 비관락 제거

• 설계:
  1. Redis: Lua Script로 원자적 재고 차감.
  2. DB: Select(조회) -> Logic(차감) -> Update(저장) 수행.
  3. 보상: DB 실패 시 Redis 재고 복구 (Increase).
• 결과 (실패): 갱신 손실 (Lost Update) 발생.
  • Redis는 1000명을 정확히 통과시켰으나, 그 1000명이 DB에 동시 접근하여 Select와 Update 사이의 시차로 인해 재고 정합성이 깨짐 (1000개 판매 후 DB 잔고 841개 등).
  • 충돌이 많을 것으로 예상해서 낙관락은 적용안하고 테스트 해봤음

4. 3차 시도 (해결): Redis + DB Direct Update

• 해결책: DB 로직을 Select 후 수정이 아닌, UPDATE stock SET qty = qty - 1 (Direct Update) 로 변경.
• 결과:
  • Redis: 앞단에서 트래픽을 방어하고 순서를 보장. → 재고 0 이후의 로직은 db 레벨로 넘어가지 않고 fail fast
  • DB: Update 쿼리의 **Row Lock(원자성)**을 이용해 남은 트래픽의 정합성 보장.
  • 성능 & 정합성 모두 확보.

5. 고민 지점

이 구조를 확정하면서 두 가지 본질적인 의문이 생김.

(1) Direct Update를 쓸 거면 Redis 가 굳이 필요한가?

• 의문: UPDATE ... SET qty = qty - 1은 그 자체로 정합성을 보장한다. Redis가 없어도 되는 것 아닌가?
• 결론: 정합성은 DB만으로 되지만, Fail Fast를 위해 Redis가 필요함. Redis 없이 DB에 수십만 트래픽이 UPDATE 락을 거는 상황을 보호.

(2) 비즈니스가 복잡해지면(3단계: Multi-Warehouse) 어떻게 할 것인가?

• 상황: "서울 창고 없으면 부산 창고 차감" 같은 조건부 로직은 Direct Update 쿼리 한 줄로 처리가 불가능함. 즉, 다시 selct → logic → update 가 필요함.
• 고민:
  • 다시 애플리케이션 레벨(Read-Modify-Write)로 돌아가면 동시성 문제가 재발함.
  • 해결할 수 있는 방법으로, Redis Lua Script에 분기 로직(비즈니스 로직)을 넣어서 원자적으로 처리해야 하는 방법을 떠올림.
  • 그렇다면 "과연 비즈니스 핵심 로직을 인프라 성격이 강한 Lua Script(Redis)에 두는 것이 옳은가?"
  • Redis 의 재고가 0이 된 이후의 로직이 DB 로 넘어가지 않도록 Fail Fast 적용하고 + 기존 DB 비관락 적용해도 되나?

[ch0ijihwan]

Redis: 앞단에서 트래픽을 방어하고 순서를 보장. → 재고 0 이후의 로직은 db 레벨로 넘어가지 않고 fail fast

이 부분 쫌만 자세히
설명 가능하실까요??

잘 이해가 안되네여

레디스에서 재고가 있으면 db를 타는건가여?

없으면 db를 안타고

[oownahcohc]

3. 2차 시도: Redis Lua Script + JPA 조회 시 비관락 제거

• 설계:

  1. Redis: Lua Script로 원자적 재고 차감.
  2. DB: Select(조회) -> Logic(차감) -> Update(저장) 수행.
  3. 보상: DB 실패 시 Redis 재고 복구 (Increase).

• 결과 (실패): 갱신 손실 (Lost Update) 발생.

  • Redis는 1000명을 정확히 통과시켰으나, 그 1000명이 DB에 동시 접근하여 Select와 Update 사이의 시차로 인해 재고 정합성이 깨짐 (1000개 판매 후 DB 잔고 841개 등).
  • 충돌이 많을 것으로 예상해서 낙관락은 적용안하고 테스트 해봤음

위 흐름에서, 1번 lua script 를 아래와 같이 작성했어요.

-- KEYS[1]: 재고 Key
-- ARGV[1]: 차감할 수량

local current_stock = redis.call('get', KEYS[1])
local current_stock_val = tonumber(current_stock)

-- 재고가 없거나 0보다 작거나 같으면 실패(-1) 반환
if not current_stock or current_stock_val <= 0 then
    return -1
end

if current_stock_val - tonumber(ARGV[1]) < 0 then
    return -1
end

-- 재고가 있으면 차감하고 남은 재고 반환
return redis.call('DECRBY', KEYS[1], ARGV[1])

만약 여기서 재고가 없거나 0보다 작거나 같으면 실패(-1) 반환 되는 경우,
2. **DB:** Select(조회) -> Logic(차감) -> Update(저장) 수행. 으로 넘어가지 않고 바로 exception 을 발생시키는 흐름으로 구성해서

Redis: 앞단에서 트래픽을 방어하고 순서를 보장. → 재고 0 이후의 로직은 db 레벨로 넘어가지 않고 fail fast

라고 설명했습니다.

[oownahcohc]

문제 해결 방향: Eventual Consistency

• 핵심 전략: Redis를 1차 저장소로 보고, DB 업데이트는 후속 처리하여 궁극적 일관성(Eventual Consistency)을 지키도록 함

• 프로세스:

  1. Redis: Lua Script로 원자적 재고 차감 (성공 시 주문 진행). << Lua Script 굳이 사용해야 하는지 판단 필요
  2. DB (Order): 주문 내역 INSERT (성공 시 클라이언트 응답).
  3. 궁극적 일관성(Eventual Consistency) 을 어떤 방법으로 보장해줄 것인지에 대한 판단 필요

• 예외 및 장애 대응:

  • 주문 실패 시: Redis 재고 보상 트랜잭션 (Increase) 수행.
  • Redis 장애 시: redis 가 뻗었을 경우에 대한 고민 필요

[ch0ijihwan]

좋은 접근인 것 같아요.

궁극적 일관성(Eventual Consistency) 을 어떤 방법으로 보장해줄 것인지에 대한 판단 필요

주문 실패 시: Redis 재고 보상 트랜잭션 (Increase) 수행.

Redis 장애 시: redis 가 뻗었을 경우에 대한 고민 필요

가 중요한 고민 포인트 일 것 같습니다.