성능 테스트

성능 테스트를 하는 이유

서비스를 오픈했는데 운이 좋아서 사용자가 엄청나게 증가할 수 있다. 서버는 그만큼 많은 요청을 받고 요청들을 처리하기 위해서 서버의 자원을 사용해야 한다. 하지만 서버의 자원은 한정적이고, 만약 자원이 무한하다면 IT 회사들은 인프라에 투자할 필요가 없을 것이다.

그럼 당연히 사용자가 많을 때, 트래픽을 감당하기 위해서는 얼마나 많은 서버가 필요할지에 대한 고민을 해야 한다. 막연하게 서버를 증설하는 것은 불필요한 비용이 발생할 것이다. 그래서 성능 테스트가 필요하다고 생각한다. 성능 테스트를 통해서 그 결과를 가지고 사용자의 수와 요청을 계산해서 얼마나 많은 서버가 필요할지에 대해서 조금은 예측 가능할 것이다.

성능 테스트가 필요한 상황음 다음과 같을 것이다.

• 비효율적으로 동작하는 로직이 존재할 경우 (메모리 정리가 잘되지 않아 지속적인 GC 발생)

• DB와 같은 저장소에 대한 성능 개선 (Index, 데드 락, .. etc)

• 시스템 설계 개선 : 시스템 구조가 바뀌어야 하는 상황. (캐시 필요, 비동기 구조, Circuit Breaker, etc..)

성능 테스트 종류

1. 성능 테스트 (Performance Test)

성능 테스트는 소프트웨어, 시스템 또는 애플리케이션의 성능을 평가하는 테스트 방법이다. 이 테스트는 시스템이 특정 작업을 처리하는 데 걸리는 시간, 응답 시간, 처리량, 자원 사용량 등을 측정하여 시스템의 성능과 안정성을 평가한다.

페이지 응답 시간, 메모리 사용율, 요청에 대한 처리 시간 등을 측정하고 시스템 성능을 개선하는 것을 목표로 한다.

사용되는 지표는 다음과 같다.

• 응답 시간 (Response TIme) : 요청하고 응답이 오기까지의 걸리는 시간

• 처리량 (Throughput) : 단위 시간당 시스템이 처리할 수 있는 작업의 수, 만약 서버가 초당 100개의 요청을 처리하면 처리량을 100이라고 말할 수 있다.

• 자원 사용량 분석 (Resource Utilization Analysis) : CPU, 메모리, 디스크 공간과 같은 사용량을 분석

성능 테스트는 소프트웨어나 시스템의 성능을 개선하고 최적화하는 데 도움이 되며, 예상치 못한 성능 문제를 발견하고 해결하는 데 도움이 됩니다. 이를 통해 사용자 경험을 향상시키고 시스템의 안정성을 보장할 수 있습니다.

성능 테스트는 부하 테스트와 스트레스 테스트로 나뉜다.

2. 부하 테스트 (Load Test)

시스템이 임계치에 도달하기 전까지 부하를 지속적으로 증가시키고, 병목 현상을 확인해서 목표치까지 개선하는 것이 목적이다. 이를 통해 SLA(Service Level Argreement)를 설정할 수 있다.

• SLA : 서비스의 성능과 품질을 정의하고, 이를 평가하고 유지하기 위한 명확한 기준

결국 부하 테스트는 예상되는 작업량(특정 부하)을 처리 가능한지 확인하고, 응답 시간과 처리량과 같은 지표를 평가하여 병목 현상을 식별하고 최적화하는 것이다.

목적:

시스템이 에상되는 정상적인 트래픽 범위 내에서 잘 동작하는지, 범위 내에서 최적의 성능을 유지할 수 있는지를 측정하는 데 중점을 둔다.

예를 들어, 100명의 동시 사용자를 처리할 수 있는 시스템이 있을 때, 부하 테스트에서는 100명의 사용자의 동시 요청을 성능 저하 없이 응답 시간이 일정하게 유지되는지를 측정. 처리할 수 없는 경우 성능 최적화(오토스케일링, 리소스 확장 등)를 진행

3. 스트레스 테스트 (Stress Test)

시스템을 한계점까지 밀어붙이는 테스트이다. 과부하 상태에서 어떻게 동작하는 지 확인하고 개선하는 것이 목적이다. 예를들어 시스템의 한계점을 확인하고 어떤 조건에서 시스템이 실패하는 지에 대해 파악하고 개선하는 것이다.

