문서요약 - 웹 애플리케이션의 스트레스 테스팅 by Meier

제목: 웹 애플리케이션의 스트레스 테스팅(Chapter 18 – Stress Testing Web Applications)

저자: J.D. Meier 외 4인, Microsoft Corporation

문서유형: 웹문서, 2007년

출처: https://docs.microsoft.com/en-us/previous-versions/msp-n-p/bb924374(v=pandp.10)

 

웹 애플리케이션 스트레스 테스팅에 대한 기본적인 개념과 수행 방법을 소개한 자료

---

스트레스 테스팅

• 스트레스 테스팅은 성능 테스팅의 한 타입이며, 극한의 조건 하에서 애플리케이션의 견고성(robustness), 가용성(availability), 신뢰성(reliability)을 판단하는데 중점을 둔다.
• 스트레스 테스팅의 목적은 극한의 조건(예, 과부하, 높은 동시성, 제한된 컴퓨팅 리소스) 하에서야 비로소 드러나는 애플리케이션 이슈를 식별하는 것이다.
• 스트레스 테스팅은 동기화 및 타이밍 버그(synchronization and timing bugs), 인터로크 문제(interlock problems), 우선순위 문제(priority problems), 리소스 손실 버그(resource loss bugs) 등을 발견하는데 유용하다.

 

다양한 스트레스 조건 하에서 주요 생산 시나리오(production scenarios)를 시뮬레이션하는게 스트레스 테스트에서 일반적으로 이루어짐. 예를 들어, 프로세서 집약적인 애플리케이션이 이미 실행되고 있는 서버 상에 애플리케이션을 전개시킴으로써 해당 애플리케이션이 당장 프로세서 리소스가 부족한 상황에 놓이게 됨(즉, 프로세서 사이클을 위해 타 애플리케이션과 경쟁해야만 함)

스트레스 조건의 예

• 사용자 또는 데이터의 과도한 양. 예, DoS(a denial of service) 공격, 동시에 많은 사용자가 웹 사이트에 한꺼번에 몰리는 상황
• 리소스 감소. 예, 디스크 드라이브 실패
• 예기치 못한 시퀀싱(Unexpected sequencing)
• 예기치 않은 장애/장애 복구(Unexpected outages/outage recover)

스트레스 관련 증상의 예

• 데이터가 소실되거나 훼손됨
• 스트레스가 제거된 후에도 리소스 사용률(Resource utilization)이 용납할 수 없을 정도로 높음
• 애플리케이션 컴포넌트가 응답을 안함
• 처리되지 못한 예외상황(Unhandled exceptions)이 최종 사용자에게 노출됨

스트레스 테스팅 접근방법

스텝 1 – 테스트 목표 식별하기

스트레스 테스팅을 통해 얻을 수 있는 바람직한 결과를 식별하기 위해 스스로에게 그리고 다른 사람에게 아래와 같은 질문을 던진다.

• 테스트 목적이 생산(운영) 중에 있는 시스템이 파국적으로 실패할 수 있는 상황을 식별하는 것인가?
• 테스트 목적이 파국적 실패에 대응할 수 있는 방어책 구축을 위한 정보를 팀에게 제공하는 것인가?
• 테스트 목적이 시스템 리소스(예, 메모리, 디스크 공간, 네트워크 대역폭, 프로세서 사이클)가 고갈되었을 때 애플리케이션이 어떻게 행동하는지를 식별하는 것인가?
• 스트레스 하에서 기능에 장애가 생기지 않는다는걸 보장하는게 테스트 목적인가? 예를 들어, 운영 성능 메트릭은 목표를 충족시키지만 애플리케이션의 기능이 그 목표를 달성하지 못하는 경우가 있을 수 있음

 

스텝 2 - 주요 시나리오 식별하기

잠재적 문제를 발견하기 위해 스트레스 테스트를 할 필요가 있는 애플리케이션 시나리오(또는 케이스)를 식별한다. 스트레스 테스트가 그 가치를 최대한으로 뽑아내기 위해서는 애플리케이션의 전반적 성공에 가장 중요한 영향을 미치는 사용 시나리오(usage scenario)의 행동에 집중할 필요가 있다. 시나리오를 선별하는데 있어 아래 지침을 따른다.

• 전반적인 애플리케이션 성능에 얼마나 중요한지에 기반해 시나리오를 선택한다.
• 성능에 영향을 미칠 가능성이 높은 오퍼레이션을 테스트 하려 애쓴다. 예, 로킹 및 동기화 집약적 오퍼레이션(intensive locking and synchronization), 길이가 긴 트랜잭션, 디스크 집약적인 입출력 오퍼레이션(disk-intensive input/output operations)
• 부하 테스팅 데이터를 통해 잠재적인 병목 구간으로 식별된 애플리케이션의 부분에 해당하는 시나리오를 선택한다. 

