부하 테스트 도구

:아마존 웹 서비스 부하테스트 입문

 

부하 테스트란?

• 부하 테스트 서버: 부하 테스트 도구를 가동한 서버
• 부하 테스트: 부하 테스트 도구를 사용하여 웹 애플리케이션에 HTTP(S) 요청을 발생시키는 것

 

부하 테스트에서 사용하는 도구

• 부하 테스트 도구: 시스템에 부하를 줌
• 모니터링 도구: 시스템 리소스 사용률을 가시화해줌
• 프로파일링 도구: 미들웨어나 애플리케이션 내부 동작을 분석하고 가시화해줌

 

부하 테스트 도구에 필요한 조건

1. 요청을 정확하게 시뮬레이션해야 함
2. 부하 정도(클라이언트 동시 접속자 수, 요청 간격, 최대 Throughput 등)를 조정 가능해야 함
3. 대상 시스템에 충분한 부하를 발생시켜야 함
4. 부하 테스트 도구/설치/장소 및 가동 장소를 선택할 수 있어야 함

 

실제 부하 테스트 주의사항

• 부하 테스트 도구에서 보이는 Latency는 부하 테스트 대상 시스템의 Latency와는 다름
• 부하 테스트 도구의 클라이언트 동시 기동 수와 시스템에서 처리되는 동시 처리 수는 다름
• 부하 테스트 도구의 클라이언트는 앞의 요청이 완료되지 않으면 다음 요청을 생성하지 않음

 

부하 테스트 도구상의 부하와 실제 운영환경의 차이

• 요청을 생성하는 서버 대수, 네트워크의 차이
  • 부하 테스트 환경: 서버에 모든 처리 부하가 집중 → 처리 시간이 소요되어 시스템 응답이 늦는 것처럼 보임
  • 서비스 환경: 요청 사용자에 처리 부하 분산 → 처리 시간이 많이 소요되지 않아 시스템 응답이 빨라 보임
• 요청을 보내는 서버와 엔드포인트의 차이
  • 부하 테스트 환경: 엔드포인트명으로 DNS Lookup 했을 때 DNS가 여러 엔드포인트 중 하나만 응답하고 서버는 그 엔드포인트를 캐시함
  • 서비스 환경: 엔드포인트명으로 DNS Lookup 했을 때 DNS가 하나의 엔드포인트에서만 응답을 받지만 여러 사용자들은 서로 다른 엔드포인트에서 응답 받음
• 동시 요청 수의 차이
  • 부하 테스트 환경: 먼저 보내진 요청 결과가 서버에 돌아올 때까지 기다리고 다음 요청을 보냄 → 시스템의 응답이 아무리 늦어도 지정한 클라이언트 수의 요청밖에 동시에 발생하지 않음
  • 서비스 환경: 응답 처리 중에도 다른 사용자로부터 계속 요청이 들어옴 → 처리해야 할 동시 요청 수 증가
• 일부 느린 처리가 전체 Throughput에 미치는 영향의 차이
  • 부하 테스트 환경: 일부 응답에 시간이 걸리게 되면 테스트 시나리오 전체가 대기하여 부하 상태가 변함
  • 서비스 환경: 일부 응답에 시간이 걸린다 해도 해당 사용자가 아니라면 영향받지 않음

 

부하 테스트 도구

• Apache Bench
  • 단일 URL 부하 테스트는 간단히 가능 → 리다이렉트 헤더 응답이 온 경우 해당 URL에 다시 접속X
  • POST/PUT 부하 테스트 가능 (DELETE 불가능)
  • 요청별로 파라미터 변경 불가
  • 시나리오 테스트 불가
  • 부하 테스트 서버의 CPU 코어 1개만 사용
• Apache JMeter
  • DELETE 테스트 가능
  • 요청 별로 동적 파라미터 변경 가능
  • 복수의 URL에 시나리오 기반의 복잡한 & 고부하 부하 테스트 가능
  • 부하 테스트 결과 출력 기능이 다양
• Locust
  • 시나리오를 파이썬 스크립트로 작성할 수 있어 유연한 시나리오 만들기 가능
  • 필요한 서버 리소스가 작으므로 작은 크기의 부하 테스트 서버로 테스트 가능
  • 테스트 결과 리포트가 간단
• Tsung
  • GUI로 시나리오를 작성하거나 볼 수 없어 복잡한 시나리오에는 맞지 않음
  • 적은 부하 테스트 서버 → 고부하 테스트에 적합함

 

하위 시스템의 상세 모니터링과 시스템 프로파일링을 하기 위한 도구

• top: 서버 실시간 모니터링 명령어
• netstat: TCP 등 네트워크 통신 상태 볼 수 있는 명령어
• AWS 관리 콘솔 → CloudWatch 활용
• Xhprof: PHP 애플리케이션 전용 프로파일링 도구
• New Relic: 다양한 언어와 웹 프레임워크를 지원하는 프로파일링/모니터링 도구

 

WATCH 해야 하는 항목

하위 시스템	WATCH 해야 하거나 방법을 알아야 하는 항목
네트워크	전송량
하드웨어 및 OS	CPU, 메모리, 프로세스 수, SWAP, Load Average
TCP	외부 커넥션 상태(ESTABLISH나 FIN WAIT 등)
디스크	IOPS, R/W 전송 데이터 양
미들웨어	커넥션 수(↔MaxConnection)
애플리케이션	프로파일러로 모니터링
MySQL	Slow Query, Process List

• 사용자 프로세스 CPU 사용률: 적당히 높을수록 좋음
• 시스템 프로세스 CPU 사용률: 낮을수록 좋음
• 사용 중인 메모리 양이 서버 전체 메모리 양을 넘게 되면 성능이 현저하게 떨어짐
• netstat → State가 TIME_WAIT된 접속 수 확인
• CloudWatch의 수평 구간 확인 → 3분 이상 부하 줘야 함
• CloudWatch에서 확인할 수 있는 CPU 사용량 값 100% → 가상화 환경에서 발생하는 오차
• CloudWatch에서 ELB를 모니터링하면 평균 Latency는 확인할 수 있지만 개별 API의 Latency와 느린 처리량 등은 확인X → 로그 확인