exp006_Redis 적용 로직 VUser 변동에 따른 성능 비교

Title

exp006_Redis 적용 로직 VUser 변동에 따른 성능 비교

Research Question

Redis를 적용하면 어플리케이션 전체 시스템 성능이 상승한다는 점을 알았다. 그렇다면 동시접속자 수 (VUser)가 상승함에 따라 어플리케이션과 DB의 성능은 어떻게 바뀔까?

Summary

• 현재 어플리케이션의 성능이 정체되기 시작하는 포화점은 VUser 약 141명
• 이 포화점 지표를 기반으로 어플리케이션 성능을 높일 수 있는 옵션들을 리서치하고 단계별 실행 계획을 세울것

Background Information

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

Procedures

Data Recording & Analysis

테스트 개별적으로 뜯어보기

서버에 Redis를 적용한 Raffle findAll 요청 시, 동시 접속자에 따라 성능이 어떻게 달라지는지 알아보기 위해 간단히 Throughput과 Latency 기록해보았다. Throughput은 TPS 기준, Latency는 Mean Test Time 기준이다.

• TPS : TPS는 VUser 수에 무관하게 약 680-790대 내에서 제한된 변동이 발생
• Errors : VUser 1,000명과 1,500명 사이부터 에러 발생이 증가한다
• Latency : VUser 1000명부터 Latency가 1000ms 초과되었음. 400-1000 사이에 1000ms 초과 되는 지점이 있을 것으로 추정
• Active Users 수(Active users = TPS * Response Time)는 VUser 1000부터 약 10만에 근접하기 시작했다

위 6개 테스트의 주요 지표들을 그래프로 표현해보았다. 6개 테스트에서 나타난 TPS 지표들은 VUser의 수와 무관하게 680-790대 사이를 유지한 반면, Latency는 VUser 수가 증가함에 따라 함께 증가했다. 그래프 기울기는 완만해보이지만, 사실 Vuser의 데이터(40 - 400 - 1000 - 1500 - 2000 - 4000)의 분포를 고려하면 실제 그래프의 기울기는 조금 다른 형태일 것이다.

이 그래프는 에러 발생 건수 지표를 추가로 표현한 그래프다. VUser 1000까지는 비록 Latency가 1408까지 상승하긴 했지만 Error 발생률이 0%였다. 하지만 VUser 1,500의 경우 에러가 총 547건 발행하며 에러 발생률 0.1%을 기록했다. Latency가 심화됨에 따라 Error의 빈도 수도 함께 높아졌다.

여러 테스트들을 종합한 그래프를 보고나니 개별 테스트의 그래프가 어떨지 궁금해졌다. VUser 수에 따라 각기 다른 그래프들은 과연 유사한 포화점(Saturation Point)를 가질 지도 궁금하기도 했다.

참고로 개별 데이터들의 데이터는 nGrinder에서 CSV 파일로 내려받을 수 있다.

이는 VUser 4000을 테스트했던 test-20230227-004의 테스트 로데이터다.

VUser 증가에 따라 처리량(TPS)도 꾸준히 증가하다 750을 넘어서면 처리량이 증가하지 않고 일정 수준을 유지하게 된다. 이 두 방향의 접점이 되는 부분을 포화점/임계점(Saturation point)라 하는데, 이 부분을 좀 더 살펴보기 위해 그래프의 수평 축의 Max Value를 1000으로 줄여서 보도록 해보겠다.

그래프의 수평 축을 자르니 포화점을 파악하기가 쉬워졌다. VUser 157명 기점으로 처리량(TPS)의 증가세가 사라지고 일정 수준을 유지하게 된다. 포화점을 전후로 Light Load Zone과 Heavy Load Zone으로 나뉜다.

이 그래프는 Latency(Mean Test Time)를 추가한 그래프다. 0부터 1000단위까지 거의 직선에 가까운 상황인데 뭔가 인위적인 느낌이 든다. 아마도 전체 중 일부만 캡쳐해서 그런 것 같다.

그래프를 확대해보면 Latency는 Vuser 0-1500대 사이 구간에만 직선적이고 그 이후부터는 변동이 큰 것을 알 수 있다. TPS는 일정한데(처리량은 그대로) VUser가 증가하기에 자연스럽게 유저의 대기 시간이 길어지는 것이다. 이는 서비스의 품질 하락으로 가는 지름길이다.

여기서 궁금증이 생겼다. 과연 VUser 4000명이 아닌 VUser 2000명, 1000명 등 다른 상황에서도 비슷한 그래프가 그려질까? VUser 4000명 실험에서 VUser 157명이 임계점의 기준이 되었다면, VUser 2000명에서도 VUser가 157명에 가까운 지점에서 임계점이 생겨야되지 않을까? 왜냐하면 같은 성능인 어플리케이션에 테스트하기 때문이다.

