당신의 서버, 부하 검증으로 안정적인 서비스를 보장하라
서버 부하 테스트 (Performance Test)
서버 부하 테스트 (Performance Test)
서버 부하 테스트 개요
서버 부하 테스트는 임계값이 한계에 도달할 때까지 시스템 부하를 지속적으로 증가시켜 특정 부하상황에서 서버가 어떻게 동작하는지 확인하기 위한 비기능 테스트로 서버 부하 상황에서도 안정적으로 서비스가 이루어질 수 있도록 보장하는 활동입니다.
서버 부하 테스트로 측정된 지표들을 바탕으로 얼마나 큰 규모의 인프라를 운영해야 할 것인지 예측할 수 있고 사용자에게 최고의 경험을 제공할 수 있는 초석이 됩니다.
서버 부하 테스트는 QA 혼자만 진행할 수 있는 테스트가 아닙니다. 서버 개발자, 인프라 개발자와 협동이 필요한 테스트로 사전에 각 담당자의 역할과 지원 범위, 테스트 커버리지/임계값 설정 등 테스트에 필요한 정보와 준비사항들에대한 논의가 진행되어야합니다.
하지만 서버 부하 테스트는 QA조직에서 참여 또는 요청하지 않아도 서버개발자에 의해 개발단계에서 반드시 테스트 되는 항목에 해당됩니다. 그렇다면 왜 굳이 QA 조직에서도 테스트에 참여해야 하는 걸까요?
□ 개발자 시점 서버부하테스트
서버 개발자들은 서버 자체 부하 상태를 측정합니다.
- 서버가 버틸 수 있는 수준의 임계값 산정
- 테스트 시나리오 구상
* 부하 상황에서 시스템 동작을 예측하여, 어느 부분에 어떻게 부하를 줄것인지 결정
* 부하가 발생했을때 요청을 얼마나 잘 처리하는지 & 병목되는 지점은 어디인지 확인
- 부하 모니터링 지표 관측 및 기록 / 결과 분석 ⇒ 서버단 개선 포인트 도출
서버 수, 서버 스펙 결정 (scale up/out)
□ QA 시점 서버부하테스트
서버 부하 상황에서 사용자 관점에서 경험할 수 있는 상황을 체크하여 개선 포인트를 도출하고 권고사항을 전달하는데 목적이 있습니다.
부하 상태에서 실제 클라이언트를 사용해봄으로서 안정적인 서비스가 제공되는지 확인
부하로 인한 이슈 발생시 이슈 대응이 필요한 지점에 대한 개선포인트를 도출하고 권고사항을 전달
유사 서비스 테스트 결과 및 개선 사례 / 기존 서버 개선 이력 / 좋은 성능 지표 등 QA 검증 데이터로 가이드 제공
시스템 관점에서만 부하 테스트를 진행 및 개선사항을 도출하지 않고 확장된 시각으로 실제 유저가 경험할 수 있는 클라이언트 이슈와 서비스 영향도도 함께 고려되어야 합니다. 안정적인 시스템 관리와 운영 관리 모두를 만족하기 위해 서로 다른 시각에서 개발과 QA가 참여하는 서버 부하 테스트가 필요한 이유입니다.
QA는 개발 완료단계에서 테스트를 수행하는 역할이 아닙니다.
파이프라인을 통해 이슈가 유입되는 경로를 차단하는 역할도 해야합니다. 이런 관점에서 서비스 품질에 영향을 줄 수 있는 모든 시스템의 품질을 관리하고 검증할 수있는 방법을 모색하고 안정적인 서비스가 가능 할 수 있도록 지원해야합니다.
[1] 서버 부하 테스트 진행 시기
개발/QA환경이 아닌 라이브에 실제 사용할 서버에서 테스트를 진행합니다.
실시간 트래픽 과부하 발생이 예상되는 새로운 서비스 오픈을 앞두고 있을때.
기존 서비스에서 병목될 가능성이 있는 변경사항이 있을 경우.
[2] 서버 부하 테스트 종류
(1) 단위 테스트
테스트 항목
서버 단일 구성 기준. 테스트 대상이 되는 각 단위 기능의 최대임계 TPS 측정
목적
- 단위 기능 별 최대 성능 도출
- 구간별 병목구간 도출
- 목표성능 만족여부 검증 및 임계치 확인
(2) Spike 테스트
테스트 항목
시스템 최대 성능 측정
실제 유저 패턴과 유사한 테스트 시나리오를 재현하여 성능 검증
목적
- 시스템 최대 용량 산정
- 사용자 과접속이 순간적으로 발생하는 상황을 재현하여 서버 안정성 검증
(3) 서버 확장성 테스트
테스트 항목
전체 서버구성을 기준으로 목표성능 만족여부 및 확장성 여부 측정, 비즈니스 로직 및 기능 별 가중치를 적용한 통합 시나리오로 진행
목적
시스템 구성 중 병렬로 구성하여 확장 예정인 구간에 대하여 확장 가능성 여부와 확장이 보장되는지 여부를 판단
(4) Long-run 테스트
테스트 항목
목표동접의 부하 수준(약 80~100%) 으로 24시간 이상 안정적인 서비스 제공 가능 여부 검증
목적
- 시스템이 오랜 시간 동안 서비스운영을 유지했을 때 서비스 안정성 파악
- 서버다운, 메모리누수, 규칙적인 CPU 사용률 점검
(5) 사용자 테스트
테스트 항목
시스템이 목표수준의 부하를 처리하는 상태에서 실제 클라이언트 빌드를 통하여 서버에 접속하여 주요 기능을 테스트
목적
- 목표수준의 부하 상태에서 실제 클라이언트를 사용했을때 안정적인 서비스가 제공되는지 확인
- 부하가 없는 상태에서의 기능 QA 결과와 동일 수준을 만족하는지 여부 검증
[3] 서버 부하 테스트 Process
(1) 준비 단계
테스트 대상 및 시나리오 선정
테스트 Tool 선정 : Jmeter, Pinpoint, Locust, LoadRunner, nGrinder 등
(2) 테스트 설계 & 구현 단계
테스트 시나리오 설계
- 검증이 필요한 기능, 주요 콘텐츠 등 테스트 대상 선정
- 성능 테스트 요구사항 반영
테스트 스크립트 개발구현
테스트 일정 계획
부하 테스트 환경 구축
- 리얼 환경과 동일한 시스템의 물리적 환경(테스트환경) 또는 실 운영장비를 대상으로 테스트 환경 준비
- 성능 테스트를 위해 필요한 시스템 준비 (로드 에이전트(VM), 컨트롤러, 리소스 모니터링 시스템 등)
네트워크 요구사항
- 기존 테스트 / 리얼 환경과 분리된 독립된 네트워크로 구성
- 부하 발생 및 모니터링 시스템들은 테스트 타깃 시스템들과 동일 네트워크에 존재
(3) 통합테스트 단계
서버 부하 테스트 진행
개선점 도출 및 목표 성능 확인
서버 모니터링과 성능 지표에 대한 내용 분석 공유 (특정 부하에서 응답성/안정성, 부하에따른 시스템 동작 처리, 개선점)
[4] 서버 부하 테스트 품질 기준
동시 접속자 수 : 서버구성, 사업목표, 마케팅 플랜에 따라 상이
트랜잭션 응답시간 : 1초 미만
시간당 처리량(TPS) : 서버 구성에 따라 상이(높을수록 좋음)
리소스 사용량(CPU, Memory사용량) : 80% 미만
요청 건수 대비 오류 발생 건수 (실패율) : 1% 미만
네트워크 Latency 사용량 : 500ms 미만(최고 1000ms 미만)
RPS : 30~200 미만
Run Time : 40초 이하
[5] 부하 모니터링 지표 분석 예시
좋은 서버 성능 지표
1) 목표 최대 동시 접속자 내 안정적인 서비스 제공
2) TPS가 높아질수록 시스템의 자원을 많이 사용하는 것으로 목표 시간 내 일정한 수준의 응답시간을 나타내는 지표가 좋은 지표이다.
< 좋은지표
[나쁜지표(아래)] 실 테스트시 많이 보게될 지표.
TPS가 급격히 증가하다 임계점(시스템 임계수준)에 다다르면 증가폭이 줄어들거나 임계수준에서 유지되고 응답 시간은 천천히 증가 또는 일정 시간 유지하다가 임계점에서 급격히 증가하는 지표를 나타낸다. 임계수준 이상의 부하 발생시 서버 성능이 떨어지거나 요청 응답 시간이 느려지거나 서버가 다운되는 등 현상이 발생될 수 있다.
3) 장시간 목표동접 부하유입시 시스템의 메모리 누수없이 일정 수준을 유지하는 지표가 좋은 지표이다.
[나쁜지표(오른쪽)] 메모리누수가 지속적으로 발생되는 것이 확인된다.
다 쓴 객체에 대한 참조를 해제하지 않으면 계속 메모리가 할당 되는 메모리 누수 현상이 발생 된다
