뭐야 코드가 이상하잖아요
입사를 하고, 출고에 차차 익숙해질 무렵, 재고가 매번 틀어지는게 보였다.
왜 틀어지는건가 하고 코드를 유심히 보고 있었는데
- 해당 할당되어있는 재고를 조회한다.
- 조회된 재고에서 요청량을 할당한다.
딱봐도 문제가 많아보이는 코드였다.
그래서 부트캠프에서 배웠던 것을 그대로 적용해서 트랜잭션 격리가 필요하다 생각하여
모두 시도를 해봤지만 정상 동작을 하지 않았다. (해당 프로젝트는 멀티 인스턴스 상태였다.)
이힛 데드락 발싸
재고가 음수면... 외상인가?
더불어서 음수의 재고 또한 존재했다.
음수 재고는 도대체 왜 있는 것인가에 대하여 의문을 표하다가
재고 컬럼에 UNSIGNED 옵션을 거는 것으로 예방을 할 수 있었다.
(애초에 왜 안 걸려 있었는지도 의문임)
음수로는 안빠지는데, 계속해서 재고가 틀어지는 상황이 반복되다보니 다양한 고민을 해봤다.
빅테크가 사용하는 것처럼 레디스가 싱글 스레드인 것을 활용하여
큐처럼 사용하는 방식도 떠올렸으나, 하루에 출고가 300건~500건이 간신히 나가는 무렵에
오버엔지니어링이라 판단하여 다같이 찾아보던 중
재고 문제, 생각보다 간단하게 해결....?
내가 부트캠프에서 쿼리빌더를 사용해서 자기참조로 수량을 업데이트 하던 것이 생각났다.
조회를 한 후 빼는 쿼리가 아니라, 자기 자신에서 필요한 수량을 차감 혹은 증감하는 식의 쿼리를 사용한 결과
한번에 1000~3000개의 주문을 요청하는 테스트에도 정상적으로 재고가 틀어지지 않은 것으로 확인됐다.
이후 간간히 재고가 틀어졌으나 모든 쿼리를 수정하지 못한 채 모니터링 도구를 도입하게 된다.
바로 대처하면 바로 잡을 수 있다.
바로 스케쥴러에 쿼리를 입력해서, 어긋나는 결과가 발생할 경우 슬랙에 보내도록 만들었다.
재고가 틀어지고나서 시간이 많이 흐른다면 트래킹이 사실상 불가능하지만
금방 캐치를 하게 된다면 어떻게든 바로 잡을 수 있었기에,
슬랙에 재고가 틀어졌다는 메세지를 보내는 것으로 어느정도 해결을 할 수 있게 됐다.
이후 문제가 있던 쿼리를 모두 수정하는 것으로 모든 것이 해결되는 듯 했으나...
디비에 직접 접근한 댓가
스타트업 특성상 완벽한 개발이 불가능하기에, 다양한 운영이슈가 있었다.
그 중 재고 이동 요청이 있었는데, 여기서 문제가 발생한다.
최초에 있던 수량 : 10개
개발자 : 조회했어 (10개)
작업자 : 2개 뺐다 (8개)
개발자 : 4개 뺐어 (10-4 = 6개)진짜 별 일이 다 있지만, 스타트업은 이게 일상이다.
대기업은 쿼리 하나 치는것도 승인까지 받는다고 하던데...(그저 신기할 따름이다)
그러다보니 이걸 어떻게 추적을 해야할까라는 의문을 가지던 차에
Database trigger를 도입하면 어떻게든 추적이 가능할 것이라는 생각이 들었다.
여러가지 장치가 있겠으나, 디비를 직접 조작하는 상황에서 서버에 적용하는 것은 무의미하고
결국 디비에 변화가 있을 때 마다 반영이 되어야 했기에 최선의 선택이였다.
그렇게 업데이트 동작을 변경하고
모니터링 도구와 로그를 남기는 것으로 거의 완벽에 가까운 수준으로 재고를 잡을 수 있게 됐다.
되돌아보며
적정 기술이라는 말이 있다.
사실 대기업처럼 레디스를 사용해서 해결하는 방법도 있었을 것이다.
그렇지만 그게 과연 옳은 선택이였을까? 라고 생각을 한다면 그 당시에는 아니지 않았을까 싶다.
일일 출고량이 200~300건을 오가며, 그것 또한 업무시간(8시간) 내에 소비가 됐던 시기였기에
조금 더 쉬운 방법으로 돌아가는게 맞았다고 생각한다.
물론 출고량이 폭발적으로 증가를 했다면 모르겠지만 (B2B 특성상 확 늘기도 쉽지가 않다.)
10배에 가까운 출고량을 테스트 했을 때도 수량이 어긋나지 않았기에 차선책으로 좋은 선택이라 생각한다.
물론 레디스를 그렇게 써보지 못한 것은 매우 아쉬우나.. 언젠가는 사용 할 수 있지 않을까?
끝.
