Introduce to Performance test(3/5)

Updated: April 03, 2020

안녕하세요!
지난번 포스트에서는 성능테스트 사전점검 및 계획에 대해 살펴보았습니다.
전체 포스트는 아래와 같으며 이번 포스트에서는 세번째인 ‘분석 단계’ 에 대해 알아보겠습니다.

성능테스트 개요

사전점검 및 계획단계

분석 단계

설계 단계

실행 및 보고 단계

성능테스트 분석 단계에서는 테스트 대상 업무 분석, 성능 요구사항 분석, 아키텍처 분석을 통하여 테스트 대상 업무 선정 및 성능 목표를 수립합니다.
지난 장표에서도 설명했지만 목표가 없으면 자칫 테스트가 미궁속에 빠지게 되어 이도 저도 아니게 될 수 있습니다. 정확한 Workload Modeling을 통해 실제와 유사한 부하모델을 도출하여 오픈 이후의 상황에 대비할 수 있도록 만반의 준비를 갖추는 것이 중요하다고 할 수 있습니다.

Workload Modeling

성능테스트의 가장 중요한 작업중 하나인 Workload Modeling은 Application이 실제 운영 환경에서 받는 부하를 계산/산정하여 실제와 동일한 부하를 생성하기 위한 일련의 분석 작업입니다. 여기서 Workload에 영향을 주는 Application, Infra 시스템과 사용자, 시스템 특성을 고려하여 산정할 필요가 있습니다. 이는 결국 시스템 오픈 후 실 사용량을 사전에 예측하여 시뮬레이션을 통해 장애를 예방하고 성능을 최적화 하기 위함이죠.

그런데 가끔 이런 특성들을 완전히 무시한 고객의 지시로 그들만의 목표에 맞춘 테스트를 하는 경우도 있습니다. 충분한 근거가 뒷받침 되어 설득하면 좋겠지만 고객의 목표에 맞추기 위해 아래와 같은 기적의 계산법이 나올 수도 있습니다. 절대로 피해야 할 상황입니다.

[미용실 기적의 할인률. 테스트는 산으로]

1. Application 분석

프로젝트와 인터뷰한 내역, 프로젝트 산출물을 검토하여 테스트 대상 Application의 주요 특성을 분석합니다. 이때 각 Transaction을 다음의 기준으로 분류 합니다.

성능에 영향을 주는가?
발생 빈도가 높은가?
데이터 처리량이 많은가?
프로세스가 복잡한가?
공통으로 사용하는가?
마감 작업 등으로 인해 특정 시점에 집중적으로 사용하는가?
온라인 업무가 수행되는 시점에 수행되는 Batch인가?

이렇게 분류된 업무들은 테스트 대상 업무 선정 시 참조 자료로 활용합니다.

2. Transaction 분석

Transaction 분석 시 AS-IS의 존재, 부하산정 분석자료의 존재, 유사시스템 존재 유무에 따라 아래와 같이 부하 산정 방식이 구분됩니다.

[Transaction 분석을 위한 순서도]

AS-IS 시스템의 근거자료가 존재한다면 아주 쉽게 부하량 산정이 가능합니다. 그러나 운영 시스템 성능과 스토리지의 한계로 인해 로그파일을 남기는데 한계가 있어 근거 자료의 확보가 쉽지 않습니다. 하나씩 천천히 살펴보겠습니다.

2-1. AS-IS 시스템의 부하산정 자료가 있을 경우

AS-IS 시스템의 Transaction Log를 통해 부하 산정을 할 수 있습니다. 시스템 자체적으로 Log를 남기는 경우도 있고, Application에서 임의로 Log를 남길수도 있으며, 상용 도구를 이용하여 남기는 경우도 있습니다. 예를 들면 Google Analytics 같은 도구가 있죠.

[Google Analystics]

상용 도구를 도입하지 않아도 분석할 수 있는 방법은 있습니다. 이를 위해 다음과 같은 각 Tier별 Log가 필요합니다.

WEB Server: Access Log
WAS Server: Transaction Log
Database: Table Data

2-1-1. WEB Server Access Log

