NDM

동시성을 해결하기 위해 Redis를 선택하게 된 생각의 과정은 앞선 포스팅에서 정리하였습니다. https://ndm-tech.tistory.com/34 4. 재고 처리 로직 동시성 이슈 해결 일지 배달 어플을 구현하는 SlowDelivery 프로젝트에서 재고를 처리하는데 동시성 이슈가 있었습니다 더보기 하지만 사실 재고 도메인은 필요가 없었는지도 모릅니다. 일반적인 쇼핑몰과 다르게 배달 ndm-tech.tistory.com 이번 포스팅에서는 Redis를 어떻게 사용하여 동시성을 해결하였는지 알아보겠습니다. # Redis Transaction Redis 트랜잭션은 다른 DB와 달리 Rollback 개념이 없으며, 기본적으로 SpringBoot + Redis를 사용하였을 경우, Redis는 @Transact..

기존의 제 이벤트 상품 조회는 다음과 같이 이루어집니다. 첫 번째로 DB를 조회해서 Cache DB에 적재하고, 그 이후부터 Cache DB에서 데이터를 가져오는 방식입니다. # 왜 이벤트 상품을 캐싱으로 처리하려고 했나 ? 이벤트 상품에 대한 수정(상품 수정, 이벤트 상품 등록/취소) 작업이 일어나는 횟수가 적을 것으로 예상했고 타임딜 이벤트 상품들을 찾아보니 사이트마다 달랐지만 한번에 이벤트에 등록되는 상품 수가 많지 않았습니다. # 그럼 무엇이 잘못되었음을 깨닫고 시스템 디자인을 바꾸었는가? Cache DB를 사용하면 분명 키가 만료되는 순간이 존재한다. 그때마다 RDB를 다시 뒤져야한다. RDB를 다시 뒤질때마다 부하가 급증할 것이고, 성능도 보장할 수 없다. 지금은 모놀리식이지만, 마이크로서비스..

현재 진행중인 토이프로젝트는 "타임딜" 이라는 단시간에 많은 트래픽이 몰리는 프로모션 상품 구매 서비스 api 서버입니다. 현재 제 프로젝트의 주요한 api는 다음 2개입니다. 상품 조회 api 주문 api 비즈니스 로직이 어떻게 진행되는지 알기 위해, 시퀀스 다이어그램을 작성해 보았습니다. # 상품 조회 상품 조회의 요구사항은 다음과 같습니다. 일반 상품과 이벤트 프로모션 상품이 존재합니다. 상품 조회는 페이징 처리가 필수적입니다. 이벤트 프로모션 상품의 경우, 이미 이벤트가 진행중인 시점이라면 상품 수정 및 이벤트 해제가 불가능합니다. 이벤트 상품과 일반 상품 모두 조회 endPoint가 같으며, 쿼리스트링의 파라미터로 구분하였습니다. 다음은 시퀀스 다이어그램입니다. 기본적인 구상은 다음과 같습니다...

시간 안에 세일한 상품 이벤트 프로모션을 진행하는 커머스 플랫폼 api 서버 프로젝트를 진행중입니다. Jmeter를 이용해 테스트할 api는 크게 주문, 상품조회로 2가지 입니다. 이번 포스팅에서는 조회 api만 다루겠습니다. Jmeter는 로컬에서 돌리고, Spring서버는 로컬에서 한번, 운영에서 한번 해보는 것으로 진행하였습니다. Jmeter와 SpringBoot를 같은 서버에서 진행하면 제대로 된 테스트를 할 수 없기에, 로컬에서 함께 진행할 때는 적은 요청으로 무리가 없는지, Jmeter 설정이 제대로 이루어졌는지만 보는식으로 진행하고 운영에서 따로 진행하였습니다. * 기본적으로 Jmeter를 돌리는 제 노트북 성능이 별로 좋지 않아 제대로 된 성능이 나오지 않습니다. # 상품조회 상품 조회는 ..