1부 - 성능 기초

1. 성능이란?

• 고객의 특정 업무를 대상으로 운영환경하에서 고객이 수긍할 수 있는 응답시간 내에 처리할 수 있는 거래량이라고 정의할 수 있다.

1.1 동시 사용자

• 성능 테스트나 운영 시 시스템에 발생하는 부하의 의미로 많이 사용되는 용어가 바로 동시 사용자다.

• 동시 사용자에 대한 정의는 개발자와 업무담당자간에 다르게 해석할 수 있다.

  • 동시에 시스템에 트랜잭션을 유발시키는 사용자
  • 시스템과 접속을 유지하고 있는 사용자 수
• 동시 사용자 수 = 요청 사용자 수 + 비요청 사용자 수

1.2 처리량

• 처리량은 서버가 일정 시간 내에 처리한 트랜잭션의 양이다.

• 서버가 인식하는 트랜잭션 양과 사용자가 인식하는 트랜젹션 양은 다르다.

  • 고객 입장에서는 화면 조회라는 1개의 트랜잭션을 보낸다.
  • 서버 입장에서는 API, DB, 웹 등 여러 쿼리 호출이 발생한다.
• 성능에서 중요한건 고객의 업무를 얼마나 빨리 처리할 수 있는가다.
• 따라서 처리량의 평가 단위로서 TPS(Transaction Per Second)의 T는 고객의 업무 처리 건수가 되는 것이 의사소통이나 평가 하는데 적합하다.

1.3 응답시간

• 응답시간은 요청한 후부터 응답을 받을 때까지 소요된 시간으로 츠겆ㅇ하는 위치에 따라 여러 유형으로 나뉜다.

  • 클라이언트 응답 시간
  • 사용자가 요청한 후 부터 화면에 응답이 나타날 때까지 경과된 시간, 클라이언트 내부 처리시간도 포함된다.
  • 네트워크 응답 시간
  • 클라이언트에서 요청이 네트워크로 전송된 후부터 응답이 클라이언트 네트워크에 도착하는 데까지 경과되는 시간을 으미한다.
  • 서버 응답 시간
  • 서버가 사용자 요청을 받은 후 부터 처리 결과를 내보는는 데까지 경과된 응답시간이다. APM 기반으로 측정하는 경우가 여기에 해당된다.
  • 연계 응답 시간
  • 서버 처리 중 외부 시스템과 연계해서 처리할 경우 연계 서버에 요청을 보내 응답을 받기까지 경과된 시간이다.

• 응답시간을 산술 평균으로 계산한다면 정확한 분석이 어려워 보통 백분율 응답시간을 사용한다.

  • 측정시간 동안 200개의 트랜잭션이 발생했고, 가장 응답시간이 빠른 것부터 줄세워 180등을 기록한 트랜잭션의 응답시간이 3.5였다면, 해당 업무의 90% 응답시간은 3.5초가 된다. p90

1.4 자원

• 서버의 CPU, 메모리, 디스크, 네트워크, WAS의 스레드 풀, DB연결 풀, 힙 메모리, 프로세스 수, 오픈 가능한 커서 수, 공유 캐시 메모리 등 물리적인 자원부터 소프트웨어 설정값까지 다양한 자원이 있다.
• 성능 측면에서 자원은 한정된 값을 가진 시스템 구성 요소 중 애플리케이션이 동작할 때 사용하며, 부족한 경우 나 사용량 변화에 따라 성능에 영향을 미치는 요소를 의미한다.

1.4.1 적정성

• 자원 사용량에 대한 목표 달성과 부족 여부를 확인하는 것이다.
• 자원이 부족한 경우 경함과 대기가 발생해 성능이 저하되므로 늘려줘야 하지만 다른 자원에 악영향을 주어 개선 효과를 보지 못할 수도 있다.

1.4.2 효율성

• 동일한 TPS를 기준으로 할 때 CPU나 메모리를 적게 사용하는 시스템이 효율적으로 작업을 수행한 것 이다.
• DB 사용량을 줄이고 애플리케이션 코드의 수행시간을 줄여 시스템 자원을 더 적게 사용하도록 개선함으로써 효율성을 높인다.

1.4.3 안정성

• 시스템 운영시간이 지남에 따라 성능이 저하되거나 장애가 발생하는 등의 문제가 발생하지 않아야 한다.

1.4.4 가용성

• 일정 기간 동안 시스템이 정상적으로 서비스된 시간 비율을 의미한다.
• 카드 승인 시스템 같은 시스템은 장애는 사업 기회의 손실로 이어지므로 100%에 가까운 가용성을 유지해야 한다.

1.4.5 확장성

• 확장성은 향후 시스템 사용량 증가에 따라 시스템 증설이 필요할 때 각 자원이 얼마나 용이하게 증설될 수 있는가를 평가하는 것 이다.

2. 성능 특성

2.1 성능 곡선

2.2 성능에 대한 이해

• 성능은 업무와 시스템 특성에 따라 다르게 나타난다.

  • 시스템에 A,B 두 업무가 있다고 가정할 때 각 업무의 비중이 10%,90% 일 때와 90%,10% 일 때 시스템의 최대 성능과 응답시간이 다를 것이다.
  • 따라서 시스템의 성능을 이야기할 때는 업무의 고유한 특성과 시나리오하에서만 논의할 수 있다.

• 모든 시스템에 일괄 적용할 수 있는 응답시간 기준은 없고 100% 만족시킬 수도 없다.

  • 화면 구성이 비슷하더라도 업무의 성격에 따라 처리하는 데이터의 양과 로직의 복잡도가 달라진다.

