시스템이 작동하는 시간에서 고장이나 보수 등으로 사용하지 못한 시간을 제외한 전체 작동 시간을 계산하기 위한 오픈 전 테스트

가용성 테스트

 

시스템에서 재해 복구를 테스트하여 소규모 오류(예: 네트워크 카드 오류)에서 프로덕션 서버 손실에 이르기까지 다양한 오류 수준에서 복구하는 기능을 확인해야 합니다.

재해 복구 테스트에는 다음 단계가 포함되어야 합니다.

 

개별 하드웨어 구성 요소 오류를 테스트합니다.

네트워크 또는 디스크와 같은 개별 하드웨어 구성 요소 오류로부터 복구하는 시스템의 기능을 테스트해야 합니다.

 

단일 BizTalk 서버 오류를 테스트합니다.

대부분의 BizTalk Server 프로덕션 환경에서 호스트 처리는 단일 BizTalk 그룹에서 실행되는 여러 컴퓨터에 BizTalk Server 분산됩니다. 그룹의 서버 중 하나가 실패하는 경우 BizTalk 그룹이 호스트 처리를 계속하는 기능은 무엇인가요?

 

클러스터 노드 장애 조치(failover)를 테스트합니다.

Windows 클러스터링을 사용하여 데이터베이스 또는 BizTalk 호스트에 고가용성을 제공하는 경우 BizTalk Server 클러스터 노드 장애 조치(failover) 기능을 확인해야 합니다. 

 

로그 전달을 사용하여 BizTalk Server 데이터베이스 복구를 테스트합니다.

재해 복구를 사용하여 환경의 가용성을 높이기 위해 수행해야 하는 단계

 

데이터베이스 복구를 확인해야 BizTalk Server 합니다.

로그 전달을 사용하여 데이터베이스를 백업하고 복원

 

 

1.시스템 대체 작동 (주 시스템의 작동이 정지되면 예비 장치가 자동으로 대체 작동함)) 테스트

 1.1 사용자가 직접 이용하는 프론트 엔드 영역 테스트

 1.2 사용자가 아니라 프로그램에 의해 이용되는 백 엔드인 테스트

 1.3 동시에 복수의 적용 업무를 지원할 수 있도록 복수 이용자의 요구에 호응해서 데이터를 받아들이고 저장,

      공급하기 위하여 일정한 구조에 따라서 편성된 데이터의 집합 테스트

 

2. 테스트 기간

2.1 Fronet End

2.2 Back End

2.3 Database

 

 

 

IT 서비스의 주요 성능 이슈

특성	내용
효율성	서비스를 제공할 때 시스템의 자원사용량과 응답시간이 보장되는가?
안정성	장시간 운영 시 일정한 수준의 서비스가 제공되는가?
가용성	과부하 상태에서 서비스가 중단되지 않고 유지되는가?
신뢰성	서비스의 기능상 오류가 발생하지 않고 지속적으로 정상 기능을 수행하는가?
이식성	시스템 변경 시에도 일정 수준의 서비스가 제공되는가?
장애조치	장애 발생 시 신속하게 조치할 수 있는가?
용량계획	향후 서비스 사용량에 따라 시스템의 용량 계획을 어떻게 세워야 하는가?

효율성

측정하기 위해서는 사용자들이 IT 서비스를 요청해서 처리할 때의 시스템의 자원사용량과 응답시간을 측정한다.

자원 사용량을 어느 정도 사용하는 상황 하에서 IT 서비스의 응답 시간도 확인해야 한다.
이론적으로는 자원 사용량이 100%에 도달하기 전까지는 응답 시간의 지연 현상이 발생하지 않는다. 하지만 자원 사용량이 높은 경우 시스템에 여유가 없기 때문에 응답 시간 지연 현상이 자연스럽게 나타나게 된다. 이 경우 시스템의 용량에 비해 부하가 높게 들어오는 것이므로 문제가 되지 않는다. 하지만 자원 사용량은 낮으면서 목표 처리량에 비해 불안정한 응답 시간이 나타난다면 반드시 그 원인을 분석하고 해결해 효율성을 확보해야 한다.

안정성

