01. 성능이란 #
시스템 성능은 ‘시간당 처리량’이며, 영향을 미치는 요소는 ‘응답시간’, ‘동시에 처리할 수 있는 프로세스 수’이다.
응답시간은 사용자의 특성, 환경에 따라 요구하는 수준이 다르다. 동일한 응답시간에 대해 고객마다 만족도도 다르다.
이는 모든 시스템과 사용자에게 일률적으로 적용할 수 있는 응답시간의 기준은 없다는 것을 의미한다.
1.1 동시 사용자 #
성능 분석이나 테스트 시 공식적으로 적용되는 동시 사용자라는 의미는 대상 서버에 접속하고 있는 사용자로 정의한다.
동시 사용자는 다음과 같이 두 유형의 합으로 표현할 수 있다.
동시 사용자 수 = 요청 사용자 수 + 비요청 사용자 수
1.2 처리량 (throughput) #
‘처리량’은 서버가 일정 시간 내에 처리한 트랜잭션의 양이다.
단, 이때 서버 입장에서 바라보는 트랜잭션과 클라이언트 입장에서 바라보는 트랜잭션은 다르다.
고객이 A 화면을 조회했을 때 서버에서 n개의 쿼리, m개의 자원(css, 이미지, html) 등이 처리/응답됐다고 가정하자.
이때 고객(클라이언트)입장에서는 1개의 트랜잭션이 처리된 것이고, 서버 입장에서는 n+m개의 트랜잭션이 처리된 것이다.
성능에서 중요한 것은 서버 입장에서의 트랜잭션이 아니고 클라이언트 입장에서의 트랜잭션이다.
따라서, 처리량의 평가 단위로서 사용되는 TPS(Transaction Per Second)의 “T"는 고객의 업무 처리 건수가 되어야 하겠다.
시스템을 설계하고 분석하는 엔지니어 입장에서는 서버 측의 트랜잭션도 중요할 수 있다. 이때 TPS 이외의 처리량 평가 단위로 PPS, HPS 등이 있다.
PPS (Page Per Second)
웹 성능을 분석할 때 화면 단위(Page)를 트랜잭션 평가 단위로 사용하기도 한다. “사용자 등록 화면 -> 사용자 입력 확인 화면 -> 주소 검색 초기 화면 -> 주소 검색 결과 화면 -> 사용자 등록 성공 화면” 의 단계로 사용자 등록 흐름이 구성돼 있다면 PPS 관점에서의 처리량은 화면 기준으로 5가 된다.
단, 사용자 입장의 TPS 관점에서는 1이 되겠다.
HTS(Hit Per Second)
웹 서버에서 이미지, 스크립트 파일, css 등은 별개 요청으로 응답되는데, 각각이 1개의 Hit 가 된다.
HTP 를 측정 단위로 삼는다면 TPS, PPS 에 비해 세분화된 것으로 볼 수 있다.
1.3 응답시간 (latency) #
응답시간은 요청한 후부터 응답을 받을 때까지 소요된 시간이다. 측정하는 위치에 따라 여러 유형으로 나뉜다.
p8 ~ p12 참고
1.4 자원 (resource) #
자원은 포괄적인 용어다.
서버의 HW(CPU, 메모리, 디스크), 네트워크 자원, WAS 자원(스레드 풀, 힙 메모리, DB 커넥션 풀), DB 자원(최대 프로세스 수, 오픈 가능한 커서 수, 공유 캐시 메모리 크기) 등 물리적인 자원부터 소프트웨어 자원까지 다양하다.
성능 측면에서 자원은 애플리케이션이 동작할 때 사용하며, 부족한 경우나 사용량 변화에 따라 성능에 영향을 미치는 요소를 의미한다.
자원은 목표 성능을 달성할 수 있게 해주는 중요 기반요소로서, 성능 평가나 분석 시 자원 사용량도 모니터링해서 다양한 관점(적정성, 효율성, 안정성, 가용성, 확장성)에서 평가해야 한다.
1.4.1 적정성 (Suitability) #
(각각의)자원 사용량이 적절한지 확인한다.
예를 들어, WAS 스레드 풀의 모든 스레드가 작업 중이라서 새로운 요청이 큐잉되고 있다고 하자.
이때 단순히 스레드 풀의 자원을 늘리는 것은 좋은 해결 방법이 아니다. CPU, 메모리와 같은 인프라 자원 상태나 병목 여부 확인(애플리케이션 내 로직, DB 쿼리 등) 등 종합적으로 상태를 판단한 후 스레드 풀 자원을 늘릴지, 다른 방안을 모색할지 결정해야 한다.
이미 CPU 사용량이 90% 이상이라면, 스레드 풀을 늘려봤자 소용이 없을 것이다. 오히려 스레드 풀을 줄여서 CPU가 70% 내외의 안정적인 범위에 있게 함으로써 성능을 개선할 수도 있다.
또, 처리 시간이 긴 로직으로 인해 스레드 풀이 소진됐다면 이 부분을 개선하는 것이 먼저일 것이다.
각 자원의 부족 여부를 판단할 때는 다른 자원과의 상관관계와 인과관계를 잘 파악해서 평가해야 한다.
1.4.2 효율성 #
동일한 성능(TPS, 응답시간 등)을 수행하는 두 아키텍쳐가 있다고 가정하자.
이때는 적은 자원(= 적은 비용)을 사용하는 아키텍쳐가 효율적인 것이다.
성능 개선이라는 행위 자체가 시스템의 효율성을 높이려는 활동이다.
효율성은 직접적인 비용에 영향을 미치는 요소로 BMT(Benchmark Test) 같은 성능 비교 평가에서 중요 평가지표가 된다.
1.4.3 안정성 #
시스템 운영시간이 지남에 따라 성능이 저하되거나 장애가 발생하는 등의 문제가 발생하지 않아야 한다.
메모리에 누수가 있다면 메모리가 부족해 장애가 발생할 것이다.
처리하는 데이터가 꾸준히 증가한다면 언젠가 성능 저하로 사용에 불편을 느낄 것이다.
이처럼 시간이 지나더라도 응답시간이나 자원 사용량이 일정하게 유지되는지 확인하는 것이 안정성 평가다.
1.4.4 가용성 #
일정 기간(년, 월 등) 동안 시스템이 정상적으로 서비스된 시간 비율을 의미한다.
이중화 구성, DR 구축 등의 키워드가 있을 것이다.
이중화가 되어 있다고 가용성이 향상되는 것은 아니다. 일부 장비가 실제로 장애로 다운됐을 때, 정상적인 서비스가 이뤄지는 것이 중요하다.
즉, 서비스 중 일부에 장애가 발생하더라도 사용자가 큰 불편 없이 서비스를 사용할 수 있는 수준이 돼야 한다.
가용성 테스트를 할 때 서비스 중단시간과 서비스 안정성, 응답시간, TPS, 자원 사용량 변화와 같은 성능 지표도 함께 측정해서 평가한다.
1.4.5 확장성 #
시스템 사용량 증가에 따라 시스템 증설이 필요할 때 각 자원이 얼마나 용이하게 증설될 수 있는지 평가하는 것이다.
확장성은 크게 수직 확장(스케일-업), 수평 확장(스케일-아웃)으로 나눠 평가할 수 있다.
보통 수직 확장은 수평 확장에 비해 확장성이 떨어지는 것으로 평가한다.