[10분 테코톡] 이프의 성능 테스트 정리

응답 대기 시간 줄이기 위해서 어떻게 해야할까?

 

위와같이 사용자가 리퀘스트를 보냈고 리스폰스를 받는 과정속에서 사용자는 단순하게 서버한테 '나는 이때 줬는데 왜 이제서야 주냐? 너 왜 이렇게 나태하냐' 라고 한다면 서버는 할 말이 있다.

 

실제 인프라 내부에서는 위와같이 뒤에서 많은 요청과 처리과정이 있다. 첫번째 서버의 경우 서버2 한테 리퀘스트를 보내고 리스폰스 받을 때까지의 대기 시간이 존재한다. 대기시간을 받은 이후에 실제로 처리를 하고 다시 대기하고 다시 처리하게된다. 이 전체 프로세스 과정의 절반 이상이 대기 하느라 소요된 시간이고, 그 대기한 시간은 다른 구성요소들(서버2, DB)이 처리시간을 차지하고 있다. 대기시간을 제외한 실제 처리하는 시간이 해당 구성 요소가 차지하는 처리 시간이며 이 모든 처리시간이 합산된게 사용자가 대기하는 응답대기시간과 거의 유사하다. 그래서 처리 시간을 줄이면 결론적으로 전체 합산인 응답시간을 줄임으로써 목표하고자 하는 바에 도달할 수 있다.

줄이는 방법은 각각의 구성요소에 모니터링 시스템을 다 도입 해야한다. 그 이유는 리퀘스트와 리스폰스가 오고 가는 그 시점을 확인해서 얼마나 대기를 하고 얼마나 처리하는지 시간도 확인을 해야 한다. 또 메모리 관점이나 CPU 자원 관점에서 어느정도 트래픽을 처리하는지 성능을 제대로 확인하기 위해서는 각각의 구성 요소에 모니터링 두어 내부적으로 확인할 수 밖에 없다. 확인했을 때, 예를들어 DB의 경우 조회 기능에서 성능이 안 좋게 나온다고 하면 조회 쿼리를 개선하거나 인덱스를 걸어서 조회에 대한 처리시간을 극단적으로 줄일수도 있다. 다른 예로는 서버 같은 경우에 너무 과도한 객체가 생성되거나 불필요한 생성이 되어 GC에 의한 불필요한 지연이 발생한다고 했을 때, 코드 리팩토링 통해서 문제를 해결할 수 있다.

 

이런식으로 처리 시간을 줄인다면 응답 대기 시간을 줄일 수가 있다. 사용자 입장에서는 응답대기시간 줄어들었기 때문에
빠르게 응답을 주는 구나, 빠른 플랫폼이구나 하는 인식을 가지게 되고 좋은 서비스로 인식이 될 수 있다.

 

입소문을 타거나 아니면 정말 좋은 기능 비즈니스를 가지고 있으면 사람들이 몰리게된다. 서버는 한정된 자원이지만 사용자들은 가변적이다. 어떤 경우에는 적을 수 있지만 어떤 경우에는 기하급수적으로 늘어날수 있다. 그렇기 때문에 한정된 자원에 대해서 과도한 트래픽, 부하에 대해 계속 생각해야 된다.

 

부하로 인해 응답이 늦게 도달 할 수 있고 그로 인해서 응답 대기시간이 다시 길어지는 문제가 발생할 수 있다. 더 나아가서  과부하가 발생하면 장애가 발생해서 서비스 자체를 사용할 수 없는 문제가 발생할 수 있다. 이런 상황들을 사전에 방지하고 개선하기 위해서 부하 테스트, 스트레스 테스트를 해야한다.

 

부하 테스트는 서버가 어느 수치까지 부하를 견딜 수 있는지 임계치를 확인하고 그 임계치가 어떠한 병목현상으로 인해서 발생을 하는지와 그 병목 현상을 해결할 수 있는지 그리고 목표로 하고 있는 수치까지 끌어 올렸는지를 확인하는  것이 목적인다.(병목 현상을 확인하고 목표치까지 개선하는 것이 목적이다.)

스트레스 테스트는 앞서 확인한 부하 임계치 이상의 트래픽을 가해서 과부하 상태에서 서버가 어떻게 동작하는지, 장애가 발생했다면 그 장애에 어떻게 대처하거나 복구하는지 이러한 사후처리에 대해서도 확인을 한다.(과부하 상태에서 어떻게 동작하는지 확인하고 개선하는 것이 목적이다.)

 

부하 테스트 그래프를 보면 급증을 하다가 임계점 이후로 라인이 일직선으로 유지되는 구간이 보인다. 저 부분이 병목현상이 발생한 부분이다. 병목 현상은 간단히 말해서 사용자가 많이 들어와도 이 수치만큼 밖에 성능을 낼 수 없다는 것이다.

 

왼쪽에 있는 Y축이 수치는 TPS (Transaction Per Second), 단위 시간당 처리할 수 있는 양이다.

 

Little's Law 계산식은 우리가 목표로 하는 수치랑과 밀접한지 확인하는 계산식이다. 먼저 150명의 동시 접속자를 예상을 했다고 가정한다. 현재 TPS가 600라인에 있고, 응답 시간은 80ms이다. Think Time은 사용자가 생각하는 시간을 나타낸다. 생각하는 시간이란 요청을 처음 보내고 두번째 요청을 보낼 때 걸리는 시간을 의미한다. TPS, 응답시간, 생각시간으로 위에 나와 있는 식으로 계산하면 동시 사용자수가 350이 나와 부하테스트를 통과한다.

 

위 그래프는 특이사항들이 존재한다. 임계점을 기준으로 쭉 진행이 되다가 갑자기 끊어지는 부분이 생기고 복구가 되었다가 다시 끊어지고 그 다음 완전히 리스폰스가 날아오지 않는 현상이 발생했다.
음영처리된 두 부분을 Buckle Zone 이라고 한다.

* Buckle Zone : 시스템 과부하로 최대 처리량보다 더 떨어지는 구간/임계점 이후에 발생

 

Buckle Zone은 스트레스 테스트에서만 발생하는 것이 아니라 부하 테스트에서도 마찬가지로 발생을 하기 때문에 부하 테스트를 할 때는 길게 30분, 1시간 가까이도 해 보면서 Buckle Zone이 존재하는지 길게 탐지해볼 필요가 있다.

 

위 상황은 완전히 서버가 멈추는 상황이다. 
서버가 멈추는 현상에 대해서, 발생하는 시점에 관심 있어하는게 아니라 장애가 발생을 했고 그 이후에 자동 복구가 되었는지, 시스템이 마련 되어있다면 자동복구가 되었는지 등 확인하고, 자원 관점에서는 셧다운 과정에서 JVM이나  메모리들이 낭비가 된 건지 아니면 안전하게 해제되고 셧다운 된 것인지, Graceful ShutDown 여부 등을 확인한다. 결국은 장애가 발생했을 때 어떻게 대처하는지를 확인하는 것이다.

 

성능 테스트 종류

Stress Test, Breakpoint Test, Load Test, Endurance Test, Spike Test 등이 있다.

---

참고

https://www.youtube.com/watch?v=IcSdPhxCn9Y&ab_channel=%EC%9A%B0%EC%95%84%ED%95%9C%ED%85%8C%ED%81%AC