Gatling을 통한 API 테스트
간단하게 API 테스팅 툴 조사
Gatling을 선택하였는데 이유는 간단하다. 아직 프로젝트 초기이기에 구현한 api들이 안정적이지 않다. 따라서 눈에 확 띄게 무슨 api가 실패하고 있는지 보여주는 툴이 더 적합하다고 판단하였다.
Api 수정하고 api 테스트해보고 결과를 확인하고 다시 수정하는 사이클을 사용하기 쉽고 리포트가 이쁜 툴이 줄여줄 것이라 기대하였다.
Batch 작업 사이에 API Fail
M1맥북 에어에 떠있는 서버에 request를 날렸으며, item 생성 api와 마감 상품 조회 api를 순서대로 각각 100개의 request를 10초간 날렸다. 그런데 마감 상품 조회 api에서 몇개 api fail이 발생하였다.
로그를 확인해보니 로직의 문제였다. 수정하고나니 위와 같이 2000개의 모든 request가 정상 동작하였다. 해당 부분을 테스트로 재구성 밋 시뮬레이션을 하려고 하는데 @SpringBootTest를 사용하지 않고 오직 멀티 스레드로만 동일한 문제를 시뮬레이션할 예정이다.
이유는
- 프레임워크를 떠나서 최대한 로직적인 부분만을 테스트하기 위함
- 이렇게 하는 것이 간소화되어 테스트가 더 간단할 것
이라 판단하였기 때문이다.
TODO
위 실험은 item의 양이 절대적으로 부족하기에 api response 속도에 대해서는 제대로 알 수 없다. 마감 상품 쿼리 API 속도에 대해서 실험을 진행하기 위하여 최소한 10만건 이상의 데이터와 직접 Order by조회하는 API를 새로 뚫어서 비교해볼 것이다.
알림 서버 스켈레톤 코드 구현 및 알림 서비스 구축을 위한 카프카 학습을 진행했어야하는데 진행하지 못했다. 해당 부분을 마저 진행할 예정이다.
Backend Developer