부하 테스트 기본

부하 테스트의 목적

 

클라우드 환경에서의 부하 테스트 목적

1. 시스템 확장성을 가졌는지 확인
2. 성능을 개선하기 위해 확장해야 하는 시스템이 무엇인지 파악
3. 부하가 많이 발생할 때 문제 상황 개선
4. 각 시스템의 병목 지점을 예측하고 진단 및 개선

 

 

어떤 부분을 확장할 것인가?: 확장성에 대한 특징 파악

어떤 부분을 확장해야 성능이 높아질지를 고민하기에 앞서, Throughput과 관련한 지표를 먼저 이해할 필요가 있습니다.
Throughput: 시간당 처리량으로, 시스템의 성능 지표는 RPS(request per second), TPS(transaction per second)와 같은 단위로 표현됩니다.
Throughput은 데이터 전송량에 포커스를 맞춘 성능 지표입니다.
한편 볼륨의 성능을 측정할 경우에는 IOPS(Input/Output per second)라는 단위를 사용합니다.
성능을 측정할 때는, 인프라 내의 구성요소(티어)로 구분된 각 요소를 구분하지 않고 통합해서, 특정 작업이 얼마만큼의 Throughput을 갖는지를 측정합니다.

 

그렇다면, 다음과 같은 질문을 던질 수 있을 것입니다.

• 1000rps에서 2000rps로 성능을 두 배 개선하기 위해서는, 웹서버를 확장해야 할까? DB 서버를 확장해야 할까?
• 시스템 구성 변경 시 다운타임은 얼마나 허용되는가? 서비스 정지 없이 가능한가?
• 현재 시스템에서 낼 수 있는 최대 성능(limit)은 어디까지인가?

 

 

부하가 많이 발생할 때의 문제 상황 개선

사용자 요청이 많아지는 경우, 즉 부하가 많이 발생하면 실제로 시스템은 어떤 문제를 일으킬까요? 이때 발생할 수 있는 요소는 다음과 같습니다.

• 응답 속도(Latency) 저하
• 시스템 잠금(Lock) 경합
• 부하 발생 시 애플리케이션 또는 서버 에러 발생
• 데이터 일관성 문제와 손실

-> 이러한 문제 상황을 해결할 수 있을 만큼의 부하의 수용 범위를 파악해야 합니다.

 

Q. 시스템 잠금(Lock)에 대한 경합(Race condition)은 어느 때 발생하나요? 누가 무엇을 잠그는 걸까요? (주로 DB에서 이러한 일이 발생합니다.)

시스템 잠금 경합(Race condition)은 동시에 여러 프로세스 또는 스레드가 공유 자원에 접근하려고 할 때 발생할 수 있습니다.
이러한 경합은 주로 데이터베이스(DB)에서 발생할 수 있습니다.

데이터베이스에서 시스템 잠금 경합은 일반적으로 두 가지 주요 상황에서 발생합니다:

동시에 여러 트랜잭션이 같은 데이터를 수정하려고 할 때: 여러 트랜잭션은 동시에 같은 데이터를 변경하려고 시도할 수 있습니다. 이 경우, 경합 조건이 발생하여 어떤 트랜잭션은 데이터를 읽을 수 없거나 잘못된 데이터를 읽을 수 있습니다.
동시에 여러 트랜잭션이 데이터를 잠그려고 할 때: 한 트랜잭션이 데이터를 수정하려고 할 때, 다른 트랜잭션이 동시에 같은 데이터를 잠그려고 할 수 있습니다. 이 경우 두 트랜잭션 모두 데이터를 잠그기 위해 경합하게 되고, 한 트랜잭션은 다른 트랜잭션이 완료될 때까지 기다려야 합니다.

즉, 시스템 잠금 경합은 동시에 여러 프로세스 또는 스레드가 동일한 데이터를 동시에 수정하려고 하거나 데이터에 동시에 접근하려고 할 때 발생할 수 있습니다.

 

 

