Embian Blog

입사 후 교육과정의 하나였던 "The Art of Application Performance Testing"이라는 책을 읽은 후, 개발자라면 한 번쯤은 읽어보면 좋은 내용이라고 생각되어 이 책을 주제로 두 번에 걸쳐서 포스팅하겠다.

일단 이 책은 원서였고, 초보 개발자의 눈에는 기술된 용어 자체가 무슨 뜻인지 모르는 것들이 너무 많아서 책이 무슨 말을 하는지 파악하기가 힘들었다. 하지만 책을 다 읽고 난 후에 내 머릿속에 남은 것은 퍼포먼스

테스팅을 절대로 무시하면 안 되는 단계라는 것이었다.

먼저 이 책을 읽고 난 초보 개발자 레벨에서 소감을 얘기하자면,

• 퍼포먼스 테스팅은 프로그램의 질을 향상해준다.

• 프로그램 성능을 뒷받침해주는 자료가 된다

• 사용자의 프로그램 사용 만족도를 올려준다.

다시 말해 퍼포먼스 테스팅은 프로그램을 안정적이게 만들어주고 사용할 때 편하게 해줌으로써 사람들이 믿고 쓰게 되는 동시에 그 프로그램을 만든 회사의 로열커스터머가 발생할 수 있다고 생각했다. (예를 들자면 애플 제품만 사용하는 사람들이라든지, 아니면 애플을 매우 사랑하는 사람들이라든지)

이 책에서 제시한 체크리스트들을 통하여 퍼포먼스 테스팅 가이드라인을 잡는 데 도움이 될 수 있는 내용을 소개하고자 한다.

I.왜 퍼포먼스 테스트를 하는가?

이 책의 저자는 "퍼포먼스를 위한 테스팅의 중요함은 고려해볼 사항이 아닌 어플리케이션을 만드는 과정 일부로서의 가치를 지니고 있다." 라고 말하고 있다. 즉, 퍼포먼스 테스트는 선택이 아닌 필수가 되어야 한다는 것이다. 그러면 왜 우리는 퍼포먼스 테스트를 해야 하는가? 답은 간단하다. 뛰어난 성능을 보여주는 어플리케이션은 기업에 이윤을 창출해 주기 때문이다.

퍼포먼스 테스트의 종류는 크게 서비스 지향적 측정(유용성과 응답 시간)과 효율 지향적 측정(처리량과 이용률)으로 나눌 수 있다. 서비스 지향적 측정이라 함은 "사용자에게 서비스를 얼마나 잘 제공하는가?" 라고 정의할 수 있고, 효율 지향적 측정은 "자원을 얼마나 잘 활용하는가?" 라고 정의 할 수 있다.

퍼포먼스 테스팅은 이 두가지의 큰 틀 안에서 퍼포먼스 테스팅 전, 하는 도중, 그리고 하고 나서의 단계로 구분 지을 수 있다.

그러면 이제 퍼포먼스 테스팅을 하기 전에 고려할 사항에 대하여 이야기해 보겠다.

II. 효과적인 어플리케이션 퍼포먼스 테스트의 기초     성능 요구 사항을 확실히 하는 단계.

효과적인 어플리케이션 퍼포먼스 테스트를 위하여 새로운 프로젝트에 대해 우리는 다음의 사항에 대하여 질문해야 할 것이다.

• 사용자들이 어디에 배치되어야 하는가? 그리고 그들이 어플리케이션에 어떻게 연결되어야 하는가?

• 어플리케이션을 배포 했을 때 얼마나 많은 사용자가 존재하는가? 6개월 후? 12개월 후? 2년 후에는 어떠한가?

위의 질문에 대한 답은 다음과 같은 질문으로 이어 진다.

• 각각의 어플리케이션 계층을 위하여 얼마나 많은 서버의 스펙이 필요한가?

• 어떤 종류의 네트워크 인프라 스트럭쳐를 준비해야 하는가?

물론 이러한 질문들에 대하여 즉시 답할 필요는 없지만, 가능성과 퍼포먼스라는 두 가지의 중요한 관점을 미리 생각해야 할 것이다.

퍼포먼스 테스팅 계획을 구성할 때 많은 요소에 대하여 고려해야 하겠지만, 이 책의 저자는 다음과 같은 항목들을 중요하게 짚고 넘어가야 한다고 기술하였다.

1. 적절한 테스팅 툴 선택

적합한 성능 테스트 툴을 고른다.

테스팅 툴 설계 (자동화 테스팅툴들은 다음과 같은 구성을 가지고 있다.)

• 스크립팅 모듈

• 테스트 매니지먼트 모듈

• 로드 인젝터

• 분석 모듈

퍼포먼스 테스팅 툴은 다음에 소개되는 항목들을 포함해야 한다.

• 툴 공급업체의 지원

• 라이센싱 모델

• Proof of Concept (POC)

