페이퍼요약 - 소프트웨어 시스템의 성능 테스팅 경험 by Weyuker

제목: 소프트웨어 시스템의 성능 테스팅 경험(Experience with Performance Testing of Software Systems: Issues, an Approach, and Case Study)

저자: Elaine J. Weyuker 외 1인, 미국

문서유형: 저널 페이퍼(총 10페이지), 2000년

 

기존 플랫폼에서 신규 플랫폼으로 재전개되는 게이트웨이 시스템(3-티어 트랜잭션 프로세싱 애플리케이션의 중간층)의 성능 테스팅 수행 경험을 기술한 자료

---

AT&T의 아키텍쳐 검토(architecture reviews)

• AT&T에서는 아키텍쳐 검토가 소프트웨어 개발 생명주기의 초기(시스템 요구사항 완성 후 하위레벨 설계 완성 전)에 수행됨. 아키텍쳐 검토에서 소프트웨어 시스템에 부정적 영향을 끼칠 가능성이 있는 문제가 식별되고 문제 원인 및 심각도에 따라 분류됨
• 저자가 30건 이상의 아키텍쳐 검토에서 수집된 데이터를 조사하는 동안 성능 이슈가 세 개의 주요 결함 카테고리 중 하나를 차지함을 발견함. 이 단계에서 식별된 성능 문제로 ‘성능 추정치 결여’, ‘데이터 수집 계획의 부재’, ‘성능 예산 결여’가 포함됨
• 저자는 또한 이 조사에서 파레토 타입의 분포를 발견함. 예) 20%의 기능이 80% 시스템 사용을 차지, 프로젝트를 위험에 처하게 하는 이슈들 분포에서 가장 심각한 문제 70%가 프로젝트의 가장 약한 30%에 위치, 프로젝트에 타격을 주는 성능 이슈의 93%가 가장 문제가 있는 것으로 여겨지는 시스템 30%에 집중되어 있음

소프트웨어 성능 테스팅

• 성능 테스팅 수행 시 고려해야 할 중요한 이슈인 확장성(scalability)은 현재 요구되는 것보다 훨씬 많은 워크로드(고객 증가 또는 시스템 기능 증가로 인해 야기됨)를 감당할 수 있는 능력을 말한다. 시스템이 확장될 수 있음을 보장하는 적절한 테스팅이 없으면 워크로드 증가 시 허용할 수 없는 수준의 서비스 거부 또는 반응 시간이 발생할 수 있다.
• 소프트웨어 시스템의 성능을 평가할 때 측정되어야 할 것에 리소스 사용(resource usage), 처리량(throughput), 자극-반응 시간(stimulus-response time), 큐 길이(특정 리소스에 의해 서비스되길 기다리는 중인 평균/최대 태스크 수를 나타냄)가 포함됨
• 성능 평가 시 고려할 필요가 있는 일반적인 리소스에 네트워크 대역폭 요구사항(network bandwidth requirements), CPU 사이클, 디스크 공간(disk space), 디스크 접속 오퍼레이션(disk access operations), 메모리 사용(memory usage)이 포함되며, 특정 프로젝트에서 특별히 중요할 수 있는 리소스에 스위치 사용(텔레콤 프로젝트 경우)이나 데이터베이스 접속률(database access rates)이 있음

성능 테스팅을 위한 워크로드 생성

대표성을 띄는 워크로드(representative workload) 생성 관련 아래와 같은 여러 이슈들이 존재함

