부하 테스트의 기본
카테고리: Performance Test
태그: Latency Lock Throughput 부하 테스트
부하 테스트의 목적
클라우드 환경에서의 부하 테스트 목적
- 시스템 확장성을 가졌는지 확인
- 성능을 개선하기 위해 확장해야 하는 시스템이 무엇인지 파악
- 부하가 많이 발생할 때 문제 상황 개선
- 각 시스템의 병목 지점을 예측하고 진단 및 개선
어떤 부분을 확장할 것인가? 확장성에 대한 특징 파악
Throughput은 시간당 처리량으로, 시스템의 성능 지표는 RPS(request per second), TPS(transaction per second)와 같은 단위로 표현됩니다. Throughput은 데이터 전송량에 포커스를 맞춘 성능 지표입니다. 한편 볼륨의 성능을 측정할 경우에는 IOPS(Input/Output per second)라는 단위를 사용합니다. 성능을 측정할 때는, 인프라 내의 구성요소(티어)로 구분된 각 요소를 구분하지 않고 통합해서, 특정 작업이 얼마만큼의 Throughput을 갖는지를 측정합니다.
그렇다면, 다음과 같은 질문을 던질 수 있을 것입니다.
- 1000rps에서 2000rps로 성능을 두 배 개선하기 위해서는, 웹서버를 확장해야 할까? DB 서버를 확장해야 할까?
- 시스템 구성 변경 시 다운타임은 얼마나 허용되는가? 서비스 정지 없이 가능한가?
- 현재 시스템에서 낼 수 있는 최대 성능(limit)은 어디까지인가?
부하가 많이 발생할 때의 문제 상황 개선
사용자 요청이 많아지는 경우, 즉 부하가 많이 발생하면 시스템에서 발생할 수 있는 문제 요소는 다음과 같습니다.
- 응답 속도(Latency) 저하
- 시스템 잠금(Lock) 경합
- 부하 발생 시 애플리케이션 또는 서버 에러 발생
- 데이터 일관성 문제와 손실
Action Items
Q. 시스템 잠금(Lock)에 대한 경합(Race condition)은 어느 때 발생하나요? 누가 무엇을 잠그는 걸까요? (주로 DB에서 이러한 일이 발생합니다.)
A. 시스템 잠금에 대한 경합(Race condition)은 두 개 이상의 프로세스나 스레드가 공유 자원에 대한 접근을 경쟁할 때 발생합니다. 이러한 상황은 주로 데이터베이스에서 발생하는데, 이는 여러 사용자나 프로세스가 동시에 같은 데이터에 접근하려 할 때 발생합니다.
데이터베이스에서 잠금(Lock)은 데이터의 일관성을 보장하기 위해 사용됩니다. 예를 들어, 한 사용자가 특정 레코드를 수정하는 동안 다른 사용자가 동일한 레코드를 읽거나 수정하려고 시도하면, 데이터의 일관성이 깨질 수 있습니다. 이런 경우, 데이터베이스는 해당 레코드에 잠금(Lock)을 걸어 다른 사용자의 접근을 제한합니다.
그러나 잠금(Lock)을 사용하면 경합(Race condition)이 발생할 수 있습니다. 예를 들어, 두 사용자가 동시에 같은 레코드를 수정하려고 하면, 누가 먼저 접근할 수 있을지 결정하는 문제가 발생합니다. 이를 해결하기 위해 데이터베이스는 일반적으로 먼저 요청을 보낸 사용자에게 잠금(Lock)을 하고, 다른 사용자는 잠금(Lock)이 해제될 때까지 대기하게 됩니다.
그러나 이런 방식으로도 완벽한 해결책이 되지 않을 수 있습니다. 예를 들어, 두 사용자가 거의 동시에 요청을 보내면, 누가 먼저 요청을 보냈는지 결정하기 어려울 수 있습니다. 또는 한 사용자가 잠금 상태에서 시스템이 다운되면, 다른 사용자는 잠금(Lock)이 해제될 때까지 영원히 대기하게 될 수 있습니다. 이러한 상황을 피하기 위해 데이터베이스는 다양한 잠금(Lock) 관리 전략을 사용합니다.
잠금 (Lock) 관리 전략
- 락 그래누러티(Lock Granularity): 락 그래누러티는 락이 적용되는 데이터의 범위를 의미합니다. 락을 거는 단위가 크면(예: 테이블 전체) 동시성이 줄어들지만, 락 관리의 복잡성은 줄어듭니다. 반면에 락을 거는 단위가 작으면(예: 행 또는 열), 락 관리는 복잡해지지만 더 많은 사용자가 데이터베이스를 동시에 사용할 수 있게 됩니다.
- 락 타입(Lock Type): 데이터베이스에서는 주로 두 가지 유형의 락이 사용됩니다. 공유 락(Shared Lock)은 여러 트랜잭션이 동시에 같은 데이터를 읽을 수 있도록 허용하지만, 배타적 락(Exclusive Lock)은 한 번에 하나의 트랜잭션만이 데이터를 수정할 수 있게 합니다.
- 데드락 처리(Deadlock Handling): 데드락은 두 개 이상의 트랜잭션이 서로의 락 해제를 기다리며 진행이 멈추는 상황을 의미합니다. 이를 해결하기 위한 방법으로는 데드락 감지 및 복구, 타임아웃 및 중복 시도 등이 있습니다.
- 최적화(Optimization): 락 관리를 최적화하는 방법 중 하나는 락을 미리 획득하는 것입니다. 트랜잭션이 실행되기 전에 필요한 모든 락을 먼저 획득하면, 데드락을 방지하고 성능을 향상시킬 수 있습니다.
이렇게 각각의 전략에는 장점과 단점이 있으며, 어떤 전략을 사용할지는 특정 상황과 요구사항에 따라 달라집니다. 이러한 전략들을 통해 데이터베이스는 동시성을 높이면서도 데이터의 무결성을 보장하려 노력합니다.
Throughput과 Latency
시스템 성능 지표의 주요 메트릭은 단연 Throughput과 Latency입니다. 부하 테스트에서는 이 두 가지 지표를 사용하여 평가합니다.
Throughput (처리량)
웹 애플리케이션 성능 지표로서의 throughput의 대표적인 예는 다음과 같습니다.
- 1초에 처리하는 HTTP 요청 수 (rps)
- (동영상 스트리밍 서비스와 같이 대역폭이 중요한 경우) 네트워크로 전송되는 데이터 전송 속도
Latency (지연시간)
사용자가 어떤 웹페이지를 보기 위한 Latency는 사용자의 인터넷 환경, 브라우저 등의 개별 환경에 대한 변수가 존재합니다. 즉, “네트워크를 통한 데이터 왕복 시간”도 포함합니다. 그러나 성능 테스트를 진행할 때에는, 사용자 환경에 따른 변인을 통제하거나, 애초에 네트워크 상황을 고려하지 않고 테스트를 진행합니다. 시스템이 요청을 받고 응답을 줄 때까지의 시간만을 시험합니다.
하위 시스템으로 구성된 경우에서의 Throughput과 Latency
- Latency는 대기 시간을 포함한, 각 하위 시스템 처리 시간의 총합으로 계산합니다.
- Throughput은 하위 시스템 Throughput 중 최소값을 전체 시스템의 Throughput으로 계산합니다.
댓글남기기