• 동시 사용자 수가 시스템 성능을 의미하는 것은 아니다.

  • 웹 기반 시스템에서는 동시 사용자(접속자) 수 보다 초당 들어오는 요청의 수, 웹 서버에 물리적으로 맺어진 네트워크 연결 수가 성능에 더 큰 영향을 준다.

• 시스템 성능은 비용과 수익으로 평가할 수도 있다.

  • 시스템 자원 부족으로 서버를 추가 도입하거나 부족한 자원을 증설하기 위해서는 비용이 든다.

3. 성능 이론

3.1 기초 성능 이론

3.2 사용률 이론

3.3 비율 분석

4. 성능 테스트

4.1. 성능 테스트 유형

4.2 성능 테스트 구성 요소

4.3 성능 테스트 시 주의사항

• 성능 테스트는 통상 제약된 환경에서 테스트하므로 실제 운영 시스템 대상으로 테스트를 진행했더라도 운영에 들어가면 예상치 못한 장애가 발생하기도 한다.

4.3.1 테스트 데이터

• 테스트 데이터에 따라 확연히 다른 결과가 나오는 경우도 많기 때문에 성능 테스트 시에는 테스트 데이터에 대해 다음과 같은 사항을 고려해야 한다.

  • 시스템 데이터(데이터 대상 DB)
  • 통상 전체 성능의 70% 이상이 DB에 자우되는데, 테스트 대상이 되는 테이블의 데이터 양이나 패턴이 다르면 쿼리의 실행계획이 달라져 성능이 다르게 나타난다.
  • 데이터가 소량이면 실제 디스크 입출력이 일어나야 하는데 모두 메모리에 로드되어 성능이 빠른 것으로 착각할 수 있다.
  • 원칙적으로 성능 테스트는 실 데이터가 전환된 데이터베이스를 대상으로 수행해야 한다.
  • 스크립트 데이터(입력용 데이터)
  • 소량의 스크립트 데이터를 사용한 경우 테스트 초기 입력 데이터가 DB에 메모리에 캐시됨으로써 성능이 좋게 나올 수 있다.
  • 초기 데이터 제로 테이블
  • 시스템을 오픈할 때 비어있는 테이블은 시간이 지나면서 성능 문제를 일으키는 경우가 많다.
  • 초기 건수가 0이지만 운영하면서 건수가 큰 폭으로 증가하는 테이블은 데이터가 쌓여있을 때의 통계정보로 테이블 통계정보를 변경해 달라고 요청해야 한다.

4.3.2 화면 처리시간

• 대부분의 성능 테스트 도구는 클라이언트 측 네트워크 시간을 기준으로 응답시간을 측정한다.
• 클라이언트마다 PC 환경이 다르고, 테스트 환경에서는 클라이언트에서 수행되는 로직이 동작할 경우 CPU 등 자원부족으로 성능 측정이 부정확하게 되기 때문이다.
• 중요 화면에 대해서는 화면 응답시간을 측정해 성능 기준 만족 여부를 평가하고, 서버 처리시간과 비교 분석해 클라이언트 성능 개선이 필요한지 여부를 판단한다.

4.3.3 네트워크

• 성능 테스트 시 부하 발생기가 연결돼 있는 스위치를 바로 백본 스위치에 연결해 테스트를 수행하는 경우가 많다.
• 이는 내부 네트워크와 서버 중심으로 처리시간을 측정하고, 외부 네트워크는 제외하는 것 이다.
• 서버 문제가 없음에도 네트워크 지연으로 애플리케이션 종료가 지연되어 작업 프로세스나 스레드 풀이 소진되어 큐잉이 발생함으로써 전체 사용자가 성능 저하를 경함할 수 있다.

4.3.4 가상 사용자 특성

• 실사용자라면 응답이 20~30초씩만 늦어져도 기다리지 못하고 다시 반복요청한다.
• 즉 성능 테스트하에서는 특정 가상 사용자 수 이상 큐잉이 발생할 가능성은 낮지만 운영 환경에서는 동일 사용자에 의한 서비스 반복 요청이 이뤄져 대량의 큐잉이 발생할 수 있다.
• 테스트 환경에서만 발생하는 패턴임에도 실제 환경에서도 발생하는 패턴으로 인식해버릴 수도 있다.

4.3.5 업무 시나리오

• 각 테스트 대상 업무에서 부수적인 서비스 호출을 제외하고 중요 서비스 호출만 시나리오에 포함시키면 운영 시 측정한 성능과 테스트 시 측정한 성능이 달라질 수 있다.
• 부하 발생기가 일으키는 서비스 요청 이외에 백엔드에서 수행되는 배치나 후속 작업들을 생략하는 것이다.
• 성능 측정 대상으로서 중요성은 떨어지더라도 정상적인 운영 시 시스템 백엔드에서 일정하게 발생하는 부하가 있다면 성능 테스트 시나리오에 포함해야 한다.

4.3.6 대상 업무와 성능 개선

• 자바 기반 애플리케이션의 경우 한 개의 업무에서 발생한 메모리 누수나 대량 데이터 조회 문제로도 전체 업무에 성능 저하와 장애가 발생할 수 있다.
• 성능 테스트에서 목표를 만족한 것은 시스템 오픈을 위한 최소한의 기준일 뿐, 안정적으로 운영될 것이라고 담보하지는 못한다.