문제 상황
특정 일시에 오픈하는 예약 구매 특성상 동시에 주문처리가 많이 일어남
이 때에 실제 재고보다 더 많은 수량의 주문이 성공적으로 처리됨
문제 원인
주문 시 DB에 짧은 시간 동안 동시 접근이 일어나 여러 트랜잭션에서 동일한 데이터를 수정하려고 할 때 데이터 불일치 문제 발생
재고관리 프로세스
예약 구매를 하는 서비스를 만드는 것이 목표였기 때문에 메인 서비스가 잘 돌아가게 하는 것이 매우 중요하다고 생각했습니다.
이 과정을 크게 두 가지 스텝으로 나누어 생각해보면 아래와 같습니다.
- 특정 시간에 구매가 활성화 됨
- 구매가 열리면, 상품의 재고보다 많은 주문 발생할 수 있음
사례 분석
이 과정에서 비슷한 레퍼런스를 생각해보니 크게 두 가지로 나눌 수 있었습니다.
- 큐넷(시험 접수)
- 인터파크 티켓(콘서트 예매)
한정적인 재고에서 많은 구매가 발생하는 대표적인 케이스라고 생각이 들어 예약 구매 로직에 비슷하게 적용해 볼 수 있다 생각이 들었습니다. 각각 재고를 관리하는 방법이 다르기 때문에 이것을 예약 구매에 대입하여 정리해보았습니다.
1. 큐넷(시험 접수)
이 서비스에서는 각각의 단계마다 재고를 실시간으로 조회합니다.
만약 주문을 누르는 단계에서 재고가 이미 떨어진 경우, 주문이 넘어가지 않습니다.
다음으로 결제를 누르는 단계에서도 재고를 조회하여 재고가 없다면 더이상 진행이 안되고, 마찬가지로 결제를 정상적으로 한 이후에도 재고 부족이면 처음페이지로 돌아갑니다.
2. 인터파크 티켓(콘서트 예매)
다음으로 이 서비스에서는 처음 구매 버튼을 누른 사람이 우선권을 가집니다. 정확히 말하면 이 서비스는 자리를 예매하는 시스템이다보니 A1 이라는 좌석을 누르면 그 좌석을 비활성화 시켜버립니다. 그리고 그 사람이 결제하기 전까지는 아무도 누를수 없습니다.
누른 버튼은 10분까지 결제가 유효하고, 그 안에 결제완료가 되지 않으면 취소되며 자리가 다시 예약가능 상태가 됩니다.
각 서비스 이용 경험
개발 이전에 이러한 서비스를 사용해 본 관점에서 생각해봤을 때 1번은 유쾌하지 못한 경험으로 남아 있었습니다.
재고가 없다면 그냥 주문단계에서 포기를 하게하면 차라리 희망(?)조차 없게 되는데 카드정보를 입력하고, 배송 정보를 입력하는 등(보통 이런 시스템은 다 수동으로 입력하게 함) 진행하고 마지막에서야 재고가 없다며 취소가 되어 버립니다.
이런 과정을 2~3번만 연속으로 겪으면 해당 사이트에 대한 이미지가 나빠지게 됩니다. 마치 선착순 깃발뺏기 게임을 하는 느낌이랄까요..
2번의 경험으로는 주문버튼을 누른 순간 재고에 대한 우선권을 가지기 때문에 먼저 선점하지 못한 경우 단순한 아쉬움에서 끝났습니다. 비즈니스 로직에 대입해봐도 주문 전 재고확인만 하면 되는 장점이 있습니다.
다만 주문한 사람이 실제 결제까지 얼만큼 이루어질지, 이탈율에 대한 고민도 필요합니다.
발생할 만한 오류 분석
이러한 두 가지 프로세스에서 생각해 볼 수 있는 오류 내용들은 아래와 같습니다.
- 결제가 이루어졌지만 재고가 없어 취소됨
- 상품페이지의 재고 수가 정확하지 않음
2-1. 재고가 있어도 다음 단계로 넘어가지 않음
2-2. 페이지를 동시에 새로고침 했을 때 재고 수가 다르게 표기됨 - 결제 시도가 불가능
- 서비스 불가능
4-1. 트래픽 몰림으로 인한 서버 다운
4-2. 구매와 관련 없는 고객들이 불편을 겪음 - 오픈 시간 이전 구매 가능
의사결정 및 추가로 생각해 볼 점
앞서 두 가지 경험을 떠올려보며 기술한 오류 내용들에서 어떤 부분을 가장 최우선으로 둘까 생각해 봤습니다.
고민 끝에 '1. 결제가 이루어졌지만 재고가 없어 취소됨'을 최우선으로 두었고, 이를 해결하는 측면에서 2번이 낫겠다고 결정하게 되었습니다.
이것이 첫번째인 이유는 이전 기술지원 업무 경험으로 비추어 봤을때 결제까지 갔는데 오류가 났던 유저는 강성 클레임 고객에 되는 경우가 많았기 때문입니다. 위에서 기술한대로 제 경험으로 비추어봐도 좋지 못했던 경험이 있었구요.
또, 제가 생각하는 주문-결제 프로세스는 주문을 시작한 이상 결제까지는 마칠 수 있어야 고객에게 좋은 경험을 제공한다고 생각합니다. 일반 가게를 생각해봐도, 여러명이 한 번 가는 가게보다 단 몇 명이라도 단골이 있는 가게는 왠만해서 망하지 않는다고 생각합니다. 이는 음식이 늦게 나오더라도 음식의 퀄리티가 좋아야합니다. 마찬가지로 주문-결제는 문제없이 이루어져야 한다는 생각에서 2번이 더 적합하다는 결론이 나왔습니다.
2번을 선택했을 때 오류의 2,3,5번이 자연스레 해결되는 것 또한 장점이었습니다. 주문 단계에서 진입이 되지 않으면 이후 서비스 영역에는 트래픽이 미치지 않기 때문입니다.
만약 이미 실시간 재고관리 서비스가 돌아가고 있는 상태였다면 이 안에서 해결을 해야하지만 아직 재고관리 프로세스를 정하지 않은 상황에서 의사결정하는 부분 이었기 때문에 이러한 결정을 내릴수 있었습니다.
이제 재고관리에서 어떤식으로 동시 접근을 처리할지에 대한 고민으로 자연스레 이어졌습니다.
'성장기록 > 개인프로젝트' 카테고리의 다른 글
sequel pro - caching_sha2_password 오류 (0) | 2024.08.03 |
---|---|
기존 개인 프로젝트 개선 계획 (0) | 2024.07.31 |
트러블 슈팅 - 동시 구매 시 재고관리에 대한 고민 2. 동시 구매시 재고관리 접근 (0) | 2024.03.11 |
트러블 슈팅 - DB 연관관계에서의 N+1 문제 (0) | 2024.03.04 |
jwt 토큰을 관리하는 방법에 대한 고민 (0) | 2024.03.03 |
남에게 설명할 때 비로소 자신의 지식이 된다.
포스팅이 도움되셨다면 하트❤️ 또는 구독👍🏻 부탁드립니다!! 잘못된 정보가 있다면 댓글로 알려주세요.