부하 및 성능 테스트

idkwhattodo·2023년 11월 29일

기타

목록 보기

13/13

시스템이 정상적으로 사용 가능한 정도
정상적인 사용시간(Uptime) / 전체시간(Uptime + Downtime)으로 계산되며, 가용성의 핵심은 Uptime의 비율을 늘려 단일 장애점(Single Point of Failure)을 없애는 것
즉, 고가용성이란 전체시간 중 정상적인 사용시간이 높은 것을 의미

시간당 처리량을 의미하는 용어
- RPS(Request Per Second) : 1초에 처리하는 HTTP 요청 수
- TPS(Transaction per Second) : 1초당 처리할 수 있는 트랜잭션의 갯수
시간당 처리량과는 다른 개념으로 네트워크로 전송되는 데이터 전송 속도를 의미하는 경우도 있으니 참고

처리 시간을 의미하는 용어
사용자가 보는 처리 시간
- 사용자가 요청을 보내고 응답을 받을 때까지의 시간
- 시스템이 보는 처리 시간 + 네트워크를 통한 데이터 왕복 시간 + 브라우저가 데이터를 받고 화면에 표시하기 까지의 시간
시스템이 보는 처리 시간
- 웹 시스템이 요청을 받고 응답을 줄 때까지의 시간

Response Time : 응답 시간
- 응답을 받기까지의 시간
Network Bandwidth : 대역폭
- 네트워크 특정 시간 내에 전송될 수 있는 데이터의 최대 용량으로, 네트워크에서 잠재적으로 동시에 전송될 수 있는 데이터의 최대치
- 즉, 실질적인 성능을 나타내는 지표가 아님

시스템 처리 능력을 계산해 가용성을 높이는 것!
즉, 부하 및 성능 테스트는 부하 시 성능을 파악하고, 원하는 성능이 나오지 않으면 확장성을 파악하여 조치하는 것
- Throughput, Latency가 부하 및 성능 테스트의 성공 지표

테스트 대상 시스템은 부하가 집중되고 있는 상태
- 부하 테스트란, 대상 시스템에 부하를 준 상태에서 실행하는 테스트
- 만일, 여러 하위 시스템으로 구성된 테스트일 때, 각각의 하위 시스템에 개별적으로 부하를 주고 조사해야 정확함
- 부하 테스트 중 특정 하드웨어 리소스가 과부하 상태가 되는 것은 나쁜 것이 아니라 좋은 부하 테스트가 진행 중임을 의미
병목 지점을 확인한 상태
- 시스템에 많은 요청을 보낸 부하 테스트인 경우, 일반적으로 시스템 어느 한 부분이 과부하되어 이 부분이 전체의 Throughput을 결정하게 됨
- 부하 테스트 실행중에는 항상 병목 구간이 어디인지를 의식해야하며, 병목 구간을 찾기 쉽게 테스트를 준비하면 보다 효율적으로 테스트할 수 있음

부하 테스트 도구
- 시스템에 부하를 주는 도구
- 많은 HTTP 요청으로 인해 시스템에 부하를 줌
- JMeter, LoadRunner 등이 있음
모니터링 도구
- 시스템 리소스(CPU, 메모리, 스토리지 등) 사용률을 감시하고, 가시화해주는 도구
프로파일링 도구
- 미들웨어나 어플리케이션(Spring, MySQL 등) 내부 동작을 분석하고 가시화해주는 도구

부하 테스트 도구에서 보이는 Latency != 부하 테스트 대상 시스템의 Latency
- 부하 테스트 도구에서 보이는 Latency = 네트워크로 전송되는 동안 발생하는 Latency나 SSL 디코드에 대한 Latency가 포함된 값
- 부하 테스트 대상 시스템이 빨리 응답해도 이 값이 반영되었는지 알 수 없으며, 각 시스템의 실제 Latency는 서버 로그를 보거나 로드 밸런서에서 보인 Latency를 확인해야함
부하 테스트 도구의 클라이언트 동시 기동 수 != 시스템에서 처리되는 동시 처리 수
- 부하 테스트 도구에서 생성된 요청 대부분은 네트워크나 서버에 있으며, 실제 부하를 줘야 하는 대상 시스템에서 처리 중인 요청은 전체 요청 중 일부분임
- 특히, 네트워크 Latency가 클 때는 부하 테스트 도구에서 설정한 클라이언트의 동시 가동 수와 비교하여, 실제 시스템에서 처리 중인 요청 비율은 낮음
부하 테스트 도구의 클라이언트는 앞의 요청이 완료되지 않으면 다음 요청을 생성하지 않음
- 서버나 네트워크 어딘가에서 일부 요청에 대한 응답을 처리하지 못하게 되면 전체 Throughpu에 많은 영향을 주지만, 이 현상은 부하 테스트 특유의 현상으로, 실제 사용자가 접속했을 때의 현상과는 다름

부하 테스트
- 적절한 부하를 발생시켜서 통계적으로써 의미있는 수치를 측정하는 것
- 장시간의 서비스 진행 여부 확인 (신뢰성, reliability)
- 실체 처리능력을 가늠하는 성능테스트(Performance)
- "부하"라는 단어는 포괄적인 의미로, 부하의 모든 의미를 내포하는 것으로 이해하는 것이 좋음
스트레스 테스트
- CPU, RAM, DISK의 환경이 갖추어지지 않은 어플리케이션에 비정상적으로 높은 부하를 발생시켜 한계점을 테스트해보는 것
- 이러한 부하를 발생시키면 VM서비스의 다운, 데이터의 소실 등의 시스템레벨의 오작동을 유발 시키는 것이 가능함
- 이러한 결점과 결함점을 찾는 것을 목표로 스트레스 테스트가 진행됨
- 스트레스 테스트는 시스템 레벨에서의 결함을 예상하는 수준으로 결과물을 파악하는 것이 중요하며, 실접속자가 발생시키는 부하량과는 매우 다른 케이스를 가질 수도 있다는 점을 유의해야 함

병목 구간(Throughput이 가장 낮은 구간)을 찾아 개선하면 최대 Throughput을 올릴 수 있음
병목을 개선하더라도, 다른 쪽에서 병목을 발견한다면? => 병목은 이동한다라고 판단이 가능
병목 구간이라고 생각해서 그 구간을 개선했는데 Throughput에 영향을 주지 않았다면? => 병목 확인이 잘못되었으므로 다른 구간을 확인 => 해당 과정들을 반복해서 Throughput을 개선해 나가는 것이 중요

'긴 처리 시간이 필요한 처리'에서는 순차적으로 개선 사항이 없는지 확인해 나가는 방법을 사용하는 것이 좋음
각 처리 시간이 적정한 범위 내에 있다면 더 이상 개선하는 것은 어려움
비효율 적인 알고리즘, 필요없는 I/O, 데이터베이스 사용 시 인덱스 부족 현상을 확인해야함
처리 시간의 경우, 애플리케이션 내부라면 프로파일러라는 도구를 사용하면 비교적 쉽게 파악이 가능함
Throughput 개선과 달리 일부 구간의 Latency 개선은 전체 Latency 개선과 연결됨 => 병목 구간에 관계없이 가장 시간이 오래 걸린 구간을 개선하는 것이 전체 Latency를 크게 개선하는 방법

참고