주문 안정화를 위해 재고 처리 구조를 어떻게 봤는가
커머스 플랫폼에 적응하기 시작하면서 가장 빨리 중요해진 주제 중 하나가 재고 처리와 주문 안정화였습니다. 트래픽이 몰리는 상황에서는 결국 특정 상품과 특정 재고 row에 부하가 집중되기 때문에, 단순한 기능 이해보다도 재고 구조와 주문 흐름을 먼저 보는 게 필요했습니다.
왜 재고가 핵심이었는가
조회 트래픽이 커지는 것만으로는 서비스가 바로 무너지지 않을 수 있습니다. 하지만 주문이 몰리는 순간에는 이야기가 달라집니다. 같은 SKU에 대한 조회와 차감이 집중되고, 동시에 여러 서버와 트랜잭션이 한 지점을 두드리기 시작하면 재고는 곧 시스템 병목의 중심이 됩니다.
특히 문제는 DB 트랜잭션이었습니다. 재고 차감은 정합성을 지켜야 하니 결국 DB 경계 안으로 들어오는데, 특정 DB 특성에서는 range lock 성격의 경합까지 겹치면서 경쟁이 훨씬 심해졌습니다. 히트 상품 하나를 사기 위해 수십만 고객이 몰리는 상황에서는 이 구간이 가장 예민했습니다.
이 때문에 주문 안정화를 이야기할 때 가장 먼저 본 건 API 레벨이 아니라 inventory 구조였습니다. 재고를 어디서 들고 있는지, 차감은 어떤 흐름에서 발생하는지, fulfillment location은 어떤 단위로 연결되는지부터 잡아야 전체 그림이 보였습니다.
이건 단순히 데이터베이스 테이블을 본다는 의미가 아닙니다. 재고를 어떤 모델로 취급하는지, 읽기와 쓰기를 어디서 분리할 수 있는지, 운영 이벤트가 몰릴 때 어떤 경쟁이 생길지를 먼저 이해하는 일에 더 가까웠습니다.
당시 자료에서 보인 개선 방향
플랫폼 고도화 계획에는 재고 row 집중, read only DB, queue, cache/no-sql 전략이 명시되어 있습니다. 이 내용은 당시 문제를 아주 잘 보여줍니다.
- 읽기 부하는
read only DB로 분산 - 차감 처리 경쟁은
queue로 완화 - 장기적으로는
cache나no-sql을 활용해 RDB 집중도를 줄이는 방향
실제로 체감상 가장 효과가 있었던 건 ProxySQL 도입 이후의 Read/Write 분리였습니다. 읽기 경로를 더 명확히 분산하면서 그 전보다 훨씬 버티는 시간이 늘었습니다. 반면 queue 기반 차감 완화는 당시에도 필요성을 분명히 느꼈지만, 미래 계획으로 남았고 실제 도입까지는 가지 못했습니다.
즉 단순한 쿼리 튜닝 문제가 아니라, 재고를 어떤 모델과 흐름으로 다룰지의 문제였습니다.
그래서 재고는 성능이나 정합성 중 하나만의 문제가 아니었습니다. 잘못 설계하면 느려지고, 더 심하면 주문 가능 여부 자체가 흔들릴 수 있습니다. 주문 안정화에서 재고를 중심 축으로 본 이유가 여기에 있습니다.
내가 재고 구조를 볼 때 먼저 본 것
- SKU와 inventory가 어떤 관계로 연결되는가
- fulfillment location이 재고 처리와 어떻게 이어지는가
- 조회와 차감이 같은 저장소/같은 경로를 타는가
- 트래픽이 몰릴 때 경쟁이 어디서 발생하는가
이 질문들만으로도 “무엇을 개선해야 하는가”가 꽤 빨리 드러났습니다.
재고를 먼저 보면 이후의 병목 논의도 훨씬 명확해집니다. 무엇이 읽기 부하인지, 무엇이 쓰기 경쟁인지, 무엇이 구조 문제인지 분리해서 볼 수 있기 때문입니다.
다음 글에서는 실제 대량 트래픽 상황에서 병목을 어떤 식으로 관찰했고, 어떤 방식으로 줄여나갔는지 이어서 정리합니다: 대량 트래픽에서 병목은 어디서 생기고 어떻게 줄였는가