예를 들어, 전형적인 이커머스 애플리케이션에서 다른 사용 시나리오들(usage scenarios)로부터 별도로 스트레스 테스팅이 될 필요가 있는 시나리오로 아래와 같은 것들이 있다.

• 특정 제품의 재고를 갱신하는 주문 처리 시나리오(an order-processing scenario). 이 기능이 로킹 및 동기화 문제를 드러낼 가능성을 갖고 있음
• 사용자 쿼리에 기반해 검색 결과 페이지들을 넘겨 보는 시나리오. 사용자가 특별히 광범위한 쿼리를 명기하는 경우 메모리 사용률(memory utilization)에 큰 영향을 미칠 수 있음

스텝 3 - 워크로드 식별하기

• 시나리오에 적용할 워크로드(workload)를 식별한다. 기 수행된 부하 테스팅에서 워크로드와 최고 부하 수용량(the peak load capacity)이 식별되었다면 이에 기반하여 워크로드를 산정함
• 특정 시나리오에 적용되는 부하가 시스템의 허용 한계를 넘을만큼 충분해야 스트레스 조건의 결과를 관측할 수 있게 됨. 애플리케이션이 스트레스 신호를 보이기 시작하는 지점의 부하를 결정하는 한 가지 방법은 부하를 점진적으로 증가시키고 다양한 부하 조건 하의 애플리케이션 동작을 관찰하는 것이다. 중요한 실패가 발생할 때까지 다양한 워크로드를 가지고 체계적으로 테스트하는게 비결(사용자 수를 추가하거나, 지연 시간을 줄이거나, 사용자 활동의 수나 종류를 추가/감소하거나, 또는 테스트 데이터를 조정함으로써 다양한 워크로드가 만들어짐)
• 데드락이나 자원 소모 같은 중요한 실패를 시뮬레이션하기 위해서는 정확하고 현실적인 테스트 데이터(예, 타입과 볼륨, 여러 다른 사용자 로그인, 제품 ID, 제품 카테고리 등)를 가지고 워크로드를 표현해야 함

스트레스 테스팅을 위한 적절한 워크로드를 식별하는데 아래 활동들이 일반적으로 도움이 된다.

• 업무 분배를 식별(Identify the distribution of work):  각 주요 시나리오에서 시뮬레이션될 업무를 배분한다. 스트레스 테스트 동안 시나리오를 실행시키는 사용자의 수와 타입에 기반하여 배분함
• 최고 사용자 부하를 추정(Estimate peak user loads): 애플리케이션의 최고 부하 조건 동안 최고 예상 사용자 수를 식별한다. 각 시나리오의 식별된 업무 분배를 사용해서 주요 시나리오 당 사용자 부하율을 계산함
• 안티-프로파일 식별(Identify the anti-profile): 정상 워크로드(normal workload)에 안티-프로파일을 적용하는 것으로 시작할 수도 있음. 안티-프로파일에서는 관심 대상 시나리오의 워크로드 배분이 역으로 뒤집혀 있음. 예를 들어, 주문 처리 시나리오의 정상 부하가 총 워크로드의 10%라면 안티-프로파일은 총 부하의 90%로 되어 있으며 남은 부하량은 다른 시나리오들에게로 배분될 수 있음. 안티-프로파일을 사용하는 것은 중요 시나리오가 정상 부하 조건 이상의 부하에 맞닥뜨리도록 보장하기 때문에 스트레스 테스트의 귀중한 시작점 역할을 할 수 있음

스텝 4 - 메트릭 식별하기

• 애플리케이션의 성능 목표와 관련해서 수집하고자 하는 메트릭을 식별한다.
• 정확하게 수집된 메트릭은 애플리케이션이 성능 목표와 견주어 얼마나 성능이 좋은지(또는 나쁜지)에 대한 정보를 제공함. 또한 메트릭은 애플리케이션 내에 문제가 있는 구역이나 병목 구간을 식별하는데 도움을 줄 수도 있음 

아래 표는 성능 메트릭을 기술하고 있다.

