Shopify는 왜 재고 예약 시스템에서 Redis를 버리고 MySQL로 돌아갔나

무엇인가요

Shopify 엔지니어링 블로그가 재고 예약 시스템을 Redis에서 MySQL로 옮긴 과정을 공개했습니다. 기존에는 Redis(빠른 예약)와 MySQL(실제 청구)이 분리돼 있었는데, 두 단계 사이에 원자성이 보장되지 않아 과다판매(overselling) 위험이 있었다고 설명합니다. 같은 데이터베이스에서 ACID 트랜잭션으로 처리하도록 바꾸면서 이 위험을 구조적으로 없앴습니다.

기술적으로는 MySQL 8의 SKIP LOCKED 기능을 활용해, 기존에 “재고 10개 = 수량 컬럼 1행”이던 구조를 “재고 10개 = 10개 행”으로 바꿨습니다. 복합 기본키로 행당 락 개수를 줄이고, READ COMMITTED 격리 수준으로 갭 락을 방지했으며, 락 순서를 표준화해 교착 상태를 막았습니다. 흥미로운 발견은 실제 병목이 쿼리 성능이 아니었다는 점입니다. CPU 사용률은 낮은데 처리량이 한계에 부딪혔고, 원인을 추적해보니 다른 코드가 DB 커넥션을 필요 이상 오래 붙잡고 있었다고 밝혔습니다. 최적화 후 기본 DB 읽기는 50%, 트랜잭션은 33% 줄었고 플래시 세일 중에도 쓰기 CPU를 50% 미만으로 유지할 수 있었다고 합니다.

왜 주목할까요

• “Redis가 빠르니까 캐시·큐로 쓰고 최종 처리는 DB로”라는 흔한 설계가 오히려 정합성 문제를 만들 수 있다는 반례입니다.
• 성능 문제의 원인이 예상(쿼리 최적화)과 다른 곳(커넥션 점유 시간)에 있었다는 점은 “감으로 최적화하지 말고 측정부터 하라”는 원론적 교훈을 실제 대규모 사례로 보여줍니다.
• 플래시 세일처럼 순간 트래픽이 몰리는 이커머스 환경에서 과다판매는 곧바로 고객 신뢰·환불 비용으로 이어지는 문제라 실무 체감도가 높습니다.

국내 관점 코멘트

국내에서도 타임세일·선착순 할인·한정 수량 이벤트를 운영하는 커머스·티켓팅 서비스가 많은데, 이 구조에서 가장 흔히 겪는 사고가 바로 과다판매입니다. 트래픽이 몰릴 때만 재현되는 문제라 평소 테스트로는 잘 안 잡히고, 사고가 난 뒤에야 원인을 찾게 되는 경우가 많습니다.

당장 Shopify처럼 대규모 재설계를 할 필요는 없지만, 재고·예약·결제 단계 사이에 트랜잭션 경계가 명확히 있는지, 캐시(Redis)와 원장(DB)이 분리돼 있다면 그 사이 정합성을 어떻게 보장하는지는 지금 점검해볼 만합니다. 특히 다음 대형 프로모션 전에, 커넥션 풀 점유 시간처럼 눈에 잘 안 띄는 지표부터 한번 프로파일링해보는 것을 권합니다. Shopify 사례처럼 진짜 병목은 예상 밖의 곳에 있을 수 있습니다.