1. 부하 테스트의 기본 개념

• 부하 테스트는 시스템의 성능과 안정성을 검증하는 중요한 과정입니다.
• 이를 위해 다음과 같은 도구들이 사용됩니다:
  • 부하 테스트 도구: 시스템에 실제 부하를 발생시키는 도구
  • 모니터링 도구: 시스템 리소스 사용률을 가시화하는 도구
  • 프로파일링 도구: 미들웨어와 애플리케이션의 내부 동작을 분석하고 가시화하는 도구

2. 부하 테스트 도구

• 부하 테스트 도구란 웹 시스템뿐만 아니라 특정 시스템을 사용하는 입장에서 시뮬레이션하여 대상 시스템의 상태를 고부하로 만들어 주는 도구입니다.
• 부하 테스트 도구를 이용하면 시스템에 많은 요청을 일으키고 DoS 공격이나 DDoS 공격이 발생하는 것과 같은 상황을 시뮬레이션할 수 있습니다.
• 부하 테스트 도구를 기동한 서버를 부하 테스트 서버라고 하며, 이 서버는 부하 테스트 도구를 이용하여 대상 시스템에 부하를 주는 역할을 합니다.

2.1 부하 테스트 도구의 선택 기준

• 요청을 정확히 시물레이션한다.
  • Apach Bench를 사용하면 시나리오 기반 테스트를 할 수 없습니다.
  • 정확한 요청 패턴을 시뮬레이션 할 수 없는 도구가 있으니 시나리오 기반 테스트를 할 수 있는 도구를 선택해야 합니다.
• 부하 정도를 조정 가능해야한다.
  • 요청 간격, 최대 Throughput 등을 조정하여 공격 강도를 조절할 수 있어야 합니다.
  • 대부분의 테스트 도구가 이 기능을 제공합니다.
• 대상 시스템에 충분한 부하를 줄 수 있어야 한다.
• 부하 테스트 도구 설치 장소 및 가동 장소를 선택할 수 있어야 한다.
  • 도구에 따라 기동할 수 있는 서버에 제약이 있을 수 있습니다.
  • 또한 SaaS 서비스로 원격 설치된 서버에서 부하를 줄 수 있습니다. 이 경우 대상 시스템에만 부하를 주는 것이 어려워 질 수 있습니다.

2.2 세션 ID와 패드워드 등 요청별로 다른 파라미터 값이 필요한 경우

• 부하 테스트 도구는 요청별로 다른 파라미터 값을 사용할 수 있어야 합니다.
• 이를 위한 방안으로 2가지 방식이 있습니다.
  • 부하 테스트 대상 프로그램을 수정하여 파라미터를 사용하는 부분에 스텁을 사용한다. 또는 프로그램 앞단에서 파라미터를 생성하여 넣어주는 방식입니다.
  • 복잡한 테스트 시나리오 실행이 가능한 도구를 사용하는 방법입니다.
• 복잡한 테스트 시나리오 실행이 가능한 도구로 Locus, JMeter, K6 등이 있습니다.
  • 이를 사용하면 요청을 생성할 때 세션ID를 수집하고 다음 요청에 그 세션 ID를 사용하는 등의 작업을 할 수 있습니다.

2.3 높은 Throughput을 가진 시스템 부하 테스트

• 높은 Throughput을 요구하는 시스템의 경우 높은 부하를 줄 수 있는 도구를 사용해야 합니다.
• 이 도구들은 테스트 서버를 병렬로 여러 대 사용하여 서버의 스케일 아웃을 지원합니다.
• 이런 도구로는 Apache JMeter, Locust, K6 등이 있습니다.

2.4 긴 시간 부하를 주는 내구성 테스트

• Apache Bench는 수초~수분 범위의 테스트는 적합하지만 수시간 이상의 테스트는 적합하지 않습니다.
• 또한 JMeter도 몇 시간 이상 부하를 중 경우 테스트 중에 요청의 양이 줄어드는 현상이 발생할 수 있습니다.

3. 부하 테스트 공통 개념

• 클라이언트: HTTP 요청을 동시에 1개만 줄 수 있는 요청 생성기
• 클라이언트 동시 가동 수: 테스트 시작 후에 테스트 도구에서 사용할 수 있는 클라이이언트 수
• ramp up 기간: 테스트 시작 후 클라이언트 동시 가동 수를 증가시키는 시간
• 시나리오: 클라이언트별로 설정된 HTTP 요청 생성 패턴
• 시나리오 실행 횟수: 클라이언트가 시나리오에 따라 요청을 보내는 횟수