프로세서(Processor)	- 프로세서 사용률(Processor utilization)
프로세스(Process)	- 메모리 소모(Memory consumption) - 프로세서 사용률(Processor utilization) - 프로세스 리사이클(Process recycles)
메모리(Memory)	- 가용 메모리(Memory available) - 메모리 사용률(Memory utilization)
디스크(Disk)	- 디스크 사용률(Disk utilization)
네트워크(Network)	- 네트워크 사용률(Network utilization)
트랜잭션/비즈니스 메트릭(Transactions/business metrics)	- 초 당 트랙잭션 수(Transactions/sec) - 성공한 트랙잭션 수(Transactions succeeded) - 실패한 트랜잭션 수(Transactions failed) - 성공한 주문 수(Orders succeeded) - 실패한 주문 수(Orders failed)
쓰레딩(Threading)	- 초 당 경합 수(Contentions per second) - 데드락(Deadlocks) - 쓰레드 할당(Thread allocation)
응답 시간(Response times)	- 트랜잭션 시간(Transactions times)

스텝 5 - 테스트 케이스 생성하기

• 단일 테스트를 실행하기 위한 단계들과 예상 결과를 정의한 테스트 케이스를 생성한다.
• 워크로드 프로파일과 주요 시나리오를 식별하는 것이 테스트 케이스를 구현 및 실행하는데 필수적인 모든 정보를 제공하지는 않는게 일반적임. 스트레스 테스트를 완전히 설계하기 위한 추가적인 입력물에 성능 목표(performance objectives), 워크로드 특성(workload characteristics), 테스트 데이터(test data), 테스트 환경(test environments), 메트릭(metrics) 등이 포함된다.
• 각 테스트 케이스 실행 후 “성공(pass)”, “실패(fail)”, 또는 “판단 보류(inconclusive)”로 표시될 수 있도록 각 테스트 설계는 테스트의 예상 결과와 수집해야할 주요 데이터를 언급해야 함

아래는 ‘주문하기 시나리오’의 테스트 케이스 예이다.

테스트 1 – 주문 시나리오(Place Order Scenario)   워크로드(Workload): 동시 사용자 1,000명 대기 시간(Think time): 각 오퍼레이션 후에 테스트 스크립트에서 1~10초 사이의 무작위 대기 시간을 사용 테스트 기간(Test Duration): 이틀 동안 테스트 실행   예상 결과(Expected results): l  데드락 또는 메모리 소모 때문에 애플리케이션 호스팅 프로세스가 리사이클 되어서는 안된다. l  처리량(Throughput)이 초 당 35 리퀘스트 아래로 떨어져서는 안된다. l  완성된 총 트랜잭션의 95%가 응답 시간(Response time)이 7초 이상이면 안된다. l  경합 관련 이슈(contention-related issues)로 인한 “Server busy” 에러가 총 응답의 10%를 넘으면 안된다. l  테스트 실행 동안에 주문 트랙잭션(Order transactions)이 실패해서는 안된다. 데이터베이스 엔트리가 “성공한 트랜잭션”의 집계와 일치해야 한다.

스텝 6 - 부하를 시뮬레이션 하기

• 선행 스텝들을 적정한 수준으로 완성하고 나면 스트레스 테스트를 실행시키는 부하를 시뮬레이션할 준비가 되어 있어야 한다.
• 각 테스트 케이스에 필요한 부하를 시뮬레이션하고 메트릭 데이터 결과를 수집하기 위해 테스트 도구를 사용한다.

 

일반적으로 테스트 실행이 아래 단계를 따른다.

①     테스트 환경이 테스트 설계에서 의도했던 구성과 일치함을 확인한다.

②     메트릭 수집을 위해 테스트와 테스트 환경이 둘 다 정확하게 구성되었음을 확인한다.

③     테스트를 실행시키기 전에 테스트 스크립트와 원격 성능 카운터가 정확하게 동작함을 확인하기 위한 빠른 “스모크 테스트(smoke test)”를 실행한다.

④     시스템을 리셋하고(시나리오가 시스템 리셋을 포함하지 않는 경우), 정식 테스트 실행을 시작시킨다.

 

Note: 부하를 생성하기 위해 사용하는 클라이언트 컴퓨터(부하 생성기)가 과도하게 스트레스를 받지 않도록 주의한다. 부하 생성 환경 자체가 병목이 있지 않도록 프로세서나 메모리 같은 리소스 사용률이 충분히 낮아야 한다.

스텝 7 - 결과 분석하기

테스트 동안 수집된 메트릭 데이터를 분석하고, 결과를 메트릭의 수용가능한 수준과 비교한다. 요구되는 성능 수준이 달성되지 못했다는 결과가 나오면 병목의 원인을 분석하고 해결한다. 관측된 이슈를 해결하기 위해 아래와 같은 활동을 할 필요가 있을 수도 있다

• 설계 리뷰 수행
• 코드 리뷰 수행
• 테스트 실행 동안 실패의 원인을 디버그할 수 있는 환경에서 스트레스 테스트를 실행시킴