• 어디서 데이터가 오는지에 대한 문제(무엇이 실제 대표 워크로드인지 어떻게 알 수 있는가?): 텔레콤 환경에서는 많은 프로젝트가 시스템 트래픽을 일상적으로 모니터하므로 테스터가 ‘운영 프로파일(시스템이 현장에서 여태껏 어떻게 사용되어 왔고 앞으로 어떻게 사용될 가능성이 높은지를 기술)’을 개발할 수 있는 리소스가 제공됨. 시스템의 이전 버전이 가용하지 않거나 과거 사용 데이터가 수집되지 않았다면 유사한 시스템이 성능 테스팅을 위한 워크로드 설계에 가이드를 제공할 수 있음
• 성능 테스트케이스가 평균 워크로드를 반영할지 또는 과부하(스트레스)를 반영할지 여부: 두 경우 모두 부하를 도출할 관측창(the window of observation)을 결정해야 함. “1시간, 24시간, 또는 이보다 더 긴 기간 동안 평균 트래픽을 조사해야 하는가?”, “부하가 적은 시간대와 많은 시간대를 구별해야 하는가(이를 예측 가능한 경우)?”, “주어진 24시간 동안 발생한 최고 부하에 주목할지 아니면 한 달(또는 일 년) 동안 발생한 최고 부하를 조사해야 하는가?” 등을 결정해야 함. 텔레콤 시스템은 1주일을 반복 주기로 생각하는 것이 일반적. 즉, 공휴일이나 자연 재해 같은 특별한 경우를 제외하고는 한 주의 특정 요일의 시스템 사용이 다음 주 해당 요일의 그것과 거의 비슷하며, 따라서 시스템 트래픽 최고치(peaks)와 최저치(valleys)가 매 주 같은 시기에 발생한다.
• 위 질문들의 답이 결정되면 성능 테스팅이 수행될 시스템이 하드웨어 플랫폼상에서 단독으로 돌아가는지를 체크. 만일 다른 시스템과 공통 플랫폼에서 같이 돌아가면 성능 테스팅 동안 테스트 대상 시스템의 워크로드가 백그라운드 워크로드(시스템 가동 시 잔존할 가능성이 있는 타 시스템의 부하)와 함께 실행되어야 함
• 또 다른 고려할 이슈는 평균 이벤트 도착률(an average event arrival rate)을 사용할지 아니면 도착률의 변이(variation)를 서술한 확률 분포를 사용할지 여부. 후자가 시스템 동작의 더 정확한 그림을 반영할 가능성이 높지만 적용하는데 비용이 더 많이 들고 복잡

사례 연구(Case Study)

아래는 저자가 3티어 클라이언트 서버 트랜잭션 처리 애플리케이션의 중간층인 게이트웨이 시스템의 성능 테스팅을 수행한 경험을 기술함. 기 존재하는 이 시스템의 신규 장비 구매가 이미 확정되었고 신규 플랫폼으로 포팅될 소프트웨어 작성이 진행 중인 상황. 즉, 성능 테스팅 결과가 하드웨어 구매에 영향을 미칠 수는 없지만 신규 플랫폼 상에서 직면할 수도 있는 성능 문제를 미리 발견하여 해결하는 것을 목표로 함

1. 시스템 정보

• 시스템이 발신자(caller)의 입력을 받고 호스트 서버에 있는 정보를 반환함. 입력은 듀얼톤 다주파 신호(터치톤) 또는 제한된 어휘의 음성 형태이며, 출력은 사전 녹음된 디지털 음성 또는 컴퓨터 생성된 음성의 형태이다.
• 클라이언트(아키텍쳐의 1-티어)는 발신자와 인터페이스 하는 컴퓨터 시스템인 음성 응답 장치(Voice Response Units: VRUs)로 구성되고, 서버(3-티어)는 최종사용자가 요청한 정보를 포함하는 메인프레임 호스트 컴퓨터로 구성되며, 중간층(2-티어)은 클라이언트가 서버와 인터페이스 하는 것을 허용하는 컴퓨터 시스템인 게이트웨이로 구성됨. 서버는 대개 원거리에 위치하며, 아키텍쳐 관점에서 게이트웨이의 목적은 네트워크 연결의 집결을 허용하고 각 VRU가 수행해야만 하는 프로세싱의 일부를 덜어주는 것
• 게이트웨이가 여러 다른 VRU에 서비스를 제공하고, 각 VRU는 여러 다른 게이트웨이가 제공하는 서비스에 접근 할 수 있다. 이 통신을 위해 게이트웨이와 VRU가 LAN을 공유함. 유사하게 각 게이트웨이 머신이 다수의 원격 서버와 연결할 수 있으며, 다양한 호스트 서버와의 통신을 허용하기 위해 각 게이트웨이가 3개의 다른 네트워크 프로토콜(SNA/3270, TN3270, TCP/IP)을 지원하도록 설계됨
• 아래는 저자가 프로젝트에 대해 잘 아는 멤버와 논의를 통해 생성한 시스템 아키텍쳐이다.