측정하기 위해서는 오랜 시간 IT 서비스를 요청해 시스템의 CPU나 메모리 사용량이나 세션 연결 및 해제, 생성되는 스레드 개수 등의 추이를 분석한다. 장시간 서비스가 제공되더라도 메모리 누수나 CPU 이상 사용, 유령 세션 발생, 혹은 스레드의 무한 증식 등이 발생하면 안 된다.
하지만 만일 장시간 운영했을 때 앞서 언급한 현상들이 발생한다면 심각한 응답시간의 저하와 시스템 다운 등 장애가 발생할 수 있다. 안정성 측정은 일정 수준의 부하 상황에서 시간과 자원 사용량이 어떤 관계도 갖지 않음, 다시 말해서 시스템이 시점과 상관없이 일정한 성능으로 유지되는 것을 말한다.

가용성

시스템의 용량에 버금가거나 다소 높은 수준의 부하 상황에서 시스템이 다운되거나 서비스가 중단되는 현상, 다시 말해 실패한 서비스 비율(Fail Rate)을 측정한다.

신뢰성

테스트 데이터에 상관없이 목표 시간 이내에 올바른 결과 혹은 오류를 출력하는 것으로 측정한다. 다양한 테스트 데이터를 준비한다면 그만큼 정상적으로 처리된 요청과 잘못 보낸 요청들의 응답시간을 다양하게 측정할 수 있다.

장애조치와 용량계획은 앞서 설명한 항목과는 좀 다르다.

장애조치

운영 프로세스와 관련된 내용으로 장애를 판단하는 주요 요소는 서비스의 연속성이다. 서비스의 연속성은 응답시간을 기준으로 해 판단하는 경우가 많다. 응답시간이 느려지거나 시스템이 요청에 대해 응답을 못하는 경우에 이를 분석하는 것이 아니라 서비스를 재개시키는 과정을 말한다.

용량계획

서비스의 처리 복잡도와 사용량 추이를 분석해 시스템의 임계 성능과 비교한 시스템의 증설계획을 세우는 것을 말하는 데, 이는 시스템의 자원사용량과 응답시간의 상관관계를 통해 근거자료를 만들 수 있다.
지금까지 언급했던 여섯 가지 항목들이 만족된다면 안정된 IT 서비스를 제공할 수 있을 것이다.

IT 서비스의 성능 지표

항목	정의 (단위)
TPS	Transaction Per Second. 시스템이 초당 처리하는 업무 수 (TPS)
평균 응답시간	클라이언트가 서비스를 요청하고 응답을 받기까지 걸리는평균적인 소요시간(초)
최대 응답시간	클라이언트가 서비스를 요청하고 응답을 받기까지 걸리는최대 소요시간(초)
CPU 사용량	부하 상황에서 서버에서 IT 서비스를 제공할 때의 CPU사용량(%)
메모리 사용량	부하 상황에서 서버에서 IT 서비스를 제공할 때의 메모리사용량(%)
Fail Rate	전체 요청 건수 대비 오류 발생 건수(%)
Execution Time PerDataVolume	전체 데이터 크기에 따른 IT 서비스 처리 시간- OLAP 서비스의 응답시간
동시 사용자	같은 시간대에 같은 IT 서비스를 요청하는 사용자 수(명)
처리량(Throughput)	단위 시간 당 대상 시스템에 의해서 처리되는 요청 건수(bytes/sec)
네트워크 사용량	초당 네트워크에서 전송되는 패킷이나 비트수(PPS or BPS)

익숙한 지표도 있고, 생소한 지표도 있다. 지금부터 나열한 항목들을 조금 더 자세하게 알아본다.

TPS(Transaction Per Second)에 사용하는 트랜잭션은 사전에 정의된 업무단위이다. 다시 말해 IT 서비스를 제공할 때 시스템이 처리하는 부하량이 곧 TPS다. 보통 시스템의 부하상황을 말할 때 그 기준이 되는 지표를 TPS로 삼는 경우가 많다.

응답시간은 평균과 최대, 그리고 간혹 표준편차 혹은 90% 응답시간 등을 지표로 삼는다. 이렇게 지표를 삼는 이유는 응답시간이 크게 흔들려서 최소 응답시간과 최대 응답시간이 크게 차이나거나, 서비스가 안정적으로 이뤄지고 있다고 판단하기는 힘들지만 평균만을 기준으로 볼 때 크게 차이가 없는 경우가 있기 때문이다. 응답시간은 사용자가 IT 서비스의 성능을 가장 직접적으로 느끼는 지표이기에 자원 사용량과 함께 반드시 확인해야 한다.

