본 글은 웹앱을 개발하고 해당 웹앱의 성능을 테스트 해야하는 이유와 테스트의 종류, 테스트 도구에 대해서 소개하고 있습니다.
서버 개발자가 아니라면, 이해하기 힘든 내용이 있을수도 있습니다.

서버 성능 테스트는 왜 해야할까?

---

백엔드를 만들어서 정상 동작한다고, 끝이 아닙니다.

서버 개발을 완료하고 해당 서버가 오류없이 동작한다고 해도, 실제로 사람들에게 서비스를 하는건 다른 영역입니다.

실제 서비스를 한다는 것은 여러 사람들이 동시에 해당 서버에 접속해서 작업을 진행할텐데, 그래서 사용자가 늘어나면 늘어날수록 서버에 부하가 발생하게 됩니다.

그리고 이 과정에서 문제점이 발견될 수 있습니다. 예를 들면 슬로쿼리나 락일 잡힌다거나, 스레드가 밀린다거나 등등 ...

서버 개발자는 이러한 문제점을 해결해서 동일 서버 사양에서, 더 많은 사용자에게 쾌적한 서비스 환경을 제공할 수 있어야 합니다.

제 경우에는, 제가 만든 어플리케이션은 동시에 얼마만큼의 사용자에게 제공할 수 있을지 궁금해서 시작하게 되었습니다.

성능 테스트(Performance Test)?

---

성능 테스트 종류

성능 테스트 하위에는 여러가지 종류의 테스트가 있습니다. 이 중에서 많이 수행하는 5가지 테스트를 소개하려고 합니다.

출처: net solutions

부하 테스트(Load Test)

특정한 부하를 제한 시간동안 부여. 일반적으로 한시간을 기준

지속성 테스트(Endurance Test)

특정한 부하는 오랜 시간동안 부여. 일반적으로 8시간 이상

스트레스 테스트(Stresss Test)

일반적인 부하 테스트보다 훨씬 높은 부하 상황에서 시스템 성능을 검증하는 테스트.
시스템 장애가 발생하는지, 또 사용 가능한 상태로 유지되는지, 또 부하가 정상 수준으로 돌아갈 때, 우아하게(gracyfully) 복구되는지 체크합니다.

최고 부하 테스트(Spike Test)

일순간 감당할 수 없을 만큼 부하를 주고, 웹 어플리케이션이 죽지 않고 동작하고 회복할 수 있는지 확인하는 테스트.

중단점 테스트(BreakPoint Test)

동시단말 사용자의 수를 점진적으로 증가시켜서, 시스템의 장애 지점을 결정하는 테스트.

주요 용어

테스트를 하면서 알고 있어야 할 용어를 소개하고자 합니다.

Users

서버를 사용중인 사람

Concurrent User: 언제든 부하를 줄 수 있는 사용자
Active User: 실제로 서버에 부하를 주고 있는 사용자

TPS(Trasaction Per Second)

일정 시간동안 얼마나 많은 요청을 처리할 수 잇는지 나타내는 지표

TPS는 성능 테스팅의 중요 지표로 활용됩니다.

Time

서비스를 사용하는 시간을 의미

Think Time: Response를 받은 뒤 실질적인 작업이 이루어지는 시간을 의미

클라이언트 입장에서, 요청을 보내고 응답을 받는 시점까지의 시간이 성능테스트 대상이 됩니다.

좋은 서버 성능이란?

어떤 서비스의 성능이 좋다는 것은 두가지 관점을 해석할 수 있습니다.
1. 사용자 입장에서, 요청에 대한 빠른 응답시간
2. 서버가 원하는 만큼의 사용자를 감당할 수 있음

이 두가지의 요청을 모두 만족해야 서비스의 성능이 좋다고 할 수 있습니다.

그리고 TPS와 User, Time간의 관계를 그래프로 나타내면 다음과 같습니다.

1. 만약 서버가 최대로 가질 수 있는 TPS가 정해져있다면, 유저가 늘어나면 TPS가 늘어나다가 한계점을 만나게 됩니다.
   • 이 경우에는 요청이 더 증가해도, TPS가 한계치를 넘어서서 증가하지 않습니다.
   • 실제로 동작시켜보면, 이러한 상황은 굉장히 이상적인 상황이라는 생각이 들게 될 것입니다. 왜냐면 ... 실제 서버는 TPS가 정해져있지 않고 다 처리하려고 할테니까요. TPS를 한정하도록 튜닝을 한 경우 이렇게 동작할 것 같습니다.
