Title
exp007_스케일업 전후 어플리케이션 성능 비교 실험
Research Question
- 어플리케이션 서버 성능을 스케일업(t2.micro -> t2.medium)했을 때 성능은 얼마나 차이가 날까?
Summary
- 스케일업(t2 micro -> t2 medium) 이후, 레디스 적용한 로직의 성능은 큰 폭으로 상승
- 상세히 보자면 TPS는 689.3에서 1634으로 약 137% 상승했고, MTT는 1408에서 593.92로 약 57% Latency 감소
- WAS CPU 사용률 또한 99.6%에서 72.8%로 약 27% 적게 소모
- DB 사용률은 9%에서 16.2%로 상승한 부분은 특이사항
- 포화점은 VUser 141명에서 180명으로 약 27% 증가했고, TPS는 약 800대에서 1,600대로 2배 증가했다.
Background Information
Situation
- 부하 테스트 툴 nGrinder을 활용하여 경매 래플 어플리케이션 시스템의 서버 부하 테스트 진행중인 상황.
Current Experiment - test-pyramid-20230301-001
- test-pyramid-20230301-002 : 레디스 적용
Procedures
이번 실험의 핵심은 웹 어플리케이션 서버의 성능의 스케일업이다. t2 micro에서 t2 medium으로 업그레이드했다. CPU는 2개이고 메모리는 4GiB다.
- Total VUser : 1000(500 * 2)
- Agent : 2
- Duration : 15mins
- Ramp-Up : True
Data Recording & Analysis
테스트는 총 2회 진행할 예정이다. 동일한 findAll 로직을 두번 실행할 것이다.
- test-pyramid-20230301-001
- test-pyramid-20230301-002 : 레디스 적용
결과 분석
레디스를 적용하지 않은 20230301-001의 TSP는 당연하지만 약 153.3에 불과했다. 당연히 레디스를 적용하면 빠르고 적용하지 않으면 느리다.
레디스 없는 t2 micro vs. t2 medium
t2medium으로 스케일업한 20230301-001이 얼마나 성능이 개선되었는지 알려면 t2.micro로 스케일업한 테스트 결과와 비교해야 할 것이다.
VUser가 동일한 비교 대상을 찾지 못했다. VUser는 다르지만 같은 쿼리를 사용하는 테스트 결과와 비교해보겠다.
- test-pyramid-20230224-001(t2.micro)
- TSP 144.8
- Latency 251.78
- WAS CPU % : 27.7%
- DB CPU % : 83%
- test-pyramid-20230301-001(t2.medium)
- TSP : 153.3
- Latency : 6313
- WAS CPU % : 35.4%
- DB CPU % : 99.4%
medium의 TSP는 153.3로 micro보다 약 8 TPS 높지만 큰 차이라고 볼 수는 없다. 조금 이해가 가지 않는 부분은 MTT와 리소스 사용율이다. Latency의 지표로 사용하는 MTT는 스케일업 이전에는 약 251 이였는데, 스케일업 이후에는 6313까지 상승했다. 게다가 WAS CPU 사용률은 27.7%에서 35.4%로 스케일업 이후 약 8% 상승했고, DB CPU 사용률도 약 15% 상승한 99.4%, 거의 DB를 최대한으로 사용하고 있었다.
- DB CPU 사용률이 상대적으로 높은 이유는 VUser가 상대적으로 높고 I/O 작업이 DB에 많은 부하를 주기 때문으로 추정된다. 따라서 I/O작업을 최대한 줄일 필요가 있다.
- WAS CPU 사용률은 VUser 수의 차이로 인해 나타난 결과인 것으로 보인다
- Latency의 경우 아래 MTT 그래프를 보면 적정 수준에 도달한 이후 MTT가 평균적으로 6000-7000 사이 구간에 머물러있다. VUser 1000명으로 설정한 medium 테스트가 VUser 40명으로 설정한 micro 테스트 대비 상대적으로 표본이 과도하기 때문에 Latency의 오차가 큰 것으로 분석한다.
- 결론은 비교 대상이 적절하지 않았다는 평가를 내릴 수 있다. 다음에는 VUser 수도 동일하게 맞춰서 비교 대상을 선정할 필요가 있다.
다음 분석으로 넘어가자.
레디스 적용한 t2 micro vs. t2 medium
이 2개는 동일한 VUser 1000 명을 기준으로 테스트했기에 왠지 흥미로운 인사이트가 나올 것 같다.
- test-pyramid-20230227-006(t2micro)
- TPS : 689.3
- MTT: 1408
- WAS CPU 사용률 : 99.6%
- DB CPU 사용률 : 9%
- test-pyramid-20230301-002(t2medium)
- TPS : 1634
- MTT : 593.92
- WAS CPU 사용률 : 72.8%
- DB CPU 사용률 : 16.2%
t2medium의 TPS는 1634로, 689.3 TPS인 t2micro 대비했을 때 여유롭게 잡아서 약 1,000 TPS 차이가 발생했다. 시간당 처리량(Throughput)은 스케일업 이후 약 137%의 성능이 개선되었다.
MTT는 스케일업 이전에는 1408이었는데 반해, 스케일업 이후에는 593.92로 Latency는 약 57% 감소했다.
또 흥미로웠던 지표는 WAS CPU 사용률이었는데, t2micro는 99.6%를 사용했던 반면 t2medium은 72.8% 를 사용했다. 전자의 CPU 사용률이 99.6%인 이유는 Redis의 영향 때문이라고 생각하는데 아직 그 증거를 찾진 못했다. Redis 적용 이후에 항상 99%대를 사용해왔으니 당연히 Redis 때문일 것이라 생각했다. 그런데 t2 medium의 CPU 사용률이 72.8%에 불과한 점을 보니 CPU에는 Redis 뿐만 아니라 다른 작업들도 고려해야 하겠다는 생각이 들었다. 이는 추가로 공부를 해볼 생각이다.
어쨌든 정리하면 이렇다.
- 스케일업(t2 micro -> t2 medium) 이후, 레디스 적용한 로직의 성능은 큰 폭으로 상승했다.
- 상세히 보자면 TPS는 689.3에서 1634으로 약 137% 상승했고, MTT는 1408에서 593.92로 약 57% Latency가 축소되었다.
- WAS CPU 사용률 또한 99.6%에서 72.8%로 약 27% 덜 사용했다
- DB 사용률은 9%에서 16.2%로 상승한 부분은 특이사항이다. 테스트 모니터링 중 일시적으로 캐싱이 안되서 DB I/O 작업이 진행되는 순간이 4-5초 정도 있었다. 이 부분은 Redis max 옵션과 관련된 이슈인거 같은데, 이때 발생한 I/O로 인해 DB의 CPU 사용률이 일시적으로 영향을 받았기 때문으로 추정된다.
포화점 비교
그래프를 2개 가져왔다. 동일한 로직을 수행하지만 위는 t2 micro이고 아래는 t2medium이다. 데이터가 부족하지만 포화점을 대략적으로 파악하기에 충분하다고 판단되어서 그래프로 표현했다.
t2 medium으로 바꾸었을 때 관측되는 유의미한 변화는 포화점이 발생하는 지점의 Throughput과 VUser 수다. t2 micro의 경우, 포화점으로 정의한 부분은 TPS 약 800대, VUSer 141명이었다. 반면 t2 medium은, 포화점이 TPS 약 1600대로 스케일업 이전 대비 약 2배 상승했고 VUser수는 180명으로 이 또한 40명 상승했다.
이를 음식점에 비유하자면, 초기 식당의 시스템(t2 micro)에서는 동시 방문 손님이 141명을 넘어가면 주방의 캐파를 모두 쓰는 상태가 되고 이때의 처리량은 약 800TPS다. 반면 식당을 업그레이드 하니, 141명이 아니라 180명이 된 이후에야 식당의 캐파를 모두 쓰게 되고 이때 처리량은 이전보다 2배 향상된 1600TPS다.
Discussion
Conclusion
- 스케일업(t2 micro -> t2 medium) 이후, 레디스 적용한 로직의 성능은 큰 폭으로 상승
- 상세히 보자면 TPS는 689.3에서 1634으로 약 137% 상승했고, MTT는 1408에서 593.92로 약 57% Latency가 축소됨
- WAS CPU 사용률 또한 99.6%에서 72.8%로 약 27% 덜 소모딤
- DB 사용률은 9%에서 16.2%로 상승한 부분은 특이사항
- 포화점은 VUser 141명에서 180명으로 약 27% 증가했고, TPS는 약 800대에서 1,600대로 2배 증가했다.
Reference
Appendix
test-pyramid-20230301-001
nGrinder Report
App Server
RDS
nGrinder Agent 1
nGrinder Agent 2
test-pyramid-20230301-002
Application Server
RDS
nGrinder Agent 1
nGrinder Agent 2
'Log > Experiment' 카테고리의 다른 글
exp009_Redis Cloud 적용 여부에 따른 성능 변화 관찰 (0) | 2023.03.02 |
---|---|
exp008_PM2 클러스터 모듈 적용에 따른 로직 성능 변화 관찰 (0) | 2023.03.02 |
exp006_Redis 적용 로직 VUser 변동에 따른 성능 비교 (0) | 2023.03.01 |
exp005_Redis 적용 후 조회 성능 변화 관찰 실험 (0) | 2023.02.27 |
exp004_동일한 로직을 다른 시간대에 테스트하여 성능 차이 비교 (0) | 2023.02.27 |
댓글