자원사용량은 시스템의 CPU나 메모리의 사용량을 뜻한다. 자원사용량은 IT 서비스가 제공되는 동안 시스템이 얼마나 효율적으로 일하는지를 판단하는 지표이며, 동시에 IT 서비스를 제공함에 있어서 안정성을 판단하기 위한 지표이다.
Fail Rate는 전체 서비스 요청 대비 한 오류 발생률을 말한다. 일반적인 상황에서 어떤 IT 서비스건 내/외부적인 요인으로 정상적인 응답을 하지 못하는 경우가 발생한다. 이는 소프트웨어의 테스트나 시스템 테스트만 가지고는 밝혀내기 힘들다. 과부하 상황이 발생할수록 Fail Rate가 올라갈 확률이 높아지는데, 대학의 수강신청이나 프로야구 포스트 시즌 예매 때의 시스템 상황을 떠올리면 쉽게 이해할 수 있다. Fail Rate는 IT 서비스의 전반적인 안정성과 가용성, 그리고 서비스의 신뢰성을 판단하는 중요한 지표가 된다.

Execution time per data volume은 데이터의 양에 따른 수행 시간을 의미한다. 주로 DBMS의 성능과 관련이 있지만 특히 OLAP 업무의 성능을 판단할 때 중요하게 사용되는 지표이다. 최근에는 대용량 DB를 기반으로 한 IT 서비스가 대세를 이루고 있기 때문에 하루에 쌓이는 DB의 양도 점점 많아진다. 따라서 Execution time per data volume은 특히 더 관심을 가지고 자세하게 살펴보아야 하는 중요한 지표이다. 이 지표는 백업과 파일 시스템의 구성을 효율적으로 하기 위해서 데이터의 양과 접근패턴을 참고하는 경우가 많다.

동시 사용자의 경우에는 시스템의 용량과 관계된 지표로, 해당 IT 서비스 산업의 추세를 판단할 수 있는 좋은 지표이다. 왜냐하면 성능과 관련한 것도 중요한 지표이지만 동시 사용자는 고객 수와 밀접한 관계가 있기 때문이다. 또 시스템이 한 번에 포용해야 하는 사람의 수이기 때문에 시스템에 필요한 최소 세션 수를 판단하고 시스템의 적정 부하량을 예측할 때 참고하는 지표이다.

처리량과 네트워크 사용량은 시스템 전체에 해당 IT 서비스의 요청이 들어왔을 때 시스템이 수행하는 작업의 총량을 뜻한다. 트랜잭션이 똑같이 1이라고 해도 그 비중과 업무의 복잡도에 따라 처리하는 작업이나 데이터의 양이 다르기 때문에 반드시 확인해야 한다. 또한 네트워크 사용량과 처리량은 직접적인 관계에 있으며 보통 여러 시스템이 하나의 네트워크에 연결돼 있는 경우가 많기 때문에, 하나의 IT 서비스로 인해 여러 서비스들에서 장애가 발생되는 것을 방지하기 위해서도 확인해야 하는 지표이다.

지금까지 IT 서비스의 주요 지표들에 대해 살펴봤다. 테스트를 수행하다 보면 정상적인 상황에서는 항상 상관관계들이 존재한다. 이 상황에서 벗어난다는 것은 시스템 어느 한 쪽에서 문제가 있다는 말이 된다. 지금부터 정상적인 상황에서 이들 사이에 존재하는 상관관계를 알아보겠다.

성능 지표들 사이의 상관관계

성능 지표를 측정할 때, 전제가 되는 것이 ‘부하 상황’이다. 다시 말해서 특정 TPS에서의 다른 성능지표 변화를 측정하고 이들의 상관관계를 통해 진단한다.
가장 대표적인 상관관계가 TPS와 응답시간, TPS와 자원사용량이다. 이들의 상관관계는 Little’s Law와 Response Time’s Law 등을 통해 정리할 수 있다. 공식을 정리하면 (그림 1), (그림 2)와 같이 그래프로 TPS와 다른 지표간의 상관관계를 나타낼 수 있다.
이론적으로는 가장 이상적인 경우는 TPS가 높아질수록 시스템의 자원이 많이 사용되면서 그에 따라 일정한 수준의 응답시간을 나타내는 것이다.

