exp017_nGrinder script 수정 후 VUser-게시글 성공률 상관관계 관찰 재실험(No ramp-up)

Title

exp017_nGrinder script 수정 후 VUser-게시글 성공률 상관관계 관찰 재실험

Research Question

nGrinder 스크립트를 수정하여 에러로 인한 테스트 중지 문제를 해결했다. 스크립트 수정 이후 VUser 변화에 따른 게시글 생성 성공률은 어떨까? 추가로 netstat으로 상세 모니터링을 진행하면 어떤 인사이트를 얻을 수 있을까?

Summary

• 현재 시스템은 VUser 600명이 동시 10건의 게시글 생성하는 수준까지는 안정적으로 처리중
• 하지만 600명이 넘어가는 순간 급격하게 증가해왔던 Latency 증가폭이 둔화되는 대신 게시글 생성 실패율이 급증
• 이는 시스템의 처리 한계를 넘어섰기에 요청 처리를 더 이상 수행하지 못하는 것으로 추측됨
• 따라서 VUser 600명에 도달하기 전에 시스템을 확장하는 등 조치를 취해야 할 것으로 판단됨

Background Information

부하 테스트 툴 nGrinder을 활용하여 경매 래플 어플리케이션 시스템의 서버 부하 테스트 진행중인 상황

일정한 지점에서 테스트가 지속 멈추는 형상을 이상하게 여겨서 nGrinder 스크립트를 수정한 결과 테스트가 잘 진행되는 것을 발견했다. 기존의 insert 관련 테스트에서 일정 Vuser 이상이 넘어가면 정상적으로 테스트가 진행되지 않는 문제를 해결한 뒤, 다시 VUser 수에 따른 게시글 성공률 상관관계 분석을 위해 다시 데이터를 얻기 위한 실험을 진행하기로 했다.

Procedures

이전 실험과의 큰 차이점 Ramp-up 옵션을 껐다는 점이다. 점진적으로 과부하를 주는 것이 아니라 동시에 수 천명의 유저가 접속하는 상황을 가정했다.

Data Recording & Analysis

총 13회의 실험 결과 데이터들.

테스트는 총 13회 진행했다. 5000 - 10000 게시글 요청 수 구간 사이에는 없었는데, 이 사이 구간부터 급격히 생성 실패율이 증가하는 구간임을 발견하여 추가로 4개의 추가 실험(보라색 음영 표시)을 진행했다.

Vuser이 증가할 때마다 게시글 생성 성공률 변화 추이를 표현하면 이렇다. run count는 10으로 고정해두었으니, VUser 1000명은 총 10000개 생성 요청, 2000명은 총 20000개 생성 요청 이렇게 생각하면 된다.

잘 보이지 않지만 VUser 600명(총 게시글 요청 수 6,000건)까지는 문제없이 처리하다 700명대가 되면 89%까지 게시글 생성 성공률이 하락한다. 10개 중 1개가 날라간다는 말이다. 이후 1000명대까지 실패율 급증하는 속도가 급격히 증가했다.

TPS와 Latency 기준으로도 한번 보자.

TPS는 VUser 0-1000명 사이에 등락이 있긴 하지만 완만한 변동을 끝까지 유지한다.

반면, Latency는 처음부터 급격하게 증가하는 것을 볼 수 있는데 이는 Ramp-up 옵션이 아니여서 동시에 하기 때문이다. 포병에서 말하는 소위 TOT(Time On Target) 방식으로 작동하기 때문에 점진적으로 증가하지 않는다.
Latency가 VUser 600명대 즈음 도달했을 때 지연속도 증가율이 꺾인다. 한마디로 급격하게 지연속도가 증가하다가 이제는 완만하게 증가한다는 말이다. 흥미로운 점은 이 지점부터 게시글 생성 실패 건수가 급격히 증가하여 지붕을 뚫어버린다는 점이다.

VUser 600명 기준으로 20:26분경에 실험했던 20230308-30의 리소스 사용 데이터다. 이번 실험에서는 상세한 모니터링을 위해 netstat을 도입했다.

CPU 사용률은 76% 이상이다. 프로세스 대기 시간도 급상승했다.

18:25분경 진행했던 20230308-024 테스트(VUser 1000명)의 그래프와도 비교해보자.

CPU 사용률는 80.7%까지 상승했는데 VUser 600명 대비 3% 상승한 것에 불과하다.

VUser 1000명의 프로세스 대기 시간의 경우 180대까지 상승했었던 VUser 600명 그래프보다 70 더 높은 250대까지 상승했다. VUser 600명을 처리할 때보다 VUser 1000명을 처리할 때 프로세스 대기 시간이 더 증가했다.

CPU 사용률이 왜 조금씩밖에 증가하지 않지?라는 생각이 들어서 테스트 결과를 보았는데 흥미로운 점을 발견했다. VUser이 증가할 수록 CPU 사용률은 오히려 감소한다. 80% 대 이상으로는 잘 올라가지 않는다.

Discussion

netstat을 사용하면서 알게된 사실인데, netstat과 aws의 모니터링 지표가 큰 차이가 난다는 점이다. netstat에서는 76%를 사용중이라 나오는데 AWS에서는 서버 CPU 사용률이 10%에 불과하다고 나왔다. 무슨 다른 셈법이 있는 것 같은데, 기존에 aws의 모니터링 데이터로는 도저히 설명이 되지 않았던 부분이 netstat을 사용하고 나서 해소가 되었다.

Conclusion

현재 시스템은 VUser 600명이 동시 10건의 게시글 생성하는 수준까지는 안정적으로 처리를 하고 있다. 하지만 600명이 넘어가는 순간 급격하게 증가해왔던 Latency 증가폭이 둔화되는 대신 게시글 생성 실패율이 급증한다. 이는 시스템의 처리 한계를 넘어섰기에 요청 처리를 더 이상 수행하지 못하는 것으로 추측된다. 따라서 VUser 600명에 도달하기 전에 시스템을 확장하는 등 조치를 취해야 할 것으로 판단된다.

Reference

Appendix