주문 트래픽 20배를 견디는 재고 처리 구조 만들기
Summary
DB Lock 병목을 부수다: 20배의 주문 폭주를 가뿐히 이겨낸 아임웹의 무중단 재고 처리 설계기
대형 공동구매 트래픽도 끄떡없는 Redis 분산 락과 Kafka 비동기 파이프라인 결합 설계 가이드
피크 트래픽 발생 시 고질적으로 발생하던 DB 슬로우 쿼리와 Row Lock 대기 현상을 해결하기 위해 아임웹 백엔드 팀이 진행한 대대적인 아키텍처 개편 과정을 담고 있습니다. 쿼리 튜닝이라는 1차원적인 수정을 넘어, 재고 도메인을 상품 도메인으로 단일화하고 빠른 구간은 Redis와 Kafka를 활용해 완전히 비동기로 전환한 실전 경험을 상세히 공유합니다.
- 01DB 성능 저하의 주범이었던 row lock 대기 시간과 커넥션 고갈의 명확한 인과관계 분석
- 02주문, 오픈 API, 어드민 등 사방에 흩어져 있던 재고 변경 주체를 상품 도메인 하나로 통일
- 03메인 트래픽 경로를 DB에서 Redis 기반 분산 락 캐싱으로 격상해 락 경쟁 차단
- 04Kafka 비동기 메시지 파이프라인과 실패 시 직접 DB를 호출하는 Retry-Fallback 안전망 설계
- 05K6 부하 테스트 도구로 2주간 철저히 검증하고 점진적 프로덕션 배포 전략으로 리스크 최소화
RECOMMENDATION
이커머스, 티케팅, 한정판 이벤트처럼 특정 시간에 대량의 리소스 락 획득 경쟁이 발생하는 대용량 백엔드 아키텍처를 설계하려는 개발자에게 추천합니다. 캐시와 메시지 큐를 통한 비동기 시스템 전환 및 분산 환경의 장애 대비 예외 처리 방식을 다루고 있어 깊은 실무 인사이트를 제공합니다.
The Problem
공동구매와 같이 특정 시각에 주문 트래픽이 몰리는 이벤트 발생 시, 특정 옵션 재고를 동시에 갱신하려는 요청이 한 지점으로 집중되며 DB Row Lock 대기 시간이 길어져 슬로우 쿼리와 500 에러를 유발했습니다. 이로 인해 DB 커넥션이 차단되어 전체 서비스의 연결이 불안정해졌으며, DBA가 실시간으로 세션을 직접 수동 종료해야 할 만큼 비효율적인 운영 리소스 낭비가 반복되었습니다.
The Solution
재고 변경 지점을 상품 도메인 한 곳으로 단일화하고, Redis 기반의 핫 패스 영역에서 분산 락을 이용해 동시성을 제어한 뒤, DB 변경 이벤트를 Kafka 메시지로 발행하여 별도 컨슈머가 비동기로 DB에 반영하는 구조를 도입했습니다. 만약 Kafka 메시지 발행이 실패하면 자체 재시도 로직을 가동하고 최종적으로 DB를 직접 변경하는 폴백 안전장치를 연계 설계했습니다.
The Result
아임웹 평소 최고 트래픽의 약 20배 수준에 달하는 대형 공동구매 실전 이벤트에서 서버 다운 한 번 없이 대용량 주문을 안정적으로 처리하는 데 성공했습니다. 더불어 대용량 주문이 몰려도 관리자가 직접 슬로우 쿼리를 모니터링하거나 비정상 종료를 시켜야 하는 수동 개입의 문제를 완전히 불식시켰습니다.
Trade-off
실시간 동기식 처리 방식 대신 Kafka를 거치는 비동기 방식을 도입함에 따라 데이터의 즉각적인 일관성 대신 최종 일관성을 타협해야 했습니다. 아울러 Redis 분산 락, Kafka 메시징, 예외 처리를 위한 폴백 처리기 등 다중 아키텍처 구성 요소가 추가되면서 전체적인 시스템 복잡도가 크게 증가하는 트레이드오프가 존재합니다.
Key Concepts
More from 아임웹
View all posts from 아임웹
Related reads#Redis
Explore #Redis
WebFlux 전환 부하 테스트를 다시 쓴 이야기
데이터 통합— MongoDB 원칙으로 document를 통합하고 동기화를 재설계하다 (3/3)
Redis 6.x에서 Valkey 9.0으로: 운영 캐시 성능과 비용을 함께 개선한 전환기
Spring Data Redis: Repository vs RedisTemplate — 실전 성능 비교