[상위 레벨 시스템 아키텍쳐]

• 아래의 소프트웨어 아키텍쳐 다이어그램도 저자가 프로젝트 팀 멤버와의 대화를 통해 작성함. VRU 상에서 실행되는 Application Script가 최종사용자와 상호작용함. 이 애플리케이션이 호스트 트랙잭션을 수행할 필요가 있을 때 프로세스간 통신(interprocess communications: IPC) 메시지가 게이트웨이 상에서 실행중인 적절한 서버 프로세스로 전송됨. 여기서 트랙잭션은 호스트로 전송된 ‘요청(request)’과 이어서 호스트로부터 받은 ‘응답(reply)’으로 정의됨
• 게이트웨이 상의 서버 프로세스는 호스트 요구사항에 따라 요청을 포맷하고 이를 호스트로 전송함. 응답이 수신되면 게이트웨이 상의 프로세스가 반환된 호스트 데이터를 파싱하고, IPC 메시지를 포맷하고, 응답을 VRU 상의 애플리케이션에게 전송함
• 기존 게이트웨이 시스템은 Unix 운영 체제를 올린 PC 하드웨어(Intel Pentium 프로세서, ISA 버스)에 기반하였음. 성능과 신뢰성을 향상시키고 유지보수 비용을 줄이기 위해 하드웨어 플랫폼을 중급 시스템(다수의 PA RISC 프로세서, 더 큰 RAM, 많은 물리적 I/O 인터페이스)으로 업그레이드하기로 결정

[상위 레벨 소프트웨어 아키텍쳐]

2. 성능 테스팅 목표

• 기 존재하는 게이트웨이의 과거 사용 데이터가 수집되지 않아서 테스팅을 위한 적절한 워크로드를 설계하는데 추정이 요구됨. 신규 시스템이 SNA/3270와 TN3270 프로토콜을 사용하여 호스트 시스템에 연결될 때 처리할 수 있어야 하는 예상 트랜잭션 수를 프로젝트 팀이 추정함. 각각 56Kbps를 처리할 수 있는 56개 링크가 필요하고, 활동중인 80%의 링크와 시스템이 기능할 수 있어야 함(각각 평균 1,620바이트의 트랜잭션을 처리)
• 신규 플랫폼이 이 워크로드를 처리할 수 있다고 벤더가 보장했지만 이를 입증할 만한 적절한 데이터를 제공하지는 않음. 벤더가 자신의 하드웨어를 데이터베이스 서버로써 사용한 경우의 성능 데이터를 제공했지만 게이트웨이 시스템의 기능과 데이터 서버가 제공하는 기능이 질적으로 다르므로 전개에 앞서 실제 운영 시와 유사한 구성(configuration)에서 게이트웨이의 성능을 테스트 하기로 결정함
• 성능 테스팅에서 아래 질문에 답하는 것을 목적으로 함
  1. 새로운 게이트웨이가 사전명세된 리소스 소모 및 지연(latency) 예산 내에서 증가된 최종사용자 볼륨을 지원할 수 있는 충분한 리소스를 가지고 있는가?
  2. 어떤 최종사용자 볼륨에서 이 리소스들이 부적합하게 되는가?
  3. 게이트웨이의 하드웨어와 소프트웨어 아키텍쳐의 어떤 컴포넌트가 성능을 제한하는가? 어디에 병목 현상이 있는가?

3. 상세한 과거 데이터 없이 성능 테스트케이스 설계하기

