단게별 테스트에서 병목이 부하 테스트 도구에 있다고 해도 그 원인은 다양하고 원인별 대응 방법도 다르다.
여기서는 대표적인 원인과 처리 방법을 소개 한다.
ㅁ 서버와 부하 테스트 도구 설정 준비 부족
이 경우는 다음과 같은 패턴이 있다
ㅇ 파일 디스크립터 부족
파일 디스크립터(DESCRIPTOR)란 프로그램이 접근하는 파일이나 표준 출력에 할당된 식별자를 말한다. 부하가 없을 때는 문제가 되지 않지만, 많은 부하가 연속적으로 발생하게 되면 Linux에서는 부하 테스트 도중에 테스트 도구에서 사용할 수 있는 파일 디스크립터가 부족해 질 수 있다.
파일 디스크립터가 부족하게 되면 파일 오픈이 안되는 에러가 발생하지만, ulimit 명령어를 사용하여 해당 셀(shell)에서 사용 가능한 파일 디스크립터 수를 변경할 수 있다.
Linux에서 파일 디스크립터 수 변경
ulimit -n 65535
ㅇ TCP 포트 부족
파일 디스크립터 부족과 비슷하게 고부하가 연속적으로 발생하게 되면 부하테스트 서버에서는 TCP 관련 커널 파라미터를 변경해야 한다. 인스턴스 타입을 스케일 업 했다고 해도 테스트 중에 리소스 부족 현상이 발생할 수 있기 때문이다. 이 경우 OS 설정을 변경해야 하낟.
ㅇ 부하 테스트 도구 기동 시 옵션 준비 부족
JMeter 등과 같이 Java를 사용하는 도구의 경우 기동 시에 사용 메모리 리소스 양등이 설정되어 있어 기본 설정 상태에서 기동하게 되면 메모리 부족 현상이 발생할 수 있다. JMeter에서는 OutOfMemoryError가 확인된 경우 서버 리소스가 있는 범위에서 HEAP 메모리를 조정하여 기동해야 한다.
JEMETER HEAP 크기 변경 방법
JMeter에서 사용할 HEAP 메모리 크기가 부족한 경우 OutOfMemoryError가 발생한다. 이 때 JMeter 기동 옵션을 변겨하여 HEAP 메모리 크기를 변경한다.
윈도우인 경우 배치 파일 jmeter.bat를 수정한다.
HEAP="-Xms256m -Xmx256m"이를 환경에 맞춰 변경한다.
HEAP="-Xms1024m -Xmx1024m"
ㅇ 부하 테스트 클라이언트 수 조정
부하 테스트 클라이언트 수가 너무 많거나 적어도 시스템에 적절한 부하를 줄 수 없다. 테스트 환경에 맞게 수정해 가면서 테스트를 진행한다.
부하 테스트 클라이언트 수가 너무 적다.
이 경우는 대상 시스템에 충분한 부하를 주지 못하고 다른 부분에서도 병목이 발생하지 않은 상태에서 리소스 여유가 생긴다. 다음과 같은 상황에서는 부하 테스트 클라이언트 수를 추가하는 것을 검토해야 한다.
- 리소스 어느 곳에도 부하가 발생하지 않는다.
- 낮은 Latency의 응답이 있다.
- 시스템 Throughtput이 작다.
적당히 부하 테스트 클라이언트를 추가하면 부하 테스트 대상 시스템 상의 어디에 병목이 발생하는지 알 수 있다.
테스트 클라이언트 수를 조금씩 늘려가면 일정 시간 후에 throughput은 올라가지만, 도중에 대상 시스템 Throughtpu이 더 이상 올라가지 않고 Latency가 급격하게 나빠지게 된다.
부하 테스트 클라이언트 수가 너무 많다.
부하 테스트이기 때문에 가능한 한 많은 클라이언트에서 많은 부하를 발생시켜야 한다고 생각할 수 있지만, 시스템에 대해 테스트 클라이언트 수가 많은 경우 대상 시스템의 Latency가 수초~수십초 이상 급격하게 커지게 된다.(Throughput에는 거의 변화가 없다.) 이 Latency의 대부분은 실제 처리에 들어가기 전의 대기 시간이므로 실제 처리에 소요된 시간을 산정하기 어렵다. 그 결과 API간 응답 속도 차를 확인하기 힘들어진다.
이런 상태가 된 경우에는 Throughput이 많이 감소하지 않는 범위에서 클라이언트수를 적당히 줄여 나간다.
ㅇ 모니터링 대상이 너무 많다.
시나리오 작성 중에는 문제가 없지만, JMeter에서 매트릭을 추가하면 대상 시스템에 부하가 발생하지 않는 상태에서 낮은 Throughput 밖에 보지 못하는 부하 테스트를 할 때가 있다. 많은 부하를 발생시킬 때는 여러 매트릭을 비활성화하고 테스트를 진행해야 한다.
ㅁ 테스트 시나리오 문제
부하 테스트 시나리오 작성이 잘못되어 부하 테스트 대상 서버에 부하가 안 걸리는 경우가 발생한다. 예를 들어 다음과 같은 경우
- 참고, 갱신 대상 리소스가 같은 리소스에 집중되어 있다.
- 시나리오 구조가 너무 복잡하다.
ㅇ 참고, 갱신 대상 리소스가 같은 리소스에 집중되어 있다.
원래 분산된 리소스를 사용하도록 설계된 시스템이지만, 부하 테스트 시나리오를 잘못 작성하여 같은 리소스에 집중하게 되고 원래의 성능을 내지 못하는 상황이 발생한다. 이 상황은 실제 접속하는 사용자는 달라야 하지만, 테스트에서는 같은 사용자만을 사용하거나 특정 레코드에서만 액션이 일어나는 시나리오를 만들었을 때 발생한다.
ㅇ 시나리오 구조가 너무 복잡하다.
복잡한 시나리오를 만들었을 때 그 시나리오 실행 자체가 부하 테스트 도구에 부하를 발생시키는 경우가 있다. 예를 들어 JMeter에서 If 컨트롤러 사용에 따라 부하의 상한을 크게 떨어뜨리는 원인이 될 수 있어 주의해야 한다.
ㅁ 부하 테스트 서버 성능 부족
다음과 같은 상태가 발생했을 때는 부하 테스트 서버를 스케일 아웃/스케일 업해야 한다.
- CPU 리소스 부족
- 메모리 리소스 부족
- 네트워크 리소스 부족
ㅁ 부하 테스트 서버 네트워크 문제
ㅇ 네트워크 대역/속도 부족
부하 테스트 서버를 테스트 대상 시스템과 네트워크 적으로 떨어진 장소에 설치하면 네트워크 대역 부족과 높은 Latency에 다른 Throughput 저하가 발생하기 쉽다. 특히 네트워크 거리에 따른 Latency 증가는 부하 테스트 결과를 크게 좌우하는 원인이 된다.
부하테스트 서버는 대상 시스템과 같은 클라우드나 네트워크를 사용하거나 가능하면 가까운 위치에 두는 것을 권장한다.
ㅇ Keep-Alive 미사용
부하 테스트로 충분한 부하를 주기 위해서는 부하 테스트 도구와 테스트 대상 서버간에 고속의 요청을 주고 받을 필요가 있다. 부하 테스트 도구와 대상 시스템 간에는 Keep-Alive 옵션을 사용하지 않으면 요청별로 핸드쉐이크(handshake)를 해야 하므로 최종적으로는 테스트 도구에 병목이 발생한다.
Apache Bench에서는 -k옵션으로 Keep-Alive를 사용할 수 있다. 다른 도구도 설정할 수 있다.
ㅇ HTTPS 테스트 미시행
HTTPS 테스트에서는 부하 테스트 서버 쪽 CPU 리소스를 사용하고 Latency를 발생시키기 때문에 대상 시스템에 충분한 부하를 주는 것이 어렵다. 그래서 가능한 한 HTTP를 사용하여 테스트 한다.
ㅁ 참고표
부하테스트 도구 병목 원인과 대책 참고표
| 원인 구분 | 원인 상세 | 주요 증상 | 대책 |
| 서버/테스트 도구 설정 준비 부족 | 파일 디스크립터 부족 | 테스트 시작 후 잠시 후에 통신 실패가 발생 | 파일 디스크립터 설정 수정 |
| TCP 접속 제한으로 통신에 실패 | 테스트 시작 후 잠시 후에 통신 실패가 발생 | TCP 설정 수정 | |
| 도구 기동 옵션 준비 부족 | JMeter에서 OutOfMemoryError가 발생 | JMeter 기동 옵션에서 HEAP 크기 조정 | |
| 테스트 클라이언트 수 부족 | 대상 시스템에 충분한 부하를 주지 못하고 리소스 여유가 생김 | 테스트 클라이언트 수를 늘림 | |
| 테스트 클라이언트 수 많음 | 대상 시스템 Latency 가 커짐(수초 ~ 수십초) | 테스트 클라이언트 수를 줄임 | |
| 시나리오에 확인 대상이 많음 | 확인 대상을 최소한으로 변경 | ||
| 테스트 시나리오 준비 부족 | 참고, 갱신 대상 리소스가 같은 리소스에 집중 | DB 특정 레코드에 처리가 집중됨 | 사용자를 분산시키는 시나리오로 변경 |
| 시나리오가 너무 복잡 | - 시나리오 수정 - 테스트 서버 증설 |
||
| 부하 테스트 서버 성능 부족 | CPU/MEM/NETWORK 리소스 부족 | - 테스트 서버 스케일 업 - 테스트 서버 스케일 아웃 - 테스트 도구 검토 |
|
| 부하 테스트 서버 네트워크 부족 | 네트워크 대역/속도 부족 | Latency가 커져 대상 시스템에 부하가 걸리지 않음 | 근접한 네트워크에서 테스트 |
| HTTPS에서 테스트 실시 | Latency가 커져 대상 시스템에 부하가 걸리지 않음 | HTTP로 테스트 실시 | |
| Keep-Alive 미사용 | Latency가 커져 대상 시스템에 부하가 걸리지 않음 | 테스트 도구의 Keep-Alive 설정을 이용 |
'AWS 기본 환경 실습 > AWS 부하 테스트' 카테고리의 다른 글
| 4. DB 서버 병목 원인과 대책 (0) | 2021.03.15 |
|---|---|
| 3. 캐시 서버 병목 원인과 대책 (0) | 2021.03.12 |
| 2. 웹 서버 병목 원인과 대책 (0) | 2021.03.12 |