성능 테스트 유형 - seongneung teseuteu yuhyeong

반응형

출처: Testing Applications on the Web, 저자 Hung Q. Nguyen, 2001년

16장 성능 테스트, 부하 테스트, 스트레스 테스트(Performance, Load, and Stress Tests), 311~335 페이지

서론

웹 애플리케이션의 장점은 여러 사용자가 동시에 시스템 리소스에 액세스 할 수 있다는 것이다(동시에 서로 다른 서비스를 요청하고 다양한 기능에 액세스 할 수 있음). 다중사용자 지원(multiuser support)이 웹 애플리케이션의 성공을 판가름하는 핵심 요인이므로, 시스템이 사용자 액티비티가 최고조에 달하는 피크 기간 동안 주요 기능을 수행할 수 있는지를 신중히 평가해야 한다. 다중사용자 지원 능력을 평가하는데 흔히 세 가지 유형의 테스트(성능, 부하, 스트레스)가 수행된다. 이 용어들이 종종 같은 의미로 사용되지만, 각각 서로 다른 목표를 해결하기 위해 설계된 테스트를 나타낸다.

성능 테스트(Performance Testing)의 주요 목표는 허용할만한 시스템 성능을 유지하기 위한 효과적인 개선 전략을 개발하는 것이다. 성능 테스트는 언제 부하 수준이 시스템 리소스를 고갈시킬지 예측하기 위해 측정 데이터를 수집하는 정보 수집 및 분석 프로세스이다.

부하 테스트(Load Testing)는 사전 정의된 부하 수준으로 시스템 성능을 평가한다. 부하 테스트는 정상 조건 또는 사전 정의된 조건 하에서 시스템이 다양한 프로그램 태스크 및 기능을 수행하는데 걸리는 시간을 측정한다. 만약 태스크가 제한 시간(일반적으로 제품 관리 그룹이나 마케팅 그룹에서 정의함) 내에 실행되지 못하면 버그 보고서가 제출된다. 시스템 성능이 부하 요구사항(load requirements)을 충족하는지 확인하는 것이 부하 테스트의 목적이므로, 테스트를 시작하기 전에 최소 구성 수준(minimum configuration levels)과 최대 액티비티 수준(maximum activity levels)을 결정하는 것이 좋다.

스트레스 테스트(Stress Testing)는 지정된 운영 한계(operational limits)를 넘도록 압박이 가해진 시스템의 동작을 평가한다(시스템 한계를 초과하는 폭발적인 피크 액티비티에 어떻게 반응하는지 평가). 과부하 조건에서 시스템 크래시가 발생하는지 또는 매끄럽게 복구되는지 확인하는 것이 스트레스 테스트의 주요 목표이다. 스트레스 테스트는 시스템의 약한 고리가 드러날 때까지 시스템 리소스를 한계로 몰아 가도록 설계해야 한다.

용어 ‘성능(performance)’과 ‘부하(load)’는 종종 같은 의미로 사용된다. 부하 테스트는 사전 정의된 부하 수준에서 허용할만한 시스템 성능이 나오는지 확인하기 위해 수행되고, 성능 테스트는 다양한 부하 수준에서의 시스템 성능을 확인하기 위해 수행된다. 성능 테스트와 부하 테스트 간의 유사성은 그 실행 전략(execution strategies)에 있다. 보통 이러한 테스트는 일정 기간 동안 동시에 시스템에 액세스하는 수백 또는 수천 명의 사용자를 시뮬레이션하며, 이 때 소요되는 시간과 노력 때문에 자동 테스팅 도구의 도움 없이 사람 테스터가 실행하는 것은 비현실적이다.

성능 및 부하 테스트와 달리 스트레스 테스트는 시스템이 한계점을 넘어서도록 밀어 붙이고, 그 결과로 망가지는 시스템 컴포넌트를 조사하고 보강하는데 주안점을 둔다.

성능, 부하, 스트레스 테스트는 또한 다음과 같은 시스템 에러도 식별 할 수 있다.

