재고 예약 방식 조건부 Update 캐싱

1. 동시성 문제에 대한 고민

• 재고 관리 문제의 경우, 일반적인 락 방식만으로는 운영상 한계가 있다고 생각했습니다.

  해결방안	방식	단점
  비관적 락	DB에서 락을 얻을 때까지 대기 후, 조작 가능	1. DB 커넥션 풀 상황에 따라 실패 가능

  2. 락 대기시간에 따라 응답 지연 |
  

  | 낙관적 락 | 조회 시점과 조작 시점의 데이터가 동일한 경우에만, 조작 가능 | 1. 요청 순서대로 처리 불가 2. 재시도 과정에 따라 응답 지연 or 실패 가능 |

  • 동일한 재고에 차감 요청이 초당 100개 들어온다면?

    (재고 차감 트랜잭션은 10ms동안 실행된다고 가정)

    • 비관적 락: 요청 1은 10ms, 요청 100은 1000ms, 평균 505ms
    • 재시도 없는 낙관적 락: 모든 요청 10ms, 그러나 성공률 1%
    • 재시도 하는 낙관적 락: 응답시간은 비관적 락과 비슷, DB 접근은 100+99+…+1 = 5050번으로 폭증

2. 락의 단점을 상쇄하는 조합

• 락 방식의 단점들을 상쇄하는 방안을 생각해봤습니다.

  해결방안	단점	상쇄방안
  비관적 락	1. DB 커넥션 풀 상황에 따라 실패 가능

  2. 락 대기시간에 따라 응답 지연 | 락으로 묶이는 트랜잭션 범위를 최소화
  

  or DB 락을 안 쓰면 베스트 | | 낙관적 락 | 1. 요청 순서대로 처리 불가 2. 재시도 과정에 따라 응답 지연 or 실패 가능 | DB 접근 전에 요청을 직렬화 → 순서 보장 + 공유자원 충돌 제거 |

• 직면한 현실 상황에 적용해보면, 비즈니스 요구사항은 락이 아닌 “세마포어”에 가깝습니다.

  • 공유자원인 “재고”의 개수를 기반으로, 여러 요청이 동시에 점유할 수 있기 때문
    • 총 재고 10개로 가정
    • 요청 A가 2개의 결제를 완료할 때까지, 요청 B가 3개를 건들이면 안 되는가? → ❌

• 따라서 각 요청의 재고 점유 상황을 기록하는 것으로 무거운 트랜잭션에서 벗어날 수 있겠다고 생각했습니다.

  단계	실제 재고	점유 중인 재고	주문 가능 재고	비고
  초기	3	0	3	—
  요청1이 1개 주문	3	1	2	요청1: 예약 중
  요청2가 2개 주문	3	3	0	요청2: 예약 중
  다른 요청이 주문 시도	3	3	0	**주문 가능 재고 0
  → 실패**
  요청1 결제 실패 / 요청2 결제 성공	1	0	1	요청1: 예약 해제,
  요청2: 차감 확정

• 또한, 재고의 개수가 핵심인 만큼, 낙관적 락과 비슷한 개념인 조건부 Update로 데이터 조작의 원자성을 보장할 수 있다고 생각했습니다.

  • 점유하는 순간에 요청 수량만큼 재고가 존재하면, 점유 가능함

    → 조회 시점의 재고와 같은지는 상관 X

  • DB에 재고 점유 상황을 명시적으로 기록하면, 무결성 보장하는 락을 흉내낼 수 있음

    • DB가 Update 조건 판단
    • 재고 현황 업데이트 및 예약 리스트 저장이 원자적으로 처리됨

3. 최종 결정

• 결제 전에 미리 확보하기 위해, 주문 시에 재고를 예약합니다.

  → 결제 전 재고 예약, 결제 후 재고 차감

• 재고 복구는 결제 취소가 확인되면 처리합니다.

  • 고객 취소 요청 시, 즉각 취소되는 간단한 플로우
  • 결제 취소 행위는 취소할 수 없는 특성을 고려

• 특히 재고 예약 방식을 도입하면서, 다른 고민사항들도 자연스럽게 해결할 수 있었습니다.

  1. 비즈니스적 문제
     • 결제 열심히 했는데, “품절입니다!”하면 고객 슬픔
     • 결제수단에 따라 결제에 필요한 시간이 천차만별
       • ex) 카드 결제 vs 무통장 입금
       • 결제 후 차감만 적용한다면, 누가누가 빨리 결제하냐의 싸움
       • 결제 후 품절이라면 결제 취소 해줘야 하는데, 동시 결제하면 다건 취소 발생
  2. 시스템적 고민
     • 주문 트랜잭션의 부담이 너무 크다는 문제 해결
       • 주문 프로세스에는 결제를 위한 외부 API 호출 (PG사)이 포함
       • 긴 트랜잭션 과정에서 재고 상태의 무결성을 보장해야 함
     • 재고의 흐름 파악에 대한 고민 해결
       • 예약 방식은 재고의 흐름을 자연스럽게 기록함
       • 추후 비즈니스 요구사항에서 결제 전 확보를 필요로 하지 않을 경우, 재고 예약을 재고 흐름 기록 과정으로 변경하면 자연스러움

4. 한정된 재고에 몇 천개의 동시 요청이 몰리면?

• 인기/특가 상품은 일정 시간에 동시 요청이 집중되는 상황이 많습니다.

• 재고 예약 방식과 조건부 Update로 정합성을 보장한다고 해도, DB 과부하가 발생하면 정상적인 서비스 제공 자체가 불가능합니다.

  • DB가 진실의 원천이기 때문
  • DB 서버 접근이 원활하지 않는 순간, 연쇄적으로 장애 전파가 될 가능성 높음

    1. 같은 데이터 조작을 위해 대기하느라, DB 커넥션 오래 점유

       → DB Connection Pool 고갈

    2. 요청 스레드도 DB 응답을 기다리느라 오래 점유됨

       → Thread Pool 고갈

    3. DB 서버의 CPU, 메모리, 디스크 사용률이 증가

       → 쿼리 실행도 더 오래 걸림

• DB가 감당할 수 있는 만큼, DB 요청을 줄이는 것부터 고려했습니다.

  • DB 요청을 줄이는 방법
    1. 재고 데이터를 캐싱하여, 어플리케이션 단에서 조건 검사로 불필요한 DB 접근 막기
    2. 아예 서비스로 들어오는 요청을 줄 세워서, 백프레셔 흡수하기
  • 실무에서는 2가지 방법 + a로 대처할 것 같지만, 일단 캐싱만으로 대처해보기로!