[부하 테스트] 기초 용어 정리 + 추가 Tip 정리

부하 테스트란?

전체 시스템이 어느 정도 트래픽을 견딜 수 있는지 테스트

 

그럼 부하 테스트는 왜 할까??

서비스를 배포하기 전에 부하 테스트를 진행하면 서버가 견딜 수 있는 트래픽의 한계를 사전에 파악할 수 있어, 이를 통해 모니터링을 통해 트래픽이 어느 정도 증가할 때 서버에 얼마나 부담이 갈 수 있는지를 인지하고, 서버 과부하가 걸려 서버가 터지는 걸 미리 인지하고 빠르게 대처할 수 있습니다.

 

부하(Load)란?

부하는 서비스에 가해지는 트래픽 양이나 요청의 수를 의미하며, 이는 서비스에서 처리해야 하는 작업의 양을 나타냅니다. 부하와 처리량이라는 용어를 보면 그 의미를 쉽게 떠올릴 수 있지만, 개념만으로는 혼란스러울 수 있습니다. 따라서 명확히 하자면, 부하는 단순히 서비스에 요청되는 양을 의미하고, 처리량은 서비스가 1초당 처리할 수 있는 요청의 수를 나타냅니다.

 

처리량(Throughput)이란?

부하 테스트에서 서비스가 1초당 처리할 수 있는 트래픽 양을 Throughput이라고 하며, 이때 주로 TPS(Transaction Per Second, 1초당 처리한 트랜잭션의 수)를 단위로 사용합니다. 예를 들어, 내가 만든 서비스가 1초에 최대 100개의 API 요청을 처리할 수 있다면, 이 서비스의 Throughput은 100 TPS로 정의할 수 있습니다. 참고로 TPS와 RPS(Request Per Second)는 비슷한 개념으로, 각각 1초당 처리한 트랜잭션의 수와 요청의 수를 의미합니다. 데이터베이스의 상태를 변경하는 요청은 TPS와 RPS가 동일한 의미로 간주될 수 있지만, 단순 조회 요청은 트랜잭션이 작동하지 않기 때문에 이 경우 RPS 단위를 사용하는 것이 더 바람직합니다.

 

지연 시간(Latency)이란?

부하 테스트에서의 Latency는 요청에 대한 응답 시간을 의미하며, 만약 내가 만든 서비스에 부하 테스트를 진행했을 때 평균 응답 시간이 2.5초라면, 이는 평균 Latency가 2.5초라는 것을 의미합니다. 쉽게 말해 하나의 API에 요청을 보냈을 때 응답받기까지 약 2.5초가 걸린다는 뜻입니다. 추가적으로 Latency는 개별 API 요청의 응답 시간을 나타낼 수도 있고, 여러 요청의 평균 지연 시간을 나타낼 수도 있습니다.

 

어떤 부하 테스트 툴이냐는 크게 안 중요하다

프레임워크 같은 경우에는 Spring Boot, Node.js 중 어느 것을 사용하는지 결정하는 것은 중요합니다. 하지만 부하 테스트 툴에서 k6을 쓸 줄 아는 지 ngrinder를 쓸 줄 아는 지는 하나도 안 중요합니다. 실제 부하 테스트를 하면서 결과 데이터를 정확하게 해석할 수 있는 지와, 결과 데이터를 바탕으로 적절한 방식으로 성능 개선을 할 수 있는 지의 역량을 가지고 있는 지가 중요합니다. 따라서 아무 부하테스트 툴이나 딱 하나만 골라서 익히면 충분합니다. 

 

병목 지점( Bottleneck Point )

병목 지점(Bottleneck Point)이란, 전체 시스템에서 특정 서버 자원(CPU, Memory 등)이 한계에 도달해 전체 성능이 저하되는 구간을 의미합니다. 이를 고속 도로에 비유하면, 도로의 폭이 갑자기 좁아지는 구간에서 차량이 정체되는 상황과 유사합니다. 예를 들어, 3차선 도로에서 소화할 수 있는 차량 수가 갑자기 2차선으로 줄어들면, 이 구간에서 정체가 발생하게 됩니다. 이처럼 2차선 구간에서 발생한 정체를 병목 지점이라고 부릅니다.

즉, 병목 지점의 Throughput은 전체 시스템의 Throughput을 결정짓는 요소입니다. 예를 들어, A~B~C 구간에서 1시간에 통과할 수 있는 자동차의 수가 300대라면, 이는 A~B 구간에서 1시간에 1,000대를 통과시킬 수 있더라도, B~C 구간에서 1시간에 300대만 통과할 수 있기 때문입니다. 따라서 해당 API or 시스템에서 1초당 처리할 수 있는 요청의 양은 300개로 제안됩니다.

이러한 사례를 통해 병목 지점의 Throughput이 곧 전체 Throughput’이라는 사실을 알 수 있습니다.

 

 

가용성(Availability)

가용성(Availability)은 시스템이 사용자에게 서비스를 정상적으로 제공할 수 있는 가능성을 의미합니다. 쉽게 말해, 시스템이 얼마나 멈추지 않고 잘 작동하는가를 나타내는 지표입니다.

• 가용성이 높은 시스템: 서비스에 장애가 발생할 가능성이 매우 낮고, 거의 항상 정상적으로 작동합니다.
• 가용성이 낮은 시스템: 서비스가 자주 중단되거나 다운되는 시간이 깁니다.

가용성 측정 방법은 주로 정상 가동율로 표시합니다.  전체 시간 대비 시스템이 정상적으로 작동한 시간의 비율을 의미합니다.

가동성(%)	1년간 서비스 중단 시간
99.9%	약 8시간 45분
99.99%	약 53분

예를 들어, 가용성 99.99%라고 하면, 1년 중 약 53분 정도만 서비스를 이용할 수 없는 상황이 발생할 수 있다는 뜻입니다.

높은 가용성을 갖춘 시스템은 어떻게 설계할까요?

가용성을 높이기 위해서는 시스템이 사용 불가능한 다운 타임(Downtime)을 최대한 줄여야 합니다. 장애가 발생하더라도 그 시간을 최소한으로 만드는 것이 중요합니다.

 

시스템 이중화

시스템 이중화는 시스템의 일부분을 사용할 수 없게 되더라도 다른 시스템을 이용하여 서비스를 계속 이용할 수 있도록 만드는 것을 의미하며, 이는 높은 가용성을 위한 핵심 설계 방법 중 하나입니다. 구체적으로, 하나의 시스템에 장애가 발생했을 때 다른 예비 시스템이 즉시 그 역할을 이어받아 서비스 중단을 막는 방식으로 작동하며, 서버, 데이터베이스, 네트워크 등 다양한 구성 요소에 이중화를 적용함으로써 특정 지점의 실패가 전체 서비스 중단으로 이어지는 것을 방지합니다.