• 하드웨어 인터럽트로 인한 소프트웨어 실패
• 메모리 런타임 에러(메모리 누수, 덮어 쓰기, 포인터 에러 등)
• 데이터베이스 교착상태(deadlocks)
• 멀티스레딩 문제(multithreading problems)

성능 목표 평가

성능 테스트가 고려하는 주요 사항이 아래와 같다.

• 시스템이 응답 시간, 보안, 신뢰성, 정확성 등을 손상시키지 않고 웹 트래픽 증가를 감당 할 수 ​​있는가?
• 어느 시점에서 성능이 저하되고 어떤 컴포넌트가 이 성능 저하의 원인이 되는가?
• 성능 저하가 회사 판매량 및 기술 지원 비용에 어떤 영향을 미칠 것인가?

위 고려사항 각각을 위해 다양한 워크로드(workload) 시나리오를 적용하여 시스템 속성(예, 응답 시간)을 평가(측정)하고, 수집된 데이터를 바탕으로 결론을 도출한다. 예를 들어, 동시 사용자 수가 X에 도달하면 응답 시간이 Y가 될 때 시스템이 X명 이상의 동시 사용자를 지원할 수 없다는 판단을 내릴 수 있다. 하지만 실제 문제는 이렇게 간단하지 않은데, 동시 사용자 수 X가 변경되지 않더라도 상이한 사용자 액티비티에 따라 Y 값이 달라질 수 있기 때문이다. 예를 들어, 1000명의 동시 사용자가 2K HTML 페이지를 요청하면 일정 범위 내의 응답 시간이 나오지만, 1000명의 동시 사용자가 상당한 서버 측 프로세싱이 필요한 구매 트랜잭션을 동시에 제출하면 응답 시간이 크게 달라질 수 있다. 따라서 실제 사용(usage)을 정확하게 반영하는 유효한 워크로드 모델을 설계하는 것은 간단한 작업이 아니다.

다음은 트래픽 부하 증가와 그에 따른 응답 시간 증가가 어떻게 회사 수익 손실로 이어지는지 보여주는 단순화된 예이다. 전자상거래 사이트가 현재 하루에 300,000건의 거래를 처리한다. 이를 아래처럼 하루의 초 수로 나누면 초당 트랜잭션 건 수(TPS)는 약 3.47이다.

마케팅 설문 조사를 수행한 결과가 아래와 같다고 가정한다.

• 트랜잭션 응답 시간은 4초를 초과하지 않는 한 허용가능한 수준이다.
• 트랜잭션 응답 시간이 4초 이상 8초 미만이면 사용자의 30%가 트랜잭션을 취소한다.
• 트랜잭션 응답 시간이 8초 이상 10초 미만이면 사용자의 60%가 트랜잭션을 취소한다.
• 트랜잭션 응답 시간이 10초 이상으로 증가하면 90% 이상의 사용자가 트랜잭션을 취소한다.

향후 6개월 동안 트랜잭션 수가 현재 수준에서 25~75% 증가 할 것으로 예상하였고, 각 트랙잭션의 잠재적 수익이 1달러라고 가정한다. 성능 테스트를 수행 해 보니 시스템이 응답 시간 증가 없이 이러한 트래픽 증가를 처리 할 수 ​​없다는 결과가 나왔다(즉, 사용자 트랜잭션 취소 또는 실패가 발생). 만약 트랜잭션 수가 예상대로 증가한다면 회사는 하루에 112,500달러에서 472,500달러 사이의 잠재적 수익 손실에 직면하게 된다.

i) 트랜잭션 25% 증가 시 초당 트랜잭션 수(TPS)가 아래와 같고, 그림 16.1에서 이 TPS의 응답 시간이 4초 이상 8초 미만에 해당되므로 30%의 트랜잭션 감소가 예상됨(375,000 * 0.3 = 112,500건 감소)

ii) 트랜잭션 75% 증가 시 TPS가 아래와 같고, 그림 16.1을 참조한 결과 응답 시간이 10초를 넘어서므로 90% 이상의 트랜잭션 감소가 예상됨(525,000 * 0.9 = 472,500건 감소)