성능 테스트의 정의와 종류

과거에는 코딩작업의 일부로, 프로그램이 정확하게 기능을 수행하는 지 파악하는 과정으로 테스트가 수행됐다면, 현재에는 구현된 시스템과 고객의 요구사항이 일치하는 지를 파악하는 의미로 수행된다. 더불어 IT 서비스를 제공하는 기업들은 소프트웨어 및 시스템 테스트를 통해 그들이 제공하는 서비스의 품질을 측정하고 개량해, 양질의 IT 서비스를 유지하려 한다.

성능 테스트는 위에서 설명한 테스트 활동의 한 종류로 ‘IT 서비스의 목적과 성격에 따라 성능 목표를 설정하고 다양한 방법으로 측정해 목표 성능을 확보하는 과정’이다. 마치 성능 테스트는 작가가 하나의 글을 쓴 뒤 독자들에게 보이기 전 퇴고하는 것과 같다. 따라서 성능 테스트는 최종적으로 고객에게 완료 보고의 역할을 하는 인수 테스트 직전까지 진행되기 때문에 전체적인 IT 서비스를 꼼꼼하게 진행해야 한다.

테스트 과정은 IT 서비스의 품질을 확보하는 과정이면서 동시에 서비스 운영 시 발생할 수 있는 장애 상황을 야기 시킬 수 있는 여러 결함을 사전에 파악해 제거하거나 조치할 수 있는 방안을 준비할 수 있게 하는 중요한 과정이다.
성능테스트는 다양한 기준으로 구분할 수 있지만, 단계에 따라서 단위성능 테스트, 통합성능 테스트, 임계성능 테스트, 인프라 테스트 등으로 구분할 수 있다.

이 구분은 일반적인 테스트 단계와 동일하다.

각 테스트 별 의미를 살펴보면, 성능 테스트에서 단위라고 하는 것은 사전에 테스트 관계자들이 동의한 업무를 의미한다.

통합 성능 테스트는 단위 업무들의 비중과 중요도, 부하모델 등을 계산해 실 환경과 유사하게 부하를 발생시키는 테스트이다.
임계 테스트의 경우에는 가용성이나 안정성 등에 대한 검증 작업을 수행할 수 있으며, 인프라 테스트는 부하 상황에서 장애와 같은 특수 상황을 임의로 발생시켜 시스템의 이상 유무를 검증하고, 이에 대한 적절한 조치를 어떻게 취해야 하는지를 확인하는 테스트이다. (표 3)에서 각 단계별 테스트 특징을 정리했다.

단계별 성능 테스트 특징

	1. 단위 성능 테스트  - 개별 단위 : 애플리케이션의 목표 성능 만족 여부 측정  - 일반적으로 애플리케이션 튜닝과 동시에 진행됨  - 통합 테스트 수행 시 발생할 수 있는 업무별 병목사항 사전 제거  - 단위 업무의 업무 부하 측정  - 통합 성능 테스트 수행환경 점검
	2. 통합 성능 테스트  - 서비스 사용 패턴에 따른 부하 상황에서의 목표 성능 만족 여부 측정  - 시스템 용량의 업무 부하 대비 적정 여부 확인  - 시스템 아키텍처 별 성능 검증 및 튜닝 포인트 분석
	3. 임계 성능 테스트  - 서비스 사용자나 업무량의 증가 추이 분석 결과와 연계해 시스템 증설 계획수립  - 시스템의 자원 사용량 증가에 따른 가용성 및 안정성의 보장 여부 검증  - 시스템의 자원의 증설 우선순위 결정(CPU, 메모리, 네트워크, 스토리지, DB 등)  - 시스템의 티어의 증설 우선순위 결정(서버, 미들웨어, DB, 스토리지, 네트워크 등)
	4. 인프라 테스트  - 예상 장애상황에서의 처리 과정 검증  - 필요에 따라 특정 설정 시 나타나는 현상에 대한 검증  - 가용성 검증