두 그래프를 함께 비교해보자. 위 그래프는 VUser 4000명, 아래 그래프는 VUser 2000명일 때의 TPS 변화량을 나타낸다.

• 두 그래프의 차이점을 보자면, VUser 4000명일 때의 포화점(Saturation Point)는 750TPS 정도인 것에 반해, VUser 2000명일 경우 포화점이 606TPS에 불과하다. VUser가 낮은데 처리량도 더 낮아진다. VUser 4000이 상대적으로 부하가 더 잘 먹혀서 그런걸까?
• 두 그래프의 공통점을 보자면 Saturated users(유저 포화점?)이 비슷하다는 점이다. 두 실험은 점진적으로 부하를 올리는 Lamp up 방식으로 진행했는데 VUser 약 155명 지점을 기점으로 TPS의 상승세가 멈추는 Heavy Load Zone으로 진입했다.

Latency도 함께 확인해보자.

두 그래프의 그림은 거의 비슷하다. Latency가 TPS를 추월하는 지점은 Vuser 2000이 좀 더 이르긴 하지만. 하지만 Latency가 TPS를 초월하는 지점에서 어떤 인사이트를 얻을 수 있을지는 모르겠다.

다시 이 지점으로 돌아와보자.

비록 VUser 수가 다르지만 같은 조건에서 실험했기에 포화점의 분포가 유사했다. 

여기서 한가지 궁금증이 생겼다🧐. 현재 테스트들을 개별적으로 분석하고 있는데, 지금까지 했던 동일한 조건의 테스트들의 로데이터를 하나로 합치면 어떤 그래프가 나올지 궁금했다. 그리고 현재 Saturation Point 지점의 표본이 적어서 그래프의 꺾임 현상이 심한데, 더 많은 표본이 생기면 왠지 더 부드럽고 명확한 그래프를 얻을 수 있지 않을까 라는 생각을 했다.

테스트 합치기

지금까지 했던 6개의 데이터를 모두 취합해보자.

데이터들을 모으니 자그마치 2,636개의 표본을 얻을 수 있었다.

VUser수를 오름차순으로 정렬해준뒤 그래프를 생성해보자.

VUser 구간 0부터 4000 사이 기준으로 모든 TPS, Latency를 표현했다. VUser 1500대까지는 선형적으로 진행되다, 그 이후로는 Latency의 변동폭이 커지기 시작했다. 1500, 2000대에 집중적으로 Latency 변동폭이 커진 것은 데이터 수집 방식 때문인 것으로 추정된다. 2000대부터는 거의 데이터가 산탄총 마냥 흩어진다.

일단 이 그래프는 너무 넓다. 좀 좁혀 보자.

VUser을 1-4000명 구간에서 1-2000명 구간으로 좁혔다. 더 좁힐 필요가 있다.

VUser 0-500명 구간으로 좁혔다. 표본이 충분하다고 생각했는데 생각보다 아쉽다. 그래도 이 정도 좁히니 포화점의 위치가 눈에 보인다. 주요 지표드를 시각화 해보자.

이 그래프에서 VUser 141 지점을 기점으로 TPS가 더 이상 늘어나지 않는다고 보고 이 지점을 Saturation Point(포화점)으로 규정했다. 이 포화 지점의 VUser 수는 141명이다. VUser이 141명 넘어가는 시점부터 TPS가 더 이상 늘지 않는다고 볼 수 있다. TPS가 늘지 않는데 VUser이 늘어가니 Latency는 당연히 높아진다.

Conclusion

• 현재 어플리케이션의 성능이 정체되기 시작하는 포화점은 VUser 약 141명
• 이 포화점 지표를 기반으로 어플리케이션 성능을 높일 수 있는 옵션들을 리서치하고 단계별 실행 계획을 세울것

---

Reference

• https://parkbrother.tistory.com/entry/TPS-%EA%B3%84%EC%82%B0-%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95
• https://www.whatap.io/ko/blog/14/
• https://performance.tistory.com/8
• https://performance.tistory.com/3

Appendix

Test 1: test-pyramid-20230227-003

Plan

nGrinder Report

Application Server

RDS

nGrinder Agent 1

nGrinder Agent 2

Test 2: test-pyramid-20230227-004

VUser을 약 10배 수준인 4000으로 상승시키고 수행

nGrinder Report

Application Server

RDS

nGrinder Agent 1

nGrinder Agent 2

Test 3: test-pyramid-20230227-005

nGrinder Report

Application Server

RDS

nGrinder Agent 1

nGrinder Agent 2

Test 4: test-pyramid-20230227-006

nGrinder Report

Application Server

RDS

nGrinder Agent 1

nGrinder Agent 2

test-pyramid-20230227-007

nGrinder Report

Application Server

CPU 사용률 99.4 %

RDS

DB CPU 사용률 7%

nGrinder Agent 1

nGrinder Agent 2