성능 테스팅 개념

성능 테스팅 계획 동안 반드시 이해하고 평가해야 하는 몇 가지 주요 이슈가 아래와 같다.

• 예상 사용자 수(Projected number of users): 사용자 액티비티가 다양하고 액세스 시간과 액티비티 빈도도 제각각 일 수 있으므로 시스템이 지원하는 사용자 수를 추정하는 것은 쉽지 않은 일이다. 워크로드 모델에서 예상 사용자 수를 결정하는데 신중한 고민이 필요하다.
• 허용가능한 성능(acceptable performance): 받아들일 수 있는 시스템 성능 수준을 결정하는데 마케팅 및 제품 관리 부서의 의견이 필요하다. 어떻게 성능 측정을 할 것인지, 이에 드는 비용을 얼마인지, 어떤 도구를 사용할 것인지, 어떤 메트릭을 적용할 것인지 등을 고려해야 한다. 또한 어떤 컴포넌트가 시스템 성능에 영향을 미치는지 이해하는 것도 중요하다.
• 데이터 분석 및 시정 조치 계획(data analysis and corrective action planning): 일단 성능 테스트 결과가 수집되면 성능 향상을 위한 시정조치(corrective measures)를 고려해야 한다. 예를 들어, 추가적인 시스템 리소스를 더해야 하는가? 네트워크 아키텍처를 조정해야 하는가? 프로그래밍을 개선 할 방법이 있는가? 등을 고려한다.

성능 테스트는 아래 세 가지 기본 요소에 대한 평가를 수반한다.

1. 시스템 환경 및 가용한 리소스.
2. 워크로드
3. 시스템 응답 시간

아래 그림은 워크로드 증가에 따라 성능이 어떻게 변화하는지에 대해 우리가 단순히 예상하는 것과 실제 현실 결과가 매우 다르다는 것을 보여준다. 그림 16.2는 트래픽 부하와 종합 응답 시간(Aggregate Response Time: 서버, 네트워크, 브라우저 응답 시간을 모두 합한 시간) 간의 관계에서 초당 트랜잭션이 증가함에 따라 종합 응답 시간이 예측 가능하고 규칙적인 방식으로 증가한다고 섣불리 예단한 모습이다. 하지만 그림 16.3처럼 서버, 네트워크, 브라우저 응답 시간이 비선형적으로 증가하는 것이 더 현실적인 시스템 반응 시나리오이다. 트랜잭션 수가 증가함에 따라 트랜잭션 왕복 시간(transaction round-trip time)이 증가하며, 궁극적으로 초당 트랜잭션 수가 포화 상태에 도달한다. 결국 전체 시스템이 리퀘스트에 응답하지 않는 지점이 될 때까지 서버 응답 시간이 증가한다.

웹 트랜잭션 시나리오

온라인 트랜잭션에 세 가지 주요 컴포넌트(클라이언트 측 브라우저, 네트워크, 서버)가 관여하는데, 전형적인 웹 트랜잭션 흐름이 아래와 같다.

클라이언트 측에서

• 사용자가 URL을 입력하거나 또는 브라우저 내의 링크를 클릭하여 서버의 파일을 요청한다.
• DNS가 서버의 호스트 이름을 적절한 IP 주소로 변환한다.
• 클라이언트가 웹 서버에 연결한다.
• 클라이언트가 서버로 HTTP 리퀘스트(예, GET 또는 POST)를 전송한다.

인터넷(네트워크) 상에서

• 네트워크는 클라이언트에서 서버로 데이터를 전달한다.

서버 측에서

일단 리퀘스트가 서버에 도달하면 데이터가 적절한 통신 프로토콜(예, HTTP)에 따라 분해된다.

• 서버는 리퀘스트에 응답한다.
• 서버는 데이터를 검색하거나 또는 데이터베이스에 쓰기를 하여 리퀘스트를 처리한다. 프로세스가 완료되면 서버는 요청된 파일 또는 결과 정보를 클라이언트에게 반환한다.

다시 인터넷(네트워크) 상에서  