2. 유저가 늘어나게 되면, Time은 임계지점을 지나게 되면 빠르게 상승합니다.
   • TPS를 초과하는 User인 경우 요청을 보내고 응답을 계속 기다리게되고, 이는 User가 많을수록 더 증가합니다.
3. TPS가 증가하다보면 특정 지점에서 Time이 급증합니다.
   • 사실 이건 완전히 튜닝된 서비스를 기준으로 하는 것 같습니다. 왜냐하면, Time이 급증하는게 아니라, 해당 TPS이상으로 작업을 할 수 없는 상태이기 때문에 해당 TPS를 초과하는 경우는 없다는 것으로 이해했습니다.

성능 테스트 도구

---

실제로 우리가 성능 테스트를 해보려면, 해당하는 User의 요청을 만들어서 서버에 부하를 줘 봐야겠죠?

이러한 부하를 줄 수 있는 성능 테스트 도구들이 있습니다.

이러한 테스트 도구들은 원하는 만큼의 사용자 요청을 만들어서 서버에 직접 요청을 해주고, 해당 요청에 대한 응답을 확인하면서 오류 목록 및 테스트에 걸리는 시간 등 종합적인 점수를 제공해줍니다.

성능 테스트 도구는 아주 많지만, 그중 몇가지를 소개하고, 한가지로 테스트를 진행해본 내용을 첨부하도록 하겠습니다.

1. JMeter
2. nGrinder

두 가지를 고민했는데, 주변 사람들은 JMeter를 사용했습니다.
Apache에서 만들었고 여러 프로토콜/서버를 테스트할 수 있다고 합니다. 전세계적으로 많은 사람들이 사용하는 성능 테스트 도구라고 합니다.

저는 nGrinder를 이용해서 성능 테스트를 진행했는데, 사용한 이유는 Naver 오픈소스 프로젝트였고 우리나라에서는 많이 활성화되어 있다고 들었기 때문에 nGrinder로 진행하고자 했습니다. HTTP, REST를 테스트할 수 있는 환경이면 되었기 때문에, nGrinder로 선정하게 되었습니다.

nGrinder로 성능 테스트를 진행하면서, 발생한 예시를 소개하고자 합니다. 제 경우에는 EC2 프리티어를 이용해서 테스트를 진행했는데, 기본적인 성능이 너무 안좋아, 테스트를 하는게 의미가 없을 정도지만 일단 간단하게 테스트를 진행한 결과를 보여드리겠습니다.

1. GET 요청을 사용자 99명이 동시에 요청을 10개 보낸다는 가정으로 테스트를 진행해 보았습니다.

동시 접속하는 인원이 많아, TPS가 일정 이상으로 증가하면 서버가 멈추게 됩니다. :(
최고 TPS는 100개지만, 100개가 된 시점 뿐 아니라, 50개인 시점에서도 부하가 발생해서 멈췄습니다.

그래서 이번엔 사용자를 10명이 동시에 요청을 100개 보낸다는 가정으로 테스트를 진행해 보았습니다.

이 전보다는 수월하게 요청을 처리할 수 있었습니다. 하지만, 16초 지점에서, TPS가 0인 지점, 즉 서버에 큰 부하가 걸린 것을 확인할 수 있었습니다.

해당 내용을 분석하는 것은 로깅, 모니터링도 같이 진행해야 하지만, 지금 환경은 구축되어 있지 않았습니다. 그냥 이렇게 하는구나로 봐주시면 될 것 같습니다. :)

본격적인 성능 테스트는 EC2가 아닌 다른 컴퓨터나 디바이스를 사용해서 진행하고자 합니다. 해당 환경에서는 로깅과 모니터링 환경도 구축해서 진짜 성능 테스트를 수행하도록 하겠습니다. 그리고 추후 블로그로 해당 내용을 업로드 하도록 하겠습니다.

읽어주셔서 감사합니다.