개요
- 목적
- 대규모 트래픽을 시뮬레이션하고 예외 상황을 적용하여 시스템에 부하를 가하고 이를 통해 잠재적인 문제를 식별하고 예방하며, 안정적인 서비스 운영을 보장하기 위해 수행
- Auction-Server 상품검색API, 입찰내역조회API 성능테스트
- 성능테스트 도구 : Locust
- 대상 API:
- 상품 검색 API
대상 :
{{url}}/products/search?explanation={explanation}&sortOrder={sortOrder}&page={page}&pageSize={pageSize}
- 입찰 조회 API
대상 :
{{url}}/bids/histories/{productId}
- 기준값/목표
- 상품 검색API는 분당 약 300회, 동시사용자는 100명으로 예상하였습니다. 이를 고려하여 해당 API의 목표 TPS는 500TPS로 설정하였습니다.
- 입찰 조회API는 분당 약 100회, 동시사용자는 100명으로 예상하였으며, 목표 TPS는 160TPS로 설정하였습니다.
- 개수도 외에도 데이터의 중복도(카디널러티, 라이브상황과 비슷하게 설정)
- MySQL의 데이터를 Faker 라이브러리를 사용하여 추가
(최대 10만개의 데이터 추가를 위해 PerformanceTestController 작성)
- 리팩토링 부분 확인
- Elasticserch 적용
- Elasticsearch Index 리펙토링
- 코드 리펙토링
- 예외상황 체크
- Locust 지표 중 Failure Count 를 확인하여 예외 상황이 일어난 요청을 확인했습니다.
테스트 데이터 정보
- 해당 Python script는 faker 라이브러리를 사용하여 실제 라이브 환경과 유사한 검색, 입찰, 입찰조회을 하도록 구성하였습니다.
- 상품검색 API
- 입찰 정보 조회 API
테스트 시나리오
- Auction-Server 성능 테스트: 응답 시간 최적화 방법
- STRESS 테스트
- 일정 주기적(패턴)으로 부하를 줘서 프로그램 정상 가동 여부 테스트
- 동시 사용자 수 조정, 요청 패턴(서비스 복잡에 따른 HTTP HEADER, BODY 용량)
- 시나리오
- 검색 API의 Param의 용량(검색 조건)이 100명의 동시 사용자가 초당 100번을 호출하여 분당(5분) 사용자를 100씩 늘려 서버의 지표를 확인
- 입찰 조회API가 100명의 동시 사용자가 초당 100번을 호출하여 분당(5분) 사용자를 100씩 늘려 서버의 지표를 확인
- 로컬에서의 테스트이기 때문에 한계가 있습니다.
- Live 운영시의 형태와 다르게 모든 서버가 한 장비에서 테스트 되기에 성능이 상대적으로 안좋게 나올 수 있는점 참고 부탁드립니다.
- Endurance(내구성) 테스트
- 장시간 동안 시스템이 얼마나 안정적으로 동작할 수 있는지를 확인
- 시나리오
- 100명의 동시 사용자가 초당 100번을 호출하였을때 10분동안 서버의 지표 CPU, RAM, DISK, TPS 가 이상이 있는지 테스트
테스트 결과 및 리펙토링 결과