• 네트워크는 서버에서 클라이언트로 데이터를 전달한다.

다시 클라이언트 측에서

• 브라우저는 요청된 데이터를 수신하고, HTML 콘텐츠를 디스플레이하며, 모든 활성 콘텐츠(active content)를 실행한다.

그림 16.5는 성능 병목 현상을 유발하는 전형적인 리소스를 정의하고, 또한 온라인 트랜잭션의 세 가지 주요 컴포넌트와 관련된 액티비티들도 기술하고 있다.

Note.

위 그림에서 ‘응답 시간’은 서버 측에서의 시간만을 나타내고 있으므로 트랜잭션 왕복 시간(Transaction Round-Trip Time)과 같은 의미로 사용되는 경우와 구분 필요. 이런 구분을 위해 Aggregate Response Time이라는 용어가 쓰이는 경우도 있음. ‘종합 응답 시간(Aggregate Response Time)’은 브라우저 프로세싱 시간, 네트워크 서비스 시간, 서버 응답 시간을 모두 합한 것이다.

워크로드(Workload)에 대한 이해

성능, 부하, 스트레스 테스트는 시스템 리소스 및 기타 관련 영역을 고갈시키는데 실제 워크로드(actual workload) 또는 시뮬레이션 된 워크로드(simulated workload)를 사용한다.

‘워크로드(workload)’는 시스템에 요구되는 프로세싱 및 트래픽 관리의 양이다. 시스템 워크로드를 평가하려면 세 가지 요소(사용자, 애플리케이션, 리소스)를 고려해야 한다. 즉, 시스템의 워크로드를 계산하려면 1) 사용자 규모(더불어 그들이 흔히 하는 액티비티), 2) 사용자 액티비티(예, HTTP 리퀘스트) 처리를 위해 애플리케이션에게 요구되는 활동, 3) 시스템의 리소스 요구사항에 대한 이해가 수반되어야 한다.

워크로드를 결정하기 위해서 아래와 같은 몇 가지 단계를 취할 수 있다.

• 시스템이 전개(배포)되기 전이라면 가용한 성능 요구사항 문서를 참조한다.
• 실제 사용자의 단면도 역할을 할 수 있는 소규모 사용자 그룹을 모아 조직한다(다양한 직원 유형을 시뮬레이션하고 그들의 일상 액티비티를 수행하도록 함). 서버를 구성하고 로그 분석 도구를 사용하여 사용자 액티비티를 기록(log)한다. 이렇게 수집된 데이터를 사용하여 워크로드를 추정한다.
• 시스템이 처리하게 될 동시 사용자 수를 추정하고, 사용자를 그룹으로 분류하고, 각 사용자 그룹의 백분율, 세션 길이, 액티비티, 액티비티 빈도를 추정한다.
• 시스템 전개(배포) 후에는 로그 분석 도구 또는 프록시 서버를 사용하여 워크로드 데이터를 수집한다.

성능 테스팅 용어

성능 테스트에서 워크로드를 시뮬레이션하고, 측정 데이터를 수집하고, 데이터를 성능 분석에 사용할 수 있는 형식으로 제공하는데 종종 자동 테스트 도구의 도움이 필요하다. 각 도구 공급 업체가 유사한 개념을 설명하는데 조금씩 다른 용어를 사용하는데, 아래 목록은 일반적으로 사용되는 응답 및 성능 테스트 용어를 기술하고 있다.

처리량(Throughput) 계산 예

처리량 계산의 목적은 시스템 워크로드를 지원하는데 필요한 대역폭 수준을 확인하는 것이다. 예를 들어, 웹서버가 10개의 상이한 HTML 문서(각각의 평균 크기는 2K)가 모인 풀(pool)에서 매 3.5분마다 문서를 요청하는 10,000명의 동시 사용자를 지원한다고 가정했을 때, 이를 처리하기 위한 대역폭 요구사항을 아래와 같이 계산한다.

이 처리량 부하를 감당하려면 네트워크 연결이 적어도 T1 라인(1,544,000bps) 이상이어야 한다(아래 대역폭 변환표 참조).

