개발자들이 자신이 만든 프로그램을 잘 만들었다고 판단하는 기준은 무엇일까? API 서버가 성능이 좋다, 잘 작동한다는 의미는 무엇일까?
실제로 사용자들이 사용을 할 때, 매끄럽게 오류 없이 안정적으로 작동한다면 잘 만든 프로그램이라 할 수 있다. 하지만 사용자가 없는 개발 단계에서 잘 만든 프로그램을 판단하기 쉽지 않다. 일반적으로 API 서버 성능이 좋다는 의미는
많은 사람이 사용해도 API 응답이 빠르고 안정적이다.
라고 할 수 있다. 하지만 문장 안에서는 정량적으로 측정되지 않은 모호한 기준만이 존재한다. 많은 사람이라는 건 얼마나 많은 사람이며, 응답이 빠르다는 것은 몇 초 내로 수행되어야 빠른 것이고, 안정적이라는 기준은 무엇인가?
이러한 모호한 기준을 명확하게 판단하기 위해 API 성능 테스트를 하는 것이며, 테스트 결과 지표를 기반으로 개발자는 성능이 좋은 API 서버를 판단할 수 있다.
- 서버 A는 10명의 사용자가 동시에 API 서버에 요청을 보냈을 때, 모두가 1초 안에 응답을 받는다.
- 서버 B는 100명의 사용자가 동시에 API 서버에 요청을 보냈을 때, 10초 안에 모두가 응답을 받는다.
첫 번째 예시와 다르게 구체적인 사용자 수와 속도가 나왔지만, 위 두 가지 테스트 결과를 통해 어느 서버가 더 좋은 성능을 가지고 있는지 판단하기 어렵다. 이는 기준이 명확하지 않기 때문이다. 따라서, 성능을 평가할 때 자주 사용하는 몇 가지 개념을 알아보자.
처리량 (Throughput)
단위 시간당 통신 채널을 통해 성공적으로 전달된 데이터 양, 일반적으로 초당 요청 수(RPS)로 측정.
|--------------- 시간 (초) ---------------|
|----------------------------------------|
| 요청 1 | 요청 2 | 요청 3 | ... | 요청 N |- 처리량 = 총 요청 수 / 총 시간 (초)
- 1000개의 요청이 10초 동안 처리되면, 처리량 = 1000 / 10 = 100 RPS
- 평가 기준: 예상되는 최대 사용자 수를 고려하여 설정한다. 예를 들어, 하루 최대 100만 요청을 예상하면 초당 약 11.57 RPS가 필요하므로 안전한 범위를 설정한다.
응답 시간 (Response Time)
요청이 서버에 전달된 시점부터 응답이 완료된 시점까지의 총 시간, 네트워크 지연 시간과 서버 처리 시간을 포함.
|--- 요청 송신 ---|--- 처리 시간 ---|--- 응답 수신 ---|
|------------------- 응답 시간 -------------------|- 응답 시간 = 응답 수신 시간 – 요청 송신 시간
- 요청이 0초에 송신되고 응답이 2초에 수신되면, 응답 시간 = 2 – 0 = 2초
- 평가 기준: 사용자의 기대치를 고려하여 설정한다. 일반적인 웹 애플리케이션의 경우 1-2초 이내가 적절하다고 한다.
지연 시간 (Latency)
사용자 동작과 서버 응답 사이의 지연 시간, 요청 처리 시간을 제외한 시간.
|--- 요청 송신 ---| 지연 시간 |--- 처리 시간 ---|--- 응답 수신 ---|- 지연 시간 = 전체 응답 시간 – 서버 처리 시간
- 전체 응답 시간: 2초 (응답 수신 시점 – 요청 송신 시점) 서버 처리 시간: 1.5초 지연 시간: 2초 – 1.5초 = 0.5초.
- 평가기준: 네트워크 및 서버의 지연 허용치를 고려하여 설정한다. 낮을수록 좋으나, 물리적인 제약을 감안하여 설정하는게 좋다.
초당 히트 수 (Hits per Second)
서버가 초당 받는 요청 수.
|-------------- 시간 (초) --------------|
|--------------------------------------|
| 히트 1 | 히트 2 | 히트 3 | ... | 히트 N |
- 초당 히트 수 = 총 히트 수 / 총 시간 (초)
- 500개의 히트가 10초 동안 발생하면, 초당 히트 수 = 500 / 10 = 50 hits/second
- 평가 기준: 예상되는 트래픽 피크를 기반으로 설정한다. 예를 들어, 프로모션 기간 동안 예상되는 최대 트래픽 수준을 반영한다.
초당 트랜젝션 수 (TPS)
시스템이 초당 처리할 수 있는 완료된 트랜젝션 수.
|------------------- 시간 (초) -----------------------|
|----------------------------------------------------|
| Transaction1 | Transaction2 | ... | TransactionN |- TPS = 총 트랜젝션 수 / 총 시간 (초)
- 300개의 트랜젝션이 10초 동안 완료되면, TPS = 300 / 10 = 30 TPS
- 평가기준: 시스템의 주요 트랜젝션 처리 용량을 고려하여 설정한다. 예를 들어, 금융 거래 시스템의 경우 높은 TPS를 요구한다.
초당 오류 수 (Errors per Second)
시스템이 초당 발생하는 오류의 수를 나타낸다. 오류는 요청 처리 중 발생하는 예외, 실패한 트랜잭션, 잘못된 응답 등을 포함한다.
|------------ 시간 (초) ------------|
| Error1 | Error2 | .... | Error N |
- 초당 오류 수 = 총 오류 수 / 총 시간 (초)
- 100개의 오류가 50초 동안 발생하면, Errors per Second = 100 / 50 = 2 오류/초
- 평가 기준: 높은 안정성이 필요한 시스템이라면 초당 0.01 오류 이하, 일반적인 웹 애플리케이션이라면 초당 0.1 오류 이하
성능 테스트 용어 정리
| 용어 | 정의 | 수식 |
|---|---|---|
| 처리량 (Throughput) | 단위 시간당 성공적으로 처리된 요청의 수, 일반적으로 초당 요청 수(RPS)로 측정 | 처리량 = 총 요청 수 / 총 시간 (초) |
| 응답 시간 (Response Time) | 요청이 서버에 전달된 시점부터 응답이 완료된 시점까지의 총 시간 | 응답 시간 = 응답 수신 시간 – 요청 송신 시간 |
| 지연 시간 (Latency) | 사용자 요청이 서버에 도달하여 응답이 시작되기까지의 시간 | 지연 시간 = 응답 시작 시간 – 요청 송신 시간 |
| 초당 히트 수 (Hits per Second) | 서버가 초당 받는 요청 수 | 초당 히트 수 = 총 히트 수 / 총 시간 (초) |
| Transaction Per Second (TPS) | 시스템이 초당 처리할 수 있는 완료된 트랜젝션 수 | TPS = 총 트랜젝션 수 / 총 시간 (초) |
| 초당 오류 수 (Errors per Second) | 시스템에서 초당 발생하는 오류 수 | 초당 오류 수 = 총 오류 수 / 총 시간 (초) |
성능 테스트의 용어를 기반으로 성능이 좋은 API 서버에 대한 평가 기준표를 예시로 들어보자면
- 처리량 (Throughput): 초당 1000 RPS 이상을 유지해야 한다.
- 응답 시간 (Response Time): 평균 응답 시간이 2초 이내여야 한다.
- 지연 시간 (Latency): 지연 시간이 500ms 이내여야 한다.
- 초당 히트 수 (Hits per Second): 초당 500 히트 이상을 처리할 수 있어야 한다.
- 초당 트랜젝션 수 (TPS): 초당 50 TPS 이상을 유지해야 한다.
- 초당 오류 수 (Errors per Second): 초당 0.01 오류 이하를 유지해야 한다.
라고 표현할 수 있을 것이다. 이러한 용어들과 서비스에서 요구하는 기준 설정하고 테스트함으로써 API 서버의 성능을 평가한다. 이를 통해 서버가 실제 운영 환경에서 요구되는 성능을 충족하는지 확인할 수 있다. 또한, 상황에 따라 성능 테스트의 목표의 차이가 있으므로 중점적으로 관찰해야할 사항도 다르다. 아래 예시를 참고해보자.
🤔성능 테스트: 앱 출시 이전 개발한 API 속도가 적정한지 대략적으로 측정하고 싶어!
목표 설정
기본 성능 기준을 설정한다. 출시 이전 테스트이므로 적당하게 1초당 1000 RPS를 유지할 수 있는지 확인한다.
테스트 시나리오 작성
100 RPS, 500 RPS, 1000 RPS 등으로 증가시키며 테스트한다.
성능 지표 측정
1. 처리량 (Throughput): 목표는 초당 1000 RPS로 설정한다.
2. 응답 시간 (Response Time): 사용자가 느끼기에 빠른 응답을 제공하기 위해 평균 응답 시간은 2초 이내로 설정한다.
3. 지연 시간 (Latency): 네트워크 지연 등을 포함한 최대 시간으로, 지연 시간은 500ms 이내로 설정한다.
4. 초당 히트 수 (Hits per Second): 초당 500 히트 이상을 처리할 수 있어야 한다.
5. 오류 수 (Errors per Second): 초당 0.01 오류 이하를 유지해야 한다.
🧐부하 테스트: 앱 출시 이후 사용자들의 API 사용 패턴 분석해, 부하가 어느정도 오는지 테스트해야할 것 같아!
사용자 패턴 분석
로그 데이터를 분석하여 API 사용 패턴을 파악한다. 예를 들어, 특정 시간대에 사용량이 급증하는지 확인한다.
테스트 시나리오 작성
분석된 패턴을 바탕으로 시나리오를 작성한다. 예를 들어, 오전 9시부터 11시까지 사용량 급증 패턴을 시뮬레이션한다.
성능 지표 측정
1. 처리량 (Throughput): 평균 2000 RPS.
2. 응답 시간 (Response Time): 평균 1.5초 이내.
3. 지연 시간 (Latency): 300ms 이내.
4. 초당 히트 수 (Hits per Second): 복잡한 요청이 동시에 다수 들어오는 상황을 대비하기 위해 초당 1000 히트 이상으로 설정한다.
5. 초당 트랜잭션 수 (TPS): 초당 100 트랜잭션 이상으로 설정한다.
6. 오류 수 (Errors per Second): 초당 0.05 오류 이하로 설정한다.
😵스트레스 테스트: 특정 시간대에 일부 API 사용량이 증가해 사용자들이 불편을 겪고있어.
목표 설정
최대 부하 상황에서의 시스템 안정성을 평가한다. 또한 부하 증가 시 시스템에서 발생하는 오류와 이를 복구하는 능력을 평가한다.
테스트 시나리오 작성
특정 시간대(예: 오후 6시 ~ 8시)에 사용량이 급증하는 상황을 시뮬레이션한다. 부하를 점진적으로 증가시켜 초당 5000 RPS 이상의 요청을 시스템에 가한 후 최대 부하 상태를 일정 시간 유지하여 시스템의 반응을 관찰한다.
성능 지표 측정
1. 처리량 (Throughput): 초당 5000 RPS 이상.
2. 응답 시간 (Response Time): 평균 1초 이내.
3. 지연 시간 (Latency): 200ms 이내.
4. 초당 히트 수 (Hits per Second): 초당 2500 히트 이상으로 설정한다.
5. 초당 트랜잭션 수 (TPS): 초당 500 트랜잭션 이상으로 설정한다.
6. 오류 수 (Errors per Second): 초당 0.1 오류 이하로 설정한다.
이처럼 성능 테스트, 부하 테스트, 스트레스 테스트는 각각의 목적과 상황에 따라 다르게 설정된다. 성능 테스트는 일반적인 성능 평가를, 부하 테스트는 예상 최대 부하에서의 성능을, 스트레스 테스트는 시스템 한계를 넘는 상황에서의 안정성을 평가한다. 각 테스트를 통해 시스템의 다양한 측면을 평가하고, 이를 바탕으로 성능 개선과 안정성 확보를 할 수 있다.
결론
API 서버의 성능을 정량적으로 평가하기 위해서는 성능 테스트가 필수적이다. 성능, 부하, 스트레스 테스트를 통해 시스템의 다양한 측면을 평가하고, 이를 바탕으로 성능 개선과 안정성을 확보할 수 있다. 다음 글에서는 JMeter를 사용하여 실제 성능 테스트 계획을 세우고 실행하는 방법을 다룰 예정이다. 실제 성능 테스트를 통해 API 서버의 성능을 어떻게 평가하고 최적화할 수 있는지 알아보자!