Github 링크
https://github.com/ghrltjdtprbs/MSA_FirstComeStore/commit/099abad3b9e1e2d7b23872743ba9bf2a98901f53
분산락 적용 블로그 링크
https://velog.io/@ghrltjdtprbs/%EB%B6%84%EC%82%B0%EB%9D%BD
JMeter를 이용한 동시성 테스트
락이 잘 작동하는지 확인하기 위해 JMeter를 사용하여 동시에 많은 주문 요청을 보내는 테스트를 진행하였다.
💡 동작 방식 분석
- 동시 요청: 여러 요청이 동시에 서버로 도착합니다.
- 분산 락 획득: 각 요청이 락을 시도하고, 락을 획득한 요청만 재고를 차감합니다.
- 재고 차감: 락을 획득한 요청은 재고를 차감하고 락을 해제합니다.
- 재고 부족 요청: 이후 락을 획득한 요청은 남은 재고가 부족하여 실패하게 됩니다.
💡 테스트 결과 예측
실제 테스트를 수행하기 전에 테스트 결과를 예측해보자.
구매 수량이 1인 2000개의 주문 스레드가 거의 동시에 주문 API를 호출할 예정이다.
만약 동시성 제어가 잘 되어있다면, 먼저 요청된 500개의 API만 성공하고, 그 후의 요청은 모두 409 에러로 실패하여야 한다.(재고 부족 예외처리)
JMeter 설정
1. Thread Group 추가
- Add -> Threads(Users) -> Thread Group을 통해 사용자가 동시에 얼마나 많은 요청을 보낼지 설정할 수 있다.
- Thread Group의 설정을 통해 동시 요청 수, Ramp-up 기간 등을 설정
2. HTTP Header Manager 추가
- Content-Type을 application/json으로 설정하여 JSON 형식의 요청을 보낼 수 있도록 설정
3. HTTP Request 설정
- Thread Group -> Add -> Sampler -> HTTP Request에서 실제로 API 요청을 구성
🛠️ 그 외 테스트 환경 설정
주문 API는 장바구니 기능인 wishlist의 id를 받아 wishlist안의 상품과 수량대로 주문이 수행되는 API이다.
신뢰성 있는 테스트를 위해서는 주문 API의 파라미터(wishlistId)를 동적으로 변경해야한다.
4. HTTP Request에서 파라미터 동적 사용
- HTTP Request에서 파라미터로 Counter 값을 동적으로 사용하여, 각 요청이 서로 다른 optionId를 사용하도록 설정한다
- ${wishlistId}와 같은 형식으로 Counter의 값을 사용할 수 있다
- Thread Group -> Add -> ConfigElement-> Counter
🛠️ 테스트를 위한 데이터 삽입
5. 장바구니(wishlist) Database 업데이트
- 테스트를 위한 wishlist를 database에 넣는다.
📎 optionId가 1인 제품을 1개씩 주문한다. - 수월한 테스트를 위해 주문자 확인 로직을 임시로 주석처리 하였으니 user_id는 신경쓰지 않아도 된다.
6. 재고 업데이트
- optionId 1인 제품의 수량을 500개로 설정하였다.
🛠️ 테스트 결과 확인
7. 결과 확인을 위한 View Result in Table 생성
- Thread Group -> Add -> Listener -> View Result in Table
8. 응답확인
- 예측대로 요청 500개의 성공적인 주문 요청을 보내고, 나머지는 재고 부족으로 인해 실패하는 시나리오를 확인할 수 있다.
결과 분석
-
성공한 요청: 총 500개의 주문 요청이 성공적으로 처리
-
실패한 요청: 재고가 부족할 때 발생한 409 에러는 예상한 결과로, 재고 부족으로 인한 예외 처리
재고 반영 확인
결론
위의 테스트로 분산 락을 통해 대규모 서비스에서 선착순 주문 기능을 안정적으로 처리할 수 있음을 확인하였다.
product-service의 재고 반영도 성공적으로 처리되었음을 확인할 수 있다.
공부...열심히...