• 신규 플랫폼이 아직 가용하지 않아서 벤더의 테스트 랩을 빌려 테스트를 수행하기로 함. 이 랩의 제한된 가용성(1주일만 사용 가능)과 비용 최소화의 필요성으로 인해 모든 테스트 활동을 사전에 철저히 계획함. 즉, 벤더의 시설을 방문하기 전에 구체적인 테스트 계획과 테스트스위트를 개발함
• 성능 테스팅을 위한 테스트스위트를 설계하는 것과 기능 테스팅을 위한 테스트스위트를 설계하는 것이 근본적으로 다름. 기능 테스팅에서는 패러미터 세팅의 실제 값이 극도로 중요하지만 성능 테스팅에서는 주된 관심이 워크로드와 입력의 횟수에 있으며 입력의 특정 값은 종종 그다지 중요하지 않다.
• 성능 테스팅에서 평균 워크로드와 최고 워크로드를 모두 고려하기로 함에 따라 이 부하 수준의 결정이 요구됨. 저자의 경험에 따르면 사용 시나리오는 시스템의 전체 성능에 가장 크게 영향을 주는 패러미터를 통해 정의되어야 함. 따라서 이런 패러미터를 식별하는 것이 일차적인 우선순위가 되었고, 이를 위해 게이트웨이의 소프트웨어 아키텍쳐를 조사함(아래 그림)

[게이트웨이 소프트웨어 아키텍쳐]

• 저자는 위 그림에서 게이트웨이의 성능이 3개 프로세스(SNASrv, GwySrv, ComMgr)의 성능과 밀접하게 관련됨을 알아냄
  - SNASrv는 구 플랫폼에는 존재하지 않았던 새 소프트웨어 컴포넌트. 게이트웨이 상에 하나의 이런 프로세스가 존재하며, 한편에서는 3270-기반 호스트와 통신하고 다른 편에서는 SNA/3270 에뮬레이터와 통신하는 것을 목적으로 함
  - GwySrv은 구 플랫폼에 있던 것의 변경된 버전(이 프로세스가 위의 신규 프로세스와 작업할 수 있도록 변경됨, 기능이 추가된 것은 없음). 호스트로의 각 링크에 이 프로세스가 하나씩 존재하고, 각각이 25개까지 다른 에뮬레이터와 상호작용할 수 있음
  - ComMgr은 VRU와 직접 인터페이스함. 게이트웨이 상에 이 프로세스 하나 존재하며, 구 플랫폼으로부터 어떤 변경도 없이 포트 됨
• SNASrv 프로세스가 최종사용자와 통신하는 프로세스 및 고객 호스트 시스템으로의 커넥션을 다루고, GwySrv 프로세스도 최종사용자와 통신하는 프로세스들을 다루므로, ‘고객 호스트 시스템으로의 동시 액티브 커넥션 수’와 ‘동시 발신자 수’가 소프트웨어 성능에 가장 크게 영향을 미치는 두 개 패러미터라고 추론함. 게이트웨이의 전반 성능에 눈에 띄게 영향을 미칠 수 있는 추가적인 패러미터로 ‘발신 당 트랜잭션 수’, ‘트랜잭션 크기’, ‘발신 유지 시간’, ‘발신 도착율’, ‘트래픽 혼합(즉, SNA vs. TN3270 vs. TCP/IP의 비율)’이 있다.
• 이 패러미터들의 현실적인 값을 결정하기 위해 저자가 현 운영 게이트웨이로부터 데이터를 수집하고 분석함. 각 트랜잭션에 대한 특정 타입의 정보(타임스탬프, 응답 시간, LU 수)를 기록하기 위해 추적(tracing) 기법을 사용하였고, 이 작업이 2개의 다른 사이트의 6개의 다른 애플리케이션에서 여러 날 동안 수행됨
• 이렇게 수집된 정보를 사용하여(또한 이전 현장 경험으로부터 나온 일부 추정치도 반영하여) 저자가 아래를 결정함
  - 평균 사용(Average usage): 링크 당 약 40개 LU, 24명의 동시발신자, 발신 당 3개 트랜잭션, 2.5분의 발신 유지 시간, 각 채널 상에서 5초의 발신 도착률. 이것이 각 링크에서 매 3초마다 대략 1개의 트랜잭션에 상응함
  - 과다 사용(Heavy usage): 링크 당 120개 LU, 120명의 동시발신자, 발신 당 4개 트랜잭션, 3.5분의 발신 유지 시간, 각 채널 상에서 5초의 발신 도착률. 이것이 각 링크에서 초 당 대략 2.2개 트랜잭션과 동일함