실 사용량과 가장 근접하게 부하량을 산정할 수 있는 자료입니다. 자동화 툴 입장에서는 TPS(Transaction Per Second)산정은 1Page = 1TPS로 산정됩니다.
쉽게 말해 https://cc.sk.co.kr/ URL을 호출했을 때 보여지는 화면 전체를 자동화 툴에서는 1TPS로 계산합니다.
이런 URL들의 호출은 WEB Server log파일에서 확인할 수 있죠.
하지만 다양한 종류의 WEB Server는 각각의 포맷을 가진 Log파일이 있습니다. 여기서 정확한 사용자 수, 처리건수를 도출하기 위해서는 각 Log파일 별로 주요 항목을 도출하기 위한 별도의 작업이 필요합니다. 시스템 사용량이 많은 사이트의 경우 Log 파일의 크기가 5Gb 이상일 수도 있고 여러대의 WEB서버가 있을 경우 더 많은 파일을 분석해야 할지도 모릅니다.(심지어 이런 파일은 열기도 쉽지 않죠.)
이를 분석하기 위해 가급적 도구를 이용하는 것이 좋습니다. 구글링 해보면 다양한 WEB Server Access Log 분석 도구가 존재합니다.
한가지 예로 Apache Log Viewer가 있습니다.

[Apache Log Viewer / 출처: https://www.apacheviewer.com]

이러한 도구를 통한 Log 분석 방법은 차후 별도의 포스팅을 통해 알아보겠습니다.

2-1-2. WAS Transaction Log

WAS에서 바라보는 TPS(Transaction Per Second)는 WEB서버, 자동화 도구와는 관점이 다릅니다. https://cc.sk.co.kr/URL을 호출하면 페이지 안에서 다양한 호출이 발생합니다. 로그인 정보, 메인 이미지, 공지사항, 뉴스, 블로그 등등… 많게는 하나의 페이지에서 20~30개의 호출이 발생하게 되는데 WAS에서는 이를 각각 1개의 호출로 인식하기 때문에 자동화 툴 입장에서는 1TPS(자동화툴) = 20~30TPS(WAS)로 매치되므로 부하량 산출이 어려운게 사실입니다.
이 경우 담당자와 면밀한 회의를 통해 페이지별 주요한 Transaction을 도출하여 해당 Transaction의 호출 건수를 기준으로 산정하거나 목표 자체를 WAS TPS에 맞춰 부하량을 산정할 수 있습니다. 단, 이 경우 TO-BE Transaction과 AS-IS Transaction의 성격을 고려하여 매칭 할 필요가 있죠.
WAS도 분석 도구가 존재하는데요, Log File을 사후 분석하는것 보다는 APM 도구(ex. Jennifer, Dynatrace)의 정보를 기준으로 사용량을 분석하는것이 일반적입니다.(물론, Log File을 별도로 분석할 수도 있습니다)

[WAS APM JENNIFER] / 출처: https://jennifersoft.com]

2-1-3. Database

Database 분석을 통한 Workload Modeling은 한정된 업무에 대해서만 가능합니다.
시간당/일당 주요 테이블의 Insert 건수 등이 해당되죠. 이를 통해 해당 테이블을 사용하는 업무의 입력 건을 기준으로 목표 처리건수를 산정할 수 있습니다.
바꿔서 생각해 보면 입력이 많은 업무 사이트라면 충분히 고려 가능한 분석 방법일 수 있습니다.

모 POS 시스템의 DB 시간당 등록 건수로 산정할 경우
(Peak 시점에 실제 Transaction 최대 전송건수를 기준으로 산정)

시간당 전송 건수: 6,000건

초당 전송 건수: 1.66 TPS (A / 3600(초))

2-2. 신규 시스템이거나, 부하산정 자료가 없는 경우

2-2-1. 유사 시스템이 없는 신규 시스템

신규 시스템일 경우, 사용량 예측이 상당히 어렵습니다. 사업의 성패에 따라 부하량도 달라질 수 있기 때문이죠(성공하면 사용량 증가로 인한 부하 증가, 실패하면 자원 낭비만 발생) 이 경우, 예상 사용자를 예측하여 사용자 관점에서 대외시스템/대내시스템 관점에서 부하량을 산정합니다.
대외 시스템은 대부분 사용자 예측이 어렵기 때문에 가용 가능한 하드웨어 범위 내에서 서비스 가능한 사용자를 유추하고, 서비스 가능 범위 이상의 사용자에 대해서는 NetFunnel(대기순번 제공 시스템. 연말정산 시 볼 수 있음)과 같은 솔루션을 도입해 사용자 유입을 차단하여 안정된 서비스를 제공할 수 있습니다.

[대기순번 제공 시스템 Netfunnel] / 출처: http://www.netfunnel.io/ko/]

대내 시스템은 사용자 수가 한정되어 있으므로 전체 사용자를 근거로 부하량을 산정할 수 있습니다. 이때 TPS를 산정하여 테스트하는 방법과 전체 사용자를 기준으로 테스트 하는 방법이 있습니다. 단, 사용자 기준으로 테스트 시 테스트를 위해 많은 사용자가 필요합니다 자동화 툴에서 사용자=돈과 직결되므로 쉽지 않은 선택입니다.

구매시스템 성능목표 : 3.3TPS
구매 시스템의 총 사용자를 근거로 산정된 동시 사용자에 통상적인 Think Time 경험치를 부여하여 산정

구매 시스템 총 사용자 : 50명

구매 시스템 예상 동시사용자 : 50명 (구매 시스템 총 사용자 * 100%)

전체 총 사용자 : 8,000명

전체 총 사용자 중 예상 동시사용자 : 160명 ( 전체 시스템 총 사용자 * 2%)

Think Time 경험치 : 60초 (MIS/인트라넷시스템 경험치 : 15초~90초, 보수적 접근)

목표 평균응답시간 : 3초

목표 TPS : 3.3 TPS (동시 사용자(210명) / (목표 평균 응답시간 3초 + Think Time 경험치 60초))

2-2-2. 신규 시스템과 유사한 시스템 참조

업무 패턴이 유사하거나 서비스 형태가 비슷할 경우 이 시스템의 부하산정 결과 또는 운영 로그등을 확보하여 부하량을 산정할 수 있습니다. 물론 이 경우 서비스 대상이 다르므로 이에 대한 보정치를 적용할 필요가 있습니다. 아래는 이를 적용한 부하 산정 예시입니다.

유니버시아드 대회 성능테스트 부하 산정
AS-IS 자료 및 유사 사례가 없어 연도별 각 대회의 성능치와 사용자 비교를 통해 성능목표 산정(구글링을 통한 대회별 자료 조사)

[유니버시아드 대회 성능목표 산정]

국제 스포츠 종합대회 비교표
규모면으로 봤을때는 올림픽>유니버시아드>아시안게임 순서가 되지만 인원수로 보면 아시안게임>올림픽>유니버시아드 순서

[국제 스포츠 종합대회 비교표]

이를 근거로 아래와 같이 산출하였습니다.

목표 TPS : 43.3TPS(서버당(총 7대))

런던 올림픽, 소치 올림픽의 참가국, 동시사용자 수를 비교하여 목표 동시사용자 수를 산정 함
. Peak시 동시사용자 수(런던2012 기준) : 409,190명/분(참가국 기준 약 83%)
. Peak시 동시사용자 수(소치2014 기준) : 337,750명/분(참가국 기준 약 193%)
. 두 대회의 중간 값 : 373,470명
. 가중치 부여 : 37,347명(373,470 * 10%, 2년 주기로 자주 열림, 대학생 연령대 선수위주, 올림픽 메달획득량 증가에 따른 관심도 하락)
. 반올림 : 37,400명

서버의 초당 처리 건수를 동시사용자 수에 응답시간 및 ThinkTime을 적용하여 산정 함
.전체 처리건수 : 303.6TPS(동시사용자(37,400명) / (응답시간 3초 + ThinkTime 120초))
.서버당 처리건수 : 43.3TPS(303.6TPS / 7개 서버)

3. Architecture 분석

Architecture 관점에서 성능관련 이슈 및 리스크를 파악하고 도출하기 위하여 Architecture 분석을 수행합니다. 예를 들면 병목구간을 미리 식별하여 최적화 작업을 수행하는 것이죠. 이를 위해 관련 산출물(Architecture 정의서 등) 검토, Hardware/Software/Network의 논리적 물리적 관점에서의 검토, Cloud 구성정보 검토를 수행하게 됩니다.
주요한 수집 항목은 아래와 같습니다.

서버 기본 정보 (IP, Port, Cloud 환경 등)
서버 탑재 S/W 정보, 관련 모듈 및 업무 처리 방식
서버 구성 방식 및 연결 방법
내/외부 Interface 및 N/W 구성 방식
사용자 접속 경로
성능 관련 S/W 설정 상태 및 설정값 조사
Cloud 종류
POD 구성정보(CPU, Mem, 종류 및 수량)
Middleware, Webserver, WAS, Package
DBMS 종류, 버전, 구성정보(이중화 등)
O/S 종류, 버전
SSO, 검색엔진
기타 성능 관련 정보

성능테스트 수행 전 이 항목들을 통해 병목구간의 유추가 어느정도 가능하며 설정값의 최적화 내용을 확인할 수 있어 상당히 중요한 정보입니다. 물론 사전에 충분히 파악했다고 해도 아래와 같이 생각지도 못한 곳에서 문제가 발생하기도 합니다.

MSSQL DBMS에서 Standard와 Enterprise의 차이로 인해 할당된 CPU Core의 절반밖에 쓰지 못하는 문제점 발생
링크: SQL Server Edition Scale Limits

4. 대상업무 선정 및 성능목표 수립

4-1. 대상업무 선정

자동화 스크립트 작성을 위한 테스트 대상 업무를 선정합니다.
업무 성격에 따라 시스템에 가해지는 부하가 달라질 수 있어 이를 고려하여 Workload Modeling에서 분석한 자료를 바탕으로 대상업무를 선정합니다. 이미 Workload Modeling을 통해 분석이 완료되었다면 아래의 업무선정 측정 Factor를 기준으로 대상업무를 선정합니다.(물론 신규 시스템이라면 어느정도 사용량 유추가 필요합니다)

발생 빈도
특정 시점 사용 빈도
사용자 수
Application 복잡도
고객 및 프로젝트 요청

AS-IS 로그 분석을 통해 도출된 결과 중 발생 빈도수를 기준으로 정렬하여 가장 높은 업무 위주로 대상업무를 산정하되, 중복 업무, TO-BE 미 전환 업무 등 소거하여 업무를 선정할수 있으며, 신규 시스템은 업무 전체를 대상으로 아래와 같이 평가항목 별 점수를 기준으로 산정하여 대상업무를 선정할 수도 있습니다.

평가항목(예시)	기준값	5점	4점	3점	2점	1점
발생빈도	월평균 사용일	25일	20일	10일	5일	1일 미만
사용자 수	일 최대 사용자 수	10명 이상	7명 미만	5명 미만	3명 미만	1명 미만
특정시점 집중사용	최고 사용시기	일 20회	일 15회	일 10회	일 5회	일 1회
복잡도	어플리케이션 분석자료	복잡				간단
고객 요청	어플리케이션 분석자료	있다				없다

단, 대상업무 선정 시 다음의 사항을 고려하여 선정합니다.

시스템 규모 및 업무 전체 개수
대상업무 Coverage 범위
사용자 수
Architecture 및 CRUD
개발 완료 여부
업무 성격
POD 측정 Coverage 범위 고려

4-2. 성능목표 수립

선정된 대상업무를 기준으로 각각의 성능목표를 수립합니다. 성능 목표는 Workload Modeling에서 분석된 최종 성능 목표 수치(TPS 혹은 동시유저 수)를 기준으로 각 대상업무에 분산 부여합니다. 이때, 다음의 항목을 근거로 수립합니다.

프로젝트 산출물
- RFP상 비기능 요구사항 정의서/명세서
- 프로젝트 품질 목표
성능부하 테스트 분석 단계에서 도출된 자료
- 성능 요구사항 분석 자료
- Architecture 분석 자료
- 테스트 대상 업무 선정 자료
고객 요구사항

이를 근거로 선정된 대상업무에 업무별 목표 응답시간, 동시유저 수, TPS ,처리건수를 아래와 같이 산정합니다.
단, 여기서 업무비율은 Workload Modeling에서 분석한 업무별 빈도수 비율에 제외된 업무의 비율을 보정하여 적용합니다.

[대상업무별 성능 목표]

끝마침

이로써 Introduce to Performance test의 세 번째 포스팅을 마쳤습니다. 분석 단계는 테스트의 방향을 결정짓는 중요한 단계입니다. 정확한 Workload Modeling을 통해 목표를 명확히 하여야만 성공적인 성능테스트를 수행할 수 있습니다.
다음 포스팅은 시스템 설계에 대한 포스팅을 기술할 예정이므로 많은 관심 부탁드립니다.

감사합니다.

Twitter Facebook LinkedIn

홍성진