부하 테스트와 유사하게 보이지만 다음과 같은 차이점이 있다고 생각한다.

• 부하 테스트 : 예상 범위 안에서 작업을 처리할 수 있는지 확인하고 성능을 최적화하는 것을 목표로

• 스트레스 테스트 : 예상치 못한 극단적인 상황에서 시스템의 한계를 확인하고 문제를 해결하는 것을 목표로

목적:

과도한 트래픽을 발생시켜 시스템의 한계를 확인한다. (극한의 조건에서 어떻게 동작하는지 확인)

이를 통해 시스템의 한계점, 취약점 드응ㄹ 파악하고, 복구 능력을 강화한다.

즉, 의도적으로 비정상적인 부하나 리소스 부족 상황을 만들어내고 복구 능력과 데이터 손실 등을 확인한다.

예를 들어, 이커머스 서비스에서 블랙프라이데이 세일을 진행하여 평소보다 100배 많은 트래픽을 예상한다. (100 * 100 = 10,000)

동시 사용자 8,000명 이상을 처리할 때 응답 시간이 느려지고 CPU 사용률이 95%를 초과한다면, 문제가 발생하는 지점을 파악하고 서버 증설 및 최적화 조치를 시행할 수 있다.

4. 스모크 테스트 (Smoke Test)

스모크 테스트트 개발 초기에 수행되는 기본 테스트 중 하나이다.

간단히 얘기해서 핵심 기능들이 제대로 동작하는지 확인하는 테스트이다.

성능 테스트 지표

1. 처리량 (Throughout) : 초당 처리 가능한 작업

• RPS(Request Per Sceond), 1초에 처리하는 요청 수

처리량은 단위 시간 동안 몇 건의 요청을 처리할 수 있는지를 의미한다.

단위 시간은 보통 1초로 설정하고 주로 TPS(Transaction Per Second) 단위를 사용한다. 여기서 트랜잭션은 웹 애플리케이션에서 HTTP 요청에 대한 응답을 의미하지만, HTTP가 아니더라도 다른 분야에서 상황에 맞게 사용된다.

어떤 API가 1초 동안 1000개의 요청을 문제없이 처리한다면 이 API의 Throughput은 1000TPS 이상으로 본다.

서버 구조가 위 이미지와 같을 때, 현재 처리량은 서브시스템 중 가장 낮은 20 RPS가 된다.

다른 곳의 성능을 향상시켜도 DB와의 처리량이 개선되지 않는다면 큰 의미가 없다. 그러므로 전체 성능 향상을 위해서라면 가장 낮은 곳을 파악하고 개선해야 한다.

1. Latency(응답 시간)

네트워크에서 데이터를 보내는 측과 받는 측 간의 소요 시간을 나타낸다. 즉 요청을 받고 나서 응답할 때까지의 시간을 의미한다. 요청을 처리하는 동안의 대기 시간도 포함된다.

요약해서, 지연시간은 요청 한 건의 처리 시간을 의미한다. 어떤 요청이 처리되어서 사용자에게 응답이 되기까지 1초가 걸린다면 이 요청의 Latency는 1초이다. 서비스나 기능에 따라서 사용자가 기대하는 지연시간은 달라질 것이고, 개발자는 목표로 하는 지연시간을 사용자의 기대에 맞춰야한다.

처리량은 일정 시간동안 몇 건이나 처리할 수 있는지를 의미하고, 지연시간은 한 건이 얼마의 시간안에 처리되는지를 의미한다.

위 그림을 예시에서 RPS를 ms로 볼 때, 클라이언트가 서버에 요청을 보내고 받는 시간은 총 170ms이다.

어느 곳을 개선해도 총 응답 시간은 개선될 것이다. 또, 처리량과 밀접한 연관이 있다.

만약 처리량이 개선되면 응답 시간도 줄어들 것이다.

성능 측정 지표

성능을 측정할 때는 처리량과 지연시간을 모두 활용해야 한다.

목표 : 초당 500개의 요청(처리량)이 들어올 때 99% 요청이 100ms(지연시간) 미만으로 처리되어야 함.

두 개의 지표를 함꼐 사용하는 이유는, 일반적으로 처리량이 낮으면 지연시간이 낮고 처리량이 높으면 지연시간이 함께 높아지는 경향이 있다.

• 처리량이 많아서 서버가 바빠지면 자원이 부족할 것이고 대기시간이 생길 것이다.