샘플 애플리케이션 테스팅(워크로드 작성) 예

아래 표는 샘플 애플리케이션(웹 기반 버그 추적 애플리케이션)의 워크로드를 분석하는 예를 보여준다. 10,000명의 동시 사용자가 시스템을 사용하여 신규 버그를 보고하고, 기존 버그 보고서로 작업하고, 차트를 생성하는 가상 시나리오(hypothetical scenario)로 워크로드를 분석한다.

웹 애플리케이션이 지원하도록 설계된 워크로드가 요구사항 문서에 자세히 기술되어 있어야 한다. 이미 사용 중인 시스템의 경우라면 네트워크 관리 그룹에서 시스템 트래픽에 대한 정보를 제공할 수도 있다. 보통 Web Trends Log Analyzer 또는 Analog 같은 로그 분석 도구를 사용하여 이런 정보를 얻는데, 어떤 로그 분석 도구를 사용하든 일관성 있게 사용하는 것이 좋다(각 도구가 동일한 네트워크 트래픽량에 대해 조금씩 다른 통계를 생성함).

이 예에서는 세 가지 사용자 타입(테스터, 개발자, 프로젝트 관리자)를 고려하고, 각 사용자 타입의 평균 세션 길이와 비중(%)을 나열한다(예를 들어, 테스팅 그룹은 10,000명의 시스템 사용자에서 60%를 차지하므로 6000명의 사용자가 해당됨). 또한 사용자 액티비티를 기술하고 세션별로 각 액티비티가 수행되는 횟수도 표시하며, 마지막으로 애플리케이션에게 요청되는 액티비티와 초당 트랜잭션 수(TPS)를 기술한다.

아래 표의 첫 번째 행을 예로 들어 TPS를 계산하는 공식이 아래와 같다.

표 16.2는 어떤 사용자 타입에서 트랜잭션을 요청했는지와 관계 없이 각각의 고유한 사용자 액티비티가 얼마나 자주 실행되는지 분석하기 위한 것이다. 즉, 표 16.1에서 사용자 타입에 따라  배치했던 사용자 액티비티를 아래 표에서는 동일한 액티비티끼리 모아서 합계하여 종합 TPS(Aggregate TPS)를 구한다. 이렇게 구한 종합 TPS는 경영진 및 마케팅 그룹에서 결정한 "허용 가능한" 응답 시간과 나란히 기술한다. 

시뮬레이션 할 가상 사용자 수 결정하기

적절한 가상 사용자 수를 결정할 때 염두에 두어야 할 두 가지 인자는 ‘응답 시간(response time)’과 ‘처리량(throughput)’이다. 예를 들어, 5개 트랜잭션이 동시에 발생하면 응답 시간에 영향을 미칠 수도 있지만 처리량에는 영향이 미비하다. 반면 균등하게 간격을 둔 500개의 트랜잭션은 응답 시간에 영향을 주지 않지만 처리량 이슈를 가져올 수도 있다. 

부하 및 성능 테스트가 필요로 하는 적절한 가상 사용자 수는 테스트의 초점에 따라 달라진다. 샘플 애플리케이션의 경우 적절한 가상 사용자 수를 계산하는 몇 가지 방법이 아래와 같다.

• 오로지 애플리케이션 서버와 데이터베이스 서버의 성능을 응답 시간 및 처리량 측면에서 테스트하고자 한다면 가상 사용자 수로 40명(TPS의 합계)을 고려하는 것이 좋다.
• 각 서버 상에서 동시 오픈 세션의 성능을 테스트하려면 10,000명(실제 동시 사용자 수)을 가상 사용자 수로 고려한다.
• 특정 성능 확장 모델(performance scaling model)의 유효성을 테스트 하고자 한다면 40에서 10,000 사이의 임의의 숫자를 가상 사용자 수로 고려한다.

반응형

공유하기

게시글 관리

저작자표시 비영리 변경금지

• 카카오스토리
• 트위터
• 페이스북

'테스팅타입별 > 성능(Performance)' 카테고리의 다른 글