위 과정을 요약한 성능 테스트케이스 생성의 전형적인 단계가 아래와 같다.

①     시스템의 전반 성능에 직접적으로 영향을 미치는 소프트웨어 프로세스를 식별한다.

②     각 프로세스에 대해 시스템의 성능에 가장 크게 영향을 미치는 입력 패러미터를 결정한다. 선정된 테스트케이스들의 집합이 관리가능한 크기가 되도록 이 패러미터를 필수적인 것으로 제한하는 것이 중요함

③     기존 사용 데이터를 수집하고 분석함으로써 이 패러미터들의 현실적인 값을 결정한다. 이 값들이 의도된 사용 시나리오(평균 워크로드와 과다 워크로드)를 반영해야 한다. 사용될 관측창도 반드시 결정되어야 한다.

④     과거 사용 데이터가 가용하지 않은 패러미터가 있다면 시스템을 개발하는데 사용된 요구사항이나 해당 시스템(또는 유사한 시스템)의 이전 버전을 사용한 경험에 기반하여 합리적인 값을 추정한다.

⑤     주어진 패러미터를 위한 추정 값들이 한 범위(range)를 형성한다면 시스템의 성능 동작에 대한 유용한 정보를 드러낼 가능성이 높은 이 범위 내에서 대표 값들을 선정한다. 선정된 값 각각이 별도의 테스트케이스로 생성된다.

4. 테스트 프로그램 개발

• 설계된 시나리오들을 표현하는 테스트케이스를 구현하기 위해 프로젝트 팀이 발신자를 흉내 내는 두 개 프로그램을 개발함
• 이 프로그램들은 트랜잭션 요청 메시지를 게이트웨이 서버 프로세스로 전송하고 응답을 수신함. 두 프로그램 모두 커맨드 라인에 명세된 크기의 트랜잭션을 수행하는 다수의 동시발신자(simultaneous callers)를 흉내 낸다. 한 프로그램은 트랜잭션 요청을 최대한 빨리 전송하고(즉, 한 요청에 대한 응답을 받자마자 또 다른 요청을 전송), 다른 프로그램은 발신 기간(call duration)과 발신 당 트랜잭션 수(number of transactions per call)를 위한 패러미터를 받아들여 ‘생각시간(think time)’을 추가하는데 이를 사용함으로써 실제 사용자(사람)를 더 비슷하게 흉내 냄(즉, 현실적인 발신 도착률을 시뮬레이션함)
• 호스트 애플리케이션을 위해서는 앞선 기능 테스팅을 위해 사용되었던 기존 단순 애플리케이션을 사용함. 모든 고객 애플리케이션이 게이트웨이를 경유로 비슷한 프로세싱 사이클을 요구하므로 어떤 고객 애플리케이션을 선택하느냐가 이 테스팅에서는 중요하지 않음

5. 성능 테스팅 결과

• 게이트웨이 성능에 대한 벤더의 보장과 현저하게 다른 몇 가지 놀라운 결과가 테스팅에서 드러남. 평균 사용 시나리오와 과다 사용 시나리오 모두에서 필요한 것으로 추정되는 트랜잭션의 작은 부분만을 게이트웨이가 처리할 수 있음을 알게 됨(벤더는 하드웨어가 이정도 크기의 부하를 처리할 수 있다고 장담했었음)
• 벤더 공급 소프트웨어에서 매우 높은 CPU 이용율을 야기하고 게이트웨이의 낮은 성능에 기여하는 세 가지 문제를 식별함. 첫 번째 문제는 호스트에 의한 게이트웨이 폴링 빈도(polling frequency)와 관련, 두 번째 문제는 새 데이터 도착을 위해 여러 LU를 탐색하는데 게이트웨이 서버 프로세스 GwySrv가 사용하는 알고리즘과 관련, 세 번째 문제는 SNA 서버 프로세스가 사용하는 일부 라이브러리 모듈의 비효율적 구현과 관련됨
• 처음 두 개 문제는 비교적 빠르게 해결할 수 있었지만 세 번째 문제는 주의 깊게 설계되어야 하는 벤더 소프트웨어의 변경이 요구됨에 따라 해결이 단순하지 않음