시나리오
<aside>
➡️ 전체 조회 / 당일 오픈런 행사 상품 조회의 속도 개선
</aside>
인원 : 100 X n 명
시간 : 5초
루프 : 10번
상품 데이터 수 : 5060500개
테스트에 사용된 API
상품 전체 조회 API
오픈런 상품 전체 조회 API
❗각각의 API는 별도로 진행
전체 조회
오픈런 조회
1차 테스트 - 초기 상태
테스트 환경
인원 : 100명
시간 : 5초
루프 : 10번
AWS : EC2 t3.micro - RDS t2.micro MySQL
테스트 결과
- 기본 MVP. 최초의 상태일 경우, 500만 건의 데이터 처리 성능 결과
해결 방안
- 페이징 객체를 만들기 위해 2번의 쿼리 content, count 쿼리 중 content 쿼리를 빠르게 가지고 오기 위해, PRIMARY 별칭의 기본 인덱스를 걸어 해결해 보기.
2차 테스트 - 조회 속도 향상<인덱스 적용>
테스트 환경
인원 : 100명
시간 : 5초
루프 : 10번
테스트 결과
- 정렬 기준을 id로 해서 index를 타게 해줌 500만 건의 데이터 처리 성능 결과
해결 방안
- 전체 상품 조회의 Count쿼리를 Global Cache에 저장하여 조회시마다 Global Cache에서 상품 총합 가져오기
3차 테스트 - 조회 속도 향상 <Cache- count 쿼리 >
테스트 환경
인원 : 100명
시간 : 5초
루프 : 10번
- 전체 상품 조회 2차 테스트에서 페이징을 위한 count쿼리 문제를 발견
- 상품 total count ⇒ Global Cache에 미리 저장
테스트 결과
- 전체 상품 조회의 Count쿼리를 Global Cache에 저장 후 전체 상품 조회 시 사용
다음 목표
- 프로젝트 특성상 많은 소비자들이 조회를 할 것으로 예상되어 전체 상품 페이징 데이터를 Global Cache를 이용해 DB의 IO를 줄여 많은 소비자에게 빠른 전체 상품 데이터 전달
4차 테스트 - 조회 속도 향상<캐시 - 페이지 별 상품 >
테스트 환경
인원 : 1500명
시간 : 5초
루프 : 10번
- 전체 상품 조회의 경우, 페이지 별 상품 정보 Global Cache에 저장
테스트 결과
- 전체 상품 페이징 데이터를 Global Cache에 저장
다음 목표
- Paging된 전체 상품을 Global Cache에 담아 성능이 올랐으나 EC2 서버에서 모든 요청을 처리하지 못하며 에러가 발생하는 경우 발생
5차 테스트 - Scale Up
테스트 환경
인원 : 4000명
시간 : 5초
루프 : 10번
AWS : EC2 c5.large - RDS t2.micro MySQL
테스트 결과
| 라벨 | 표본수 | 평균(ms) | 중앙값(ms) | 99%Line(ms) | 오류
(%) | 처리량 | 수신
KB/sec | 송신
KB/sec |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| /api/products | 40000 | 2200 | 2374 | 4403 | 0.00% | 1435.8/sec | 10011.31 | 200.50 |
| TOTAL | 40000 | 2200 | 2374 | 4403 | 0.00% | 1435.8/sec | 10011.31 | 200.50 |
- 이전 테스트 성능 대비 약 40%(1014/sec → 1435/sec) 성능 개선 확인
- 응답 속도 또한 평균 2.2초로 매우 준수한 상황을 보이고 있음.
추가 테스트 환경(최대 성능 기록)
인원 : 5000명
시간 : 5초
루프 : 10번
| 라벨 | 표본수 | 평균(ms) | 중앙값(ms) | 99%Line(ms) | 오류
(%) | 처리량 | 수신
KB/sec | 송신
KB/sec |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| /api/products/openrun | 50000 | 2835 | 3077 | 3634 | 0.00% | 1367.7/sec | 9599.50 | 192.25 |
| TOTAL | 50000 | 2835 | 3077 | 3634 | 0.00% | 1367.7/sec | 9599.50 | 192.25 |
1차 테스트 - 초기 상태
테스트 환경
인원 : 100명
시간 : 5초
루프 : 10
AWS : EC2 t3.micro - RDS t2.micro MySQL
테스트 결과
- 기본 MVP. 최초의 상태일 경우, 500만 건의 데이터 처리 성능 결과
해결 방안
2차 테스트 - 조회 속도 향상<인덱스>
테스트 환경
인원 : 100명
시간 : 5초
루프 : 10번
테스트 결과
- 기본 MVP. product status에 index 걸어준 후 500만 건의 데이터 처리 성능 결과
해결 방안
- 특정 시간에 당일의 오픈런 상품 정보를 캐시에 미리 저장 해두고 조회하는 방안을 고려.
3차 테스트 - 조회 속도 향상 <Cache - 오픈런 상품>
테스트 환경
인원 : 300명
시간 : 5초
루프 : 10번
- 오픈런 상품 조회의 경우, 페이지 별 상품 정보 Global Cache에 저장
- 프로젝트에서 중요한 서비스이므로, 당일 오픈런 상품 정보 페이지 Global Cache에 미리 저장
(Cache Warmup 활용)
테스트 결과
- 오픈런 상품 조회의 Count쿼리를 Global Cache에 저장 후 오픈런 상품 조회 시 사용
다음 목표
- Paging된 오픈런 상품을 Global Cache에 담아 성능이 올랐으나 EC2 서버에서 모든 요청을 처리하지 못하며 에러가 발생하는 경우 발생
4차 테스트 - Scale Up
테스트 환경
인원 : 3000명
시간 : 5초
루프 : 10번
AWS : EC2 c5.large - RDS t2.micro MySQL
테스트 결과