성능 테스팅(Performance testing)
- 성능 테스팅은 속도(speed), 안정성(stability), 신뢰성(reliability), 확장성(scalability) 같은 시스템 반응(responsiveness)을 판단하는 비기능적 테스팅이다.
- 출시 전에 비즈니스 핵심 애플리케이션의 성능 테스팅을 수행하는게 기능 테스팅 못지 않게 중요하다. 연구에 따르면 응답 시간이 5초를 넘어설 때 애플리케이션의 사용자 대화 속도(user conversation rate)가 악화되기 시작함
- 성능 테스팅의 평균 비용이 총 개발 비용의 2.5%에 달함. 이미 생산 환경에 놓인 애플리케이션의 저조한 성능을 고치는데 드는 비용은 개발 비용의 거의 25%에 육박할 수 있음
성능 테스팅의 목표(GOALS)
애플리케이션 상에 성능 테스트를 수행하는 주요 목표가 아래와 같다.
- 생산 준비 정도(Production Readiness)에 대한 정보 얻기
– 예상 부하 조건 동안의 시스템 응답 시간(response time) 체크
– 예상 못한 부하 조건 동안의 시스템 행동
– 시스템 확장성(scalability) 체크
– 최적 성능을 위한 가장 좋은 구성 설정(best configuration settings)
– 사용자 부하가 치솟는(spike user loads) 동안의 시스템 행동
– 시스템 안정성(stability) - 어떤게 더 성능이 좋은지 보기 위해 동일한 소프트웨가 올라간 두 개 플랫폼을 비교
- 시스템 구성의 성능 특성(performance characteristics)을 비교
- 성능 기준(performance criteria)을 비교 잣대로하여 시스템 평가
- 처리량 수준(throughput level) 찾기
- 애플리케이션의 어떤 부분이 어떤 조건 하에서 낮은 성능을 보이는지 발견하기
- 성능 문제의 근원 찾기
- 시스템 튜닝 지원
성능 테스팅의 타입
성능 테스팅은 아래를 포함한 여러 타입을 가질 수 있다.
부하 테스팅(LOAD TESTING)
- 부하 테스팅은 수용가능한 한계 내에 있는 다양한 부하 레벨에서 애플리케이션 행동을 테스트하기 위해 수행된다.
- 부하 테스팅 동안 주의를 집중해야할 주요 패러미터는 응답 시간(Response Time)이다.
- 부하 테스팅을 통해 답해야 하는 질문이 아래와 같다
– 정상적인 부하 조건(normal load conditions) 하에서 애플리케이션이 얼마나 잘 동작하는가?
스트레스 테스팅(STRESS TESTING)
- 스트레스 테스팅은 애플리케이션 성능이 악화되는 붕괴점(break point)을 발견하기 위해 수행된다.
- 스트레스 테스팅 동안 집중해야할 주요 패러미터로는 응답 시간과 처리량(Throughput)이 있다.
- 스트레스 테스팅을 통해 답해야 할 질문이 아래와 같다.
– 생산 부하(the production load)가 예상 부하(the anticipated load)를 넘어서면 어떤 일이 발생하는가?
– 어떤 종류의 실패(failures)에 대비해야 하는가?
– 어떤 지표(indicators)를 찾아야 하는가?
소크/내구성 테스팅(SOAK/ENDURANCE TESTING)
- 소크 테스팅은 애플리케이션이 아주 긴 기간 동안의 지속적인 부하(continuous load)를 감당할 수 있는지 판단하기 위해 수행된다.
- 소크 테스팅 동안 주의를 기울여야 할 주요 패러미터는 메모리이다.
- 소크 테스팅을 통해 답해야 할 질문이 아래와 같다.
– 메모리 누수(memory leaks)가 있는가?
– 성능이 시간 경과 동안 일관적인가?
– 아직 발견하지 못한 천천히 심화되는 문제들이 있는가?
볼륨 테스팅(VOLUME TESTING)
- 볼륨 테스팅은 갑작스런 사용자 증가(sudden user increase)에 대한 애플리케이션 성능을 결정하기 위해 수행된다.
- 볼륨 테스팅 동안 집중해야 할 주요 패러미터는 응답 시간이다.
- 볼륨 테스팅을 통해 답해야 할 질문이 아래와 같다.
– 극적인 부하 변화를 시스템이 감당할 수 있는가?
– 애플리케이션이 다양한 DB 수준에서 어떤 행동을 보이는가?
– 생산 부하(the production load)가 예상 최고 부하(the anticipated peak load)를 넘어서면 어떤 일이 발생하는가
확장성 테스팅(SCALABILITY TESTING)
- 확장성 테스팅은 시스템의 확장 능력을 측정하기 위해 수행된다.
- 확장성 테스팅 동안 주의를 기울여야 할 주요 패러미터는 응답 시간과 초당 트랜잭션 수(Transactions per Seconds: TPS)이다.
- 확장성 테스팅을 통해 답해야 할 질문이 아래와 같다
– 시스템의 최대 TPS가 얼마인가?
– 정상 부하 조건과 최고 부하 조건 각각에서 시스템 수용량이 비즈니스 볼륨을 맞출 수 있는가?
성능 테스팅의 전제조건(PRE-REQUISITES OF PERFORMANCE TESTING)
성능 테스팅 활동을 시작하기 앞서 충족되어야 하는 사전 조건들이 있으며, 이런 조건들을 충족시키지 않고 성능 테스팅 활동을 실행하는 것은 아주 의미 없는 결과를 낳을 수 있다. 이런 전제 조건들이 아래와 같다.
- 안정적이고 결함이 없는 전용 환경
- 생산 환경(production environment)과 유사한 성능 테스팅 환경
- 성능 테스팅 동안 다른 테스팅이 수행되지 않음
- 실제 가동(go live)으로 가기 전에 성능 테스팅
- 성능 테스팅 계획 개발
- 테스트 데이터 준비
- 성능 테스팅 요구사항 수집
– 애플리케이션 아키텍쳐
– 애플리케이션 개발 기술
– 서버 정보
– 애플리케이션 사용 정보(Application usage information)
– 애플리케이션 사용 패턴(Application usage patterns)
– 성능 승인 기준(Performance Acceptance criteria)
성능 테스팅 주기(PERFORMANCE TESTING CYCLE)
통상적인 성능 테스팅 주기가 아래의 3개 활동으로 구성된다.
① 애플리케이션 성능 패러미터를 결정하기 위해 성능 테스트를 실행한다.
② 애플리케이션이 성능 목표를 충족시키는지 여부를 조사하기 위해 결과를 분석한다.
③ 성능 병목을 해결하기 위해 애플리케이션을 최적화한다.
성능 목표가 달성될 때까지 이 3 단계 성능 테스팅 주기가 반복된다.
성능 테스팅 활동(PERFORMACNE TESTING ACTIVITIES)
성능 테스팅 프로세스에서 수행되는 활동들이 아래와 같다.
1. 테스트 환경 식별하기(Identify Test Environment)
성공적인 성능 테스트를 위해서는 성능 테스트 환경이 생산 환경(production environment)을 정확하게 복사해야 한다. 생산 환경과 유사한 테스트 환경을 식별하기 위해 아래 활동들이 수행된다.
- 생산 환경(생산 환경의 컴포넌트와 상세 사항들)을 식별한다.
- 성능 테스트 환경을 식별한다.
- 테스트를 위해 필요한 하드웨어와 소프트웨어 자원을 식별한다.
2. 성능 승인 기준 식별하기(Identify Performance Acceptance Criteria)
성능 테스트는 정량적 목표(quantitative goals)에 대해 실행되고 이 목표들을 기준으로 테스트 결과가 검증되므로, 현실적인 정량적 목표를 설정하는 것이 매우 중요함. 성능 테스팅 메트릭과 각 메트릭의 수용가능한 값은 아래 활동들을 통해 식별된다.
- 응답 시간, 처리량, 자원이용률 목표를 식별한다.
– 응답 시간: 예, “제품 카달로그가 3초 이내에 반드시 디스플레이 되어야 한다.”
– 처리량: 예, “시스템이 반드시 초 당 100 트랜잭션을 지원해야 한다.”
– 자원이용률: 애플리케이션이 소비하는 자원량(프로세서, 메모리, 디스크 I/O, 네트워크 I/O) - 최대 사용자 부하: 이 테스트 목표는 특정 하드웨어 구성 상에서 얼마나 많은 사용자가 실행될 수 있는지 결정한다.
- 비즈니스 관련 메트릭: 이 테스트 목표는 정상 값과 최고 값에서의 비즈니스 볼륨에 매핑된다(예, 주문 건수, 주어진 시간 동안 처리되는 헬프 데스크 전화 건수)
3. 테스트를 계획하고 설계하기(Plan and Design Test)
적절한 성능 시나리오 선택은 성능 테스트에서 애플리케이션의 진짜 성능을 알아내는데 아주 중요한 태스크임. 성능 테스트 시나리오가 그 중요도(importance), 빈도(frequency), 성능 영향력(performance impact)에 기반하여 식별된다. 성능 테스트를 위한 테스트 시나리오 선택 기준이 아래와 같다.
- 비즈니스 핵심 시나리오(Business critical scenarios)
- 가장 많이 접근되는 시나리오
- 성능을 저해하는 시나리오
테스트 시나리오 선택과 별도로 테스트 데이터도 이 단계에서 준비된다.
4. 테스트 환경 구성하기(Configure Test Environment)
모든 성능 테스트 요구사항이 식별되면 구현 단계가 오게 됨. 이 단계에서는 테스트 환경이 성능 테스팅의 첫 단계(즉, 테스트 환경 식별 단계)에서 식별된 대로 셋업된다.
5. 테스트 설계 구현하기(Implement Test Design)
테스트 환경을 구성한 후에는 식별된 성능 시나리오의 스크립트를 성능 테스팅 툴의 도움을 받아 작성한다. 아래는 테스트 설계 구현 단계에서 수행되는 활동들 목록이다.
- 식별된 테스트를 성능 테스팅 툴을 가지고 스크립트화함
- 모든 사용자 액션을 시뮬레이션함
- 테스트 케이스 설계(사용자 배포)
- 서비스 수준 협약(Service Level Agreement: SAL)
6. 테스트 실행하기(Execute Tests)
여러 다른 시스템 자원 구성에서 여러 다른 사용자 셋에 대한 테스트 스크립트를 실행하고, 추세를 보기 위해 테스트 결과를 모니터한다.
7. 보고서 분석하기와 재테스트하기(Analyze Reports and Retests)
성능 테스트의 실행 및 그 결과 수집이 완료되면 아래 활동들이 수행된다.
- 테스트 결과를 분석한다
- 분석 결과를 문서화하고 모든 이해관계자와 공유한다.
- 의도한 결과를 받을 때 까지 새로운 구성에서 애플리케이션을 재테스트 한다.
성능 징후 및 이슈(PERFORMANCE SYMPTOMS AND ISSUE)
애플리케이션 성능 병목(performance bottlenecks)이 애플리케이션 인프라구조의 다양한 영역에서 등장할 수 있음. 아래는 애플리케이션의 다양한 레벨에서 나타날 수 있는 성능 증상의 목록이다.
웹 애플리케이션 성능 문제의 징후
- 긴 사용자 응답 시간
- 긴 서버 응답 시간
- 메모리 누수
- 높은 CPU 사용
- 열려있는 커넥션이 너무 많음
- 너무 긴 리퀘스트 큐
- 데이터베이스의 테이블 스캔이 너무 많음
- 데이터베이스 데드락
- 에러가 있는 데이터가 반환됨
- HTTP 에러
- 페이지가 가용하지 않음
- 페이지 체크 에러
전형적인 데이터베이스 문제
- 충분하지 않은 인덱싱: 쿼리 프로세싱을 개선하기 위해 데이터베이스 인덱싱 튜닝
- 조각난 데이터베이스: 테이블 레코드들을 인접 페이지에 놓음
- 유효 기간이 지난 통계치: 쿼리 옵티마이저 성능을 저하시킴
- 결함이 있는 애플리케이션 설계: 과도한 DB 콜, 과도한 데이터 리퀘스트
전형적인 웹 서버 문제
- 좋지 않은 서버 설계: 비효율적인 데이터 또는 페이지 캐싱
- 메모리 문제: 물리적인 메모리 제한
전형적인 앱 서버 문제
- 좋지 않은 데이터베이스 튜닝: 애플리케이션 서버가 너무 많은 DB 리퀘스트를 보냄
- 좋지 않은 캐시 관리: 높은 CPU 사용과 디스크 액세스를 야기
- 좋지 않은 세션 관리: 높은 CPU 사용, 디스크 액세스, 그리고 타임아웃을 야기
- 좋지 않은 보안 설계: https 프로토콜의 과도한 사용
- 높은 CPU 사용: CPU 사용이 70% 이상이면 문제가 있음을 나타냄
네트워크 문제
네트워크 문제들의 잠재적 근원이 아래와 같다.
- 방화벽 처리량
- 인터넥 액세스 처리량
- 부하 분산 장치, 게이트웨이, 라우터
통상적인 수리 순서(TYPICAL ORDER OF FIXES)
성능 병목이 식별되고 나면 그것을 수리하는 단계가 오는데, 기능 결함과 마찬가지로 성능 병목도 우선 순위가 매겨지고 그 순서 대로 수리됨. 아래는 수리의 통상적인 우선 순위 목록이다.
- 현 애플리케이션 설계를 개선: 알고리즘, 캐싱, DB 호출, 메모리 사용
- 하드웨어 업그레이드: RAM, CPU, 네트워크 대역폭
- 소프트웨어 인프라구조 업그레이드: OS, 웹 서버, 데이터베이스(데이터베이스 연결 폴링)
- 시스템 아키텍쳐 업그레이드: 클라이언트 서버에서 기본 n-tier로, 기본 n-tier에서 엔터프라이즈 n-tier로, 소프트웨어와 하드웨어 변경, 정적 자원을 서비스하기 위해 Tomcat 앞에 Apache HTTPD 사용, 하드웨어 부하 분산 사용
성능 테스팅의 난제(CHALLENGED WITH PERFORMANCE TESTING)
성공적인 성능 테스트를 수행하기 위해 적절하게 다룰 필요가 있는 많은 난제들이 있음. 아래는 이러한 난제들의 목록이다.
- 테스트 환경 셋업
- 거대한 데이터의 수집 및 분석
- 병목의 근본 원인 식별
- 공동의 노력이 요구됨(제품 벤더, 아키텍트, 개발자, 테스터, 데이터베이스 관리자, 시스템 관리자, 네트워크 관리자)
- 정확한 결과 확보하기
- 클라이언트의 참여
- 방화벽 내에서 테스팅
- 신 기술의 성능 테스팅
- 라이브 환경 상의 테스팅
- 높은 비용
성능 테스팅 모범 관행(PERFORMANCE TESTING BEST PRACTICES)
성공적인 성능 테스팅 활동과 관련된 많은 난제들이 존재하지만, 성능 테스터가 성능 테스트 수행의 모범 관행을 따른다면 이런 난제들을 일부 극복할 수 있음. 아래는 모범 관행의 예이다.
- 사용자 램프업과 램프다운 접근 방법을 사용한다.
- 램프업과 램프다운 기간 동안 수집된 결과를 무시한다.
- 성능 시나리오들을 하나의 단일 테스트로 결합하기 전에 성능 시나리오들의 개별 테스트를 실행한다.
- 스크립트를 확인하기 위해 단일 사용자로 베이스라인 테스트를 실행한다.
- 낮은 부하에서 시스템 메트릭를 확인하고 시스템이 높은 부하에서 테스트 될 준비가 되었는지 체크하기 위해 의도된 부하량의 15~20%를 가지고 벤치마크 테스트를 실행한다.
- 테스트를 안정된 피크 부하에서 적어도 10~15분 동안 실행시킨다.
- 결과를 확신하기 위해 테스트를 최소 3번 반복한다.
- 테스트를 다른 시간 대에서 실행시킨다.