병목 지점을 예측하고 진단 및 개선

1. 네트워크 병목: 네트워크 대역폭이 부족하거나 네트워크 지연이 발생하는 경우 응답 성능에 영향을 줄 수 있습니다. 이 경우 대응 방법으로는 네트워크 인프라를 업그레이드하거나 네트워크 트래픽을 최적화하는 것이 있습니다. 또한, 캐싱이나 CDN(Content Delivery Network)을 사용하여 지연을 줄일 수도 있습니다.
2. 서버 부하: 서버 자원(CPU, 메모리, 디스크 등)이 부족하거나 과도한 요청으로 인해 서버 부하가 증가하는 경우 응답 성능이 저하될 수 있습니다. 이에 대한 대응 방법은 서버 확장(스케일 업 또는 스케일 아웃)이 있습니다. 서버 자원을 추가하거나 클라우드 기반의 서비스를 사용하여 부하를 분산시킬 수 있습니다.
3. 비효율적인 코드 또는 알고리즘: 코드나 알고리즘이 비효율적으로 작성되어 처리 시간이 오래 걸리는 경우 응답 성능에 영향을 줄 수 있습니다. 이 경우 코드 최적화, 쿼리 튜닝, 캐싱 등을 통해 성능을 개선할 수 있습니다.
4. 데이터베이스 성능 문제: 데이터베이스 쿼리의 복잡성, 인덱스 부재, 잠금 경합 등으로 인해 데이터베이스 성능이 저하될 수 있습니다. 데이터베이스 성능을 향상시키기 위해 쿼리 최적화, 인덱스 개선, 데이터베이스 샤딩(Sharding) 등을 고려할 수 있습니다.
5. 클라이언트 측 성능: 클라이언트 측에서도 성능 문제가 발생할 수 있습니다. 브라우저 캐싱, 리소스 최적화, 비동기 처리 등을 통해 클라이언트 측 성능을 개선할 수 있습니다.

 

 

Throughput과 Latency

Throughput

시간당 처리량을 의미합니다. 웹 애플리케이션 성능 지표로서의 throughput의 대표적인 예는 다음과 같습니다.

• 1초에 처리하는 HTTP 요청 수 (rps)
• (동영상 스트리밍 서비스와 같이 대역폭이 중요한 경우) 네트워크로 전송되는 데이터 전송 속도

 

 

Latency

처리 시간을 의미합니다.

 

사용자가 어떤 웹페이지를 보기 위한 Latency는 사용자의 인터넷 환경, 브라우저 등의 개별 환경에 대한 변수가 존재합니다.

그러나 성능 테스트를 진행할 때에는, 사용자 환경에 따른 변인을 통제하거나, 애초에 네트워크 상황을 고려하지 않고 테스트를 진행합니다. 이후 언급하는 Latency는 네트워크 상황을 고려하지 않은 시스템이 요청을 받고 응답을 줄 때까지의 시간만을 의미할 것입니다.

 

 

하위 시스템으로 구성된 경우에서의 Throughput과 Latency

다음 고속도로의 비유를 통해 Throughput과 Latency를 이해할 수 있습니다.
여기서 하위 시스템은 서울/대구/부산 각각의 도시를 의미하며, 각 도시 간에는 서로 다른 Throughput과 Latency를 가진 고속도로 두 개가 존재한다고 가정합시다.

 

• 이때 Latency는 대기 시간을 포함한, 각 하위 시스템 처리 시간의 총합으로 계산합니다.
• 반면 Throughput은 하위 시스템 Throughput 중 최소값을 전체 시스템의 Throughput으로 계산합니다.

 

• 서울-부산 간 Latency: 각 구간의 소요 시간 합계인 5시간
• 서울-부산 간 Throughput: 각 구간에 도달하는 차량 대수 중 최소값인 800대/시간

 

[출처]

코드스테이츠