3.1 클라이언트 요청 라이프 사이클

1. 부하 테스트 서버에서 http 요청 생성
2. http 요청이 네트워크 이동
3. 로드 밸랜서가 요청을 웹 서버에 전달
4. http 요청을 웹 서버가 받음
5. http 응답을 웹 서버가 보냄
6. 로드 밸런서를 통해 외부로 나감
7. http 응답이 네트워크로 이동
8. 부하 테스트 서버가 http 응답을 받음

여기서 중요한 점

• 부하 테스트의 latency는 대상 시스템의 latency와 다르다.
  • 부하 테스트의 latency는 네트워크로 전송되는 동안 발생하는 latency, SSL 프로토콜에 의한 추가 latency, 실제 시스템 처리 시간을 포함한다.
• 부하 테스트 도구의 클라이언트 동시 기동 수와 시스템에서 처리되는 동시 처리 수는 다르다.
  • 부하 테스트 도구에서 생성된 요청은 대부분 네트워크나 서버에 있으며 실제 부하를 줘야하는 대상 시스템에서 처리 중인 요청은 요청 중 일부일 뿐입니다.
  • 특히 네트워크 latency가 클 때는 부하 테스트 도구의 클라이언트 동시 가동 수와 비교하여 실제 처리 중인 요청 비율은 낮아질 수 있습니다.
  • 이런 상황에서 충분한 부하를 주기 위해서는 부하 테스트 서버의 동시 기동 수를 높여야 합니다.
• 부하 테스트 도구의 클라이언트는 아프이 요청이 완료되지 않으면 다음 요청을 생성하지 않는다.

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

• 부하 테스트의 부하 테스트 서버는 1-N대의 범위지만, 실제 서비스 환경은 요청을 한 수 만큼의 사용자가 존재합니다.
• 따라서 SSL을 사용한 사이트의 부하 테스트 환경에서 SSL 접속과 계산 처리가 부하 테스트 서버에 집중됩니다.
  • 실제 서비스 환경에서는 사용자의 브라우저에서 SSL 접속과 계산 처리가 이루어집니다.
• HTTP 요청의 경우에도 통신을 끊고 다시 접속하게 되면 부하 테스트 서버에 과부하가 발생합니다.
• 네트워크 부하도 테스트 환경에서는 집중되지만, 실제 서비스 환경에서는 분산됩니다.
  • 따라서 테스트 서버의 사양을 아무리 높여도 네트워크 대역이 충분하지 않으면 부하 테스트를 실행할 수 없습니다.
• 요청을 보내는 서버와 엔드포인트 차이
  • 엔드포인트가 되는 서버가 부하 테스트 환경에서는 부하 테스트 서버별로 일정 시간 동안 DNS 정보를 캐싱합니다.
  • 그래서 부하를 받는 서버가 스케일 아웃 되더라도 성능을 내지 못할 수 있습니다.
  • 실 서비스 환경에서는 하나의 서버가 아닌 여러 곳으로 분산되어 있어 이런 문제가 없습니다.
  • 이 문제 해결을 위해 네트워크 영향을 최소할 필요가 있습니다. 테스트 대상 시스템의 가까운 지점에서 테스트를 실행합니다.
• 동시 요청 수의 차이
  • 부하 테스트 환경에서는 요청 결과를 받기 전까지 다음 요청을 보내지 않습니다.
  • 이와 같은 동작으로 시스템의 응답이 아무리 늦어도 지정한 클라이언트 수으 요청밖에 동시에 발생하지 않습니다.
  • 하지만 실제 서비스 환경에서는 특정 사용자 응답이 늦어져 그 요청에 대한 결과를 기다리면서도 새로운 사용자가 새로운 요청을 계속 보냅니다.
  • 따라서 시스템 응답 시간이 늦더라도 처리해야 할 동시 요청 수는 점점 증가합니다.
• 일부 느린 처리가 전체 Throughput에 영향을 미침
  • 부하 테스트 환경에서 시스템 리소스 사용량이 적음에도 실행 시간이 길어지는 요청이 조금 섞이면 다음 요청을 보낼 수 없게 되고 결과적으로 전체 Throughput이 낮아집니다.
  • 실제 서비스 환경에서는 이런 문제가 발생하지 않습니다.
  • 이런 경우 시간이 소요되는 요청은 별도 스레드로 테스트하거나 시나리오에서 빼고 테스트하는 것이 좋습니다.