대규모 트래픽을 처리하는 이커머스 시스템에서는 재고 관리를 신뢰성과 확장성 측면에서 고민해야 합니다. 특히 Kafka와 같은 메시징 시스템을 활용해 비동기 재고 처리를 설계할 경우, 언제 재고를 차감할지를 결정하는 전략이 중요합니다.
Kafka를 활용한 재고 차감 방식에는 사전 차감 방식과 사후 차감 방식 두 가지가 존재합니다.
각각 어떠한 구조와 장단점을 갖고 있을까요?
사전 차감 방식
사전 차감 방식은 결제 이전에 먼저 재고를 차감하는 구조입니다.
주문 요청 시점에 Redis를 활용해 실시간으로 재고를 차감하고, Kafka를 통해 차감 이벤트를 발행한 뒤 상품 서버가 이 이벤트를 소비해 최종적으로 DB에 반영합니다.
사전 차감 방식의 흐름
사전 차감 방식의 흐름은 아래와 같습니다.
(단, 재고를 관리하는 서버는 상품 서버, 주문은 주문 서버, 결제는 결제 서버에서 관리합니다.)
- 사용자가 주문을 요청합니다.
- 주문 서버는 상품 서버의 Redis 재고를 차감 합니다.(동시성 안전 확보를 위해 Lua 스크립트를 사용합니다.)
- 상품 서버가 재고 차감에 성공하면, 재고 차감 이벤트 메시지를 발행합니다.
- 상품 서버가 재고 차감 이벤트 메시지를 수신하고, DB에서 실제 재고 값을 차감합니다.(Redis와 DB의 정합성)
- 주문 서버는 결제 서버에 결제 요청을 보냅니다.
- 결제가 성공하면 주문이 최종적으로 완료됩니다.
- 결제가 실패하면 주문 서버에서 재고 롤백 이벤트 메시지를 발행합니다.
- 상품 서버에서 재고 롤백 이벤트 메시지를 수신하고 DB와 Redis에 차감된 재고를 복구합니다.
사전 차감 방식의 장점 & 단점
사전 차감 방식의 장점은 다음과 같습니다.
- 먼저 주문한 사용자에게 우선권을 부여할 수 있습니다.
- 결제 중 재고가 소진되는 상황을 방지할 수 있습니다.
- 품절 상품에 대한 무의미한 결제 시도가 감소합니다.
- 결제 처리량이 많을 때도 빠르게 병렬 처리가 가능합니다.
단점은 다음과 같습니다.
- 결제 실패 시 재고 복구 로직이 필요합니다.
- Kafka 메시지 지연과 유실에 따른 정합성 이슈 대응이 필요합니다.
- 복구 실패 시 장애 가능성이 존재합니다.
사후 차감 방식
사후 차감 방식은 결제 이후에 재고를 차감하는 구조입니다.
즉, 실제 재고 감소는 결제 성공이 보장된 뒤에 이뤄지며, 해당 과정 또한 Kafka 이벤트를 통해 비동기적으로 처리됩니다.
사전 차감 방식과 달리 사용자 주문 시점에는 재고를 확보하지 않기 때문에, 결제 성공 후 재고 부족이 발생할 가능성이 있습니다.
사후 차감 방식의 흐름
사후 차감 방식의 흐름은 아래와 같습니다.
- 사용자가 주문을 요청합니다.
- 주문 서버는 결제에 결제 요청을 보냅니다.
- 결제가 성공하면, 주문 서버는 재고 차감 이벤트 메시지를 발행합니다.
- 상품 서버에서 재고 차감 이벤트 메시지를 수신하여 Redis 및 DB의 재고를 차감합니다.
- 주문 상태가 최종적으로 완료 처리가 됩니다.
사후 차감 방식 장점 & 단점
사후 차감 방식의 장점은 다음과 같습니다.
- 재고 차감은 결제가 성공한 후에만 발생하므로, 정합성 관리가 상대적으로 수월합니다.
- 결제 실패시 별도의 복구 로직이 필요 없습니다.
- 구현이 비교적 단순하고, 흐름이 명확합니다.
단점은 다음과 같습니다.
- 결제 도중 재고가 부족해질 수 있어, 결제 성공 이후에도 주문 실패가 발생할 수 있습니다.
- 재고 우선 확보가 불가능하므로, 상품에 대한 공정한 구매 보장이 어렵습니다.
- 결제까지 완료한 사용자에게 품절 안내를 해야 하는 이슈가 발생할 수 있습니다.
그렇다면, 어떤 방식을 사용해야 할까요?
사전 차감 방식 vs 사후 차감 방식
사전 차감 방식은 각각의 장단점이 뚜렷하기 때문에, 비즈니스 성격과 시스템 요구사항에 따라 적절한 방식을 선택해야 합니다.
사전 차감 방식은 트래픽이 집중되는 이벤트성 상품이나 한정 수량의 인기 제품에 적합합니다. 선착순 기반으로 빠르게 재고를 확보해야 하며, 중복 결제나 품절 이슈를 방지하는 데 효과적입니다. 다만, 복구 로직을 견고하게 구현해야 하며, Kafka의 신뢰성과 메시지 처리 지연에 대한 대비가 필요합니다.
사후 차감 방식은 정합성을 가장 중요하게 여기는 경우에 적합합니다. 비즈니스 로직이 비교적 단순하고 안정적이며, 결제 이후의 흐름이 명확하기 때문에 복잡한 오류 대응이 필요 없는 구조로 설계할 수 있습니다. 다만, 재고 확보의 우선순위를 보장하지 못하기 때문에 실시간성이 중요한 시나리오에는 적합하지 않을 수 있습니다.
마무리
사전 차감 방식이든 사후 차감 방식이든 중요한 것은 메시지 유실, 중복 처리, 장애 전파 등에 대한 복원력이 있는 설계 입니다.
결과적으로 재고 차감 시점을 결정하는 일은 데이터 정합성을 우선할 것인지, 처리 속도와 우선순위 보장을 우선할 것인지에 대한 트레이드 오프의 문제입니다.
'Kafka' 카테고리의 다른 글
Kafka Transactional Producer (0) | 2025.04.22 |
---|---|
Dead Letter Topic (0) | 2025.04.21 |
Kafka 사용 사례 (0) | 2025.04.16 |
Kafka랑 친해지기 (0) | 2025.03.26 |