• 스크립팅 노력

• 솔루션 VS 로드 테스팅 툴

• 자체 제작 또는 아웃소스

2. 적절한 테스트 환경을 디자인

테스트 환경은 최대한 실제 환경과 유사하게 만든다.

• 서버의 숫자와 사양

• 대역폭과 네트워크 인프라스트럭처의 연결

• 어플리케이션 계층의 숫자

• 어플리케이션 데이터베이스의 크기 조정

테스트를 할 가상 환경 구비

테스트 가상환경에 대한 체크리스트

• 서버 갯수

• 로드 밸런싱 스트레티지

• 하드웨어 목록

• 소프트웨어 목록

• 어플리케이션 구성 목록

• 외부 링크

3. 현실적인 성능 목표를 설정

경영자와 그 외의 사람들간의 합의점 도출

핵심성능 목표 설정

• 유용성 또는 가동시간

• 동시성, 확장성, 그리고 처리량

• 반응시간

• 네트워크 사용률 (데이터 볼륨, 데이터 처리량, 데이터 에러 비율을 측정)과 서버 사용률(CPU사용률, 메모리 사용률 ,디스크 입출력, 디스크 공간을 측정)은 성능에 따른 용량의 지표에 사용될수 있다.

4. 퍼포먼스 테스트를 하기에안정적인 버전의 어플리케이션 준비

5. 코드 프리즈를 얻음

6. 비즈니스에 중요한 트랜잭션을 식별 및 스크립팅

트랜잭션 체크리스트

• 탐색 경로에 대한 모호성이 없도록 각 실행 단계를 정의 및 문서

• 모든 입력 데이터 요구사항과 예상되는 응답을 확인해야한다.    

• 트랜잭션에 연관된 사용자의 타입을 결정한다.

• 이 트랜잭션을 위한 커넥티비티 패스가 무엇인가?

• 활성 트랜잭션일것인가 수동 트랜잭션일것인가?

트랜젝션 리플레이 검증

• 단일 사용자 리플레이

• 다중 사용자 리플레이

7.고품질의 테스트 데이터를 준비

인풋데이터 - 트랜젝션에 입력할 데이터

예) 자용자 자격증명, 검색 기준들, 관련 문서들

타겟 데이터 - 현실적인 분량의 유효 데이터를 이용하여 채울 수 있는 데이터.  

예) 사이징, 데이터 롤백

런타임 데이터 - 퍼포먼스 테스트를 실행할때 사용되는 데이터

데이터 시큐리티 - 보호되어야 할 데이터에 대한 툴을 사용

8. 정확한 퍼포먼스 테스트 디자인을 보장

각종 종류의 테스트를 만들어야 한다.

• 베이스라인 테스트

• 로드 테스트

• 스트레스 테스트

• 흡수 또는 안정성 테스트

• 스모크 테스트

• 아이솔레이션 테스트

9. 서버와 네트워크 모니터링 KPI를 식별함

제너릭 템플릿    

• 프로세서 이용 비율

• Top 10 프로세서

• byte 단위의 사용 가능한 메모리

• 초당 페이지 메모리

• 물리 디스크: %디스크 타임

• 네트워크 인터페이스 : 패킷 리시브드 에러

웹과 어플리케이션 서버 계층

• IIS (Microsoft Internet Information Server)

• Oracle application server (OC4J)

• Oracle WebLogic (JRockit)

• IBM WebSphere

• JBOSS

데이터베이스 서버 계층

• Microsoft SQL Server

• Oracle

• IBM DB2

• MySQL

• Sybase

• Informix

메인프레임 계층

• Strobe from Compuwave Corporation

• Candle from IBM

10. 효과적인 퍼포먼스 테스트를위하여 충분한 시간을 할애

• 비지니스 트랜젝션 식별과 스크립트하는 시간

• 충분한 테스트 데이터 식별하고 만드는데 시간

• 테스트 환경 도구 준비 시간

• 퍼포먼스 테스트 준비하고 실행시키는데 들어가는 시간

• 확인된 문제점을 해결하는 시간

우리는 이처럼 여러단계와 세세한 사항들이 퍼포먼스 테스트를 하기 위한 고려대상임을 알았다.

자, 이제 우리는 겨우 퍼포먼스 테스트를 시행하기 전 기초에 대해 준비가 되었다. 너무 많은 양의 준비가 필요하다고 생각되어지나? 어플리케이션의 운명을 좌우한다고 말할 수 있는 퍼포먼스 테스팅은, 이 많은 양의 준비과정을 거쳐 퍼포먼스 테스트를 좀더 효과적이고 짜임새 있게 만들어 준다.

그러면 다음 포스팅에서는 퍼포먼스 테스트의 과정과 결과 분석에 대하여 기술하도록 하겠다.

참고자료 : "The Art of Application Performance Testing" by Ian Molyneaux