부하 테스트 유형

다음 테스트 유형은 가이드 앞부분에 나열된 기본 질문을 기반으로 합니다.

애플리케이션이 어느 정도의 로드를 견딜 수 있는가?

애플리케이션이 견딜 수 있는 부하를 확인하기 위해 테스트를 설정할 때는 먼저 초당 요청 수(req/s), 응답 시간(초) 또는 동시 사용자 수를 측정할지 결정합니다. 어느 경우든 애플리케이션의 어느 부분을 테스트할지 정의합니다.

• 사이트 탐색은 여러 페이지 또는 엔드포인트를 방문하거나 각 요청마다 다른 파라미터를 사용하여 단일 엔드포인트에 데이터를 요청함으로써 발생하는 부하입니다. 사용할 도구 섹션에 설명된 기본 도구를 사용하여 이를 수행할 수 있는 경우가 많습니다. 캐시는 애플리케이션의 중요한 구성 요소인 경우가 많으므로 테스트에 캐싱 계층을 포함할지 여부를 결정합니다.

• 요청이 서로 의존하고 요청 간에 데이터를 전달하는 체크아웃과 같은 트랜잭션 워크플로를 테스트하려면 더 복잡한 도구가 필요합니다. 또한 다단계 트랜잭션의 컨텍스트에서는 요청 측정의 관련성이 제한적이므로 도구에서 별도의 데이터 포인트로 생성해야 하는 전체 트랜잭션을 계산하는 것이 더 정확합니다. 이러한 데이터 포인트를 제공하도록 Apache JMeter 및 k6 도구를 구성할 수 있습니다.

대상 시스템의 성능 및 오류율에 대한 허용 가능한 임곗값을 정의합니다. 일부 시스템의 경우 이벤트가 성공적으로 처리되는 한 응답 시간에 신경 쓰지 않을 수 있습니다. 사용자 상호 작용이 있는 애플리케이션과 같은 많은 애플리케이션의 경우 최종 사용자에게 허용되는 한도를 정의합니다.

테스트를 단계별로 수행하는 것이 도움이 되는 경우가 많습니다. 정의된 임곗값에 도달할 때까지 각 단계마다 부하가 증가합니다. 반복 테스트의 경우 이전 테스트를 통해 학습하고 단계별 진행을 개선하여 테스트에서 더 적은 단계를 수행하면서도 여전히 유효한 결과를 얻을 수 있습니다.

애플리케이션에서 X 로드를 처리할 수 있는가?

이전 테스트와 마찬가지로 테스트 중인 애플리케이션의 특성에 따라 req/s 또는 동시 사용자 수로 이 테스트의 부하를 정의할 수 있습니다. 이 테스트는 이전 테스트의 간소화된 버전입니다. 여기서는 특정 워크로드를 제출해야 하며 시스템에서 이를 처리할 수 있어야 합니다. 필요한 부하 볼륨 지정을 지원하는 테스트 도구를 선택하는 것이 중요합니다.

테스트 실행 시간도 관련이 있을 수 있습니다. 일부 효과는 테스트를 장기간 실행한 경우에만 관찰할 수 있습니다. 예를 들어, 역압으로 인해 대기열에 과부하가 발생할 수 있습니다. 운영 시스템을 복제하고 올바른 결론을 내리려는 경우 테스트 실행에 필요한 시간이 테스트 시스템의 규모에 영향을 미칠 수 있습니다.

애플리케이션이 자동으로 스케일 업되고 스케일 다운되는가?

탄력성은 클라우드의 주요 판매 포인트이자 비용 절감의 핵심 소스입니다. 탄력성을 확실하게 활용할 수 있도록 애플리케이션이 적절하게 확장되고 있는지 테스트하는 것이 클라우드 여정에 포함되어야 합니다.

스케일 업 및 스케일 다운에 사용되는 주요 지표를 식별해야 합니다. 일반적으로 이는 대상 시스템의 CPU 부하입니다. CPU 부하를 생성하는 엔드포인트를 대상으로 사용할 수 있습니다.

이 테스트에는 표현성이 필요하지 않으므로 부작용이 없는 엔드포인트를 대상으로 하는 것이 좋습니다. 또한 누적될 수 있는 데이터를 지속하거나 후속 프로세스를 시작하여 불필요한 비용을 유발하거나 부하를 차단하는 흐름을 시작하는 것도 바람직하지 않습니다.

단계별 프로세스로 테스트를 수행하여 부하를 점진적으로 늘립니다. 간격은 각 단계에서 지표가 조정을 시작할 수 있을 만큼 충분히 길어야 합니다. 예를 들어, 5분 동안 CPU 부하가 70% 이상이어야 한다는 규칙이 있는 경우 조정 이벤트를 시작하고 실행하는 데 걸리는 시간을 제공하려면 단계가 5분 이상이어야 합니다. 또한 규모 조정이 제대로 작동하고 생성한 부하 상황이 해결되었는지도 확인하고 싶을 것입니다.

서버 2대로 규모 조정 테스트를 시작하는 것을 고려해 보세요. 소규모 환경에서는 스케일 업 속도가 느리고 부하에 대처하기 위해 여러 주기가 필요할 수 있습니다. 그리고 EC2 Auto Scaling 클러스터는 크기를 두 배로 늘어날 수만 있습니다. 즉, 서버 1대로 시작하여 부하 테스트를 시작하는 경우 첫 번째 조정 이벤트의 최대 규모는 서버 2대까지만 가능합니다. 부하로 인해 서버가 3대 필요한 경우 2개의 조정 이벤트가 필요하며 이 작업에는 20분 이상 걸릴 수 있습니다.

원하는 스케일 업 이벤트 트리거를 모니터링하고 조정이 실제 부하에 적합한지 여부를 모니터링합니다.

스케일 다운 이벤트를 구현한 경우 단계별로 테스트할 수도 있습니다. 스케일 다운이 기존 부하에 적용 가능하고 적절한지 모니터링하고, 스케일 업이 즉시 다시 시작되지 않는지 확인합니다.

부하가 계속 높아지면 시간이 지날수록 애플리케이션 동작이 저하되는가?

일부 효과는 장기간에 걸쳐 부하가 생성되는 경우에만 관찰될 수 있습니다. 가장 중요한 효과 중 하나는 배압입니다. 즉, 시스템이 너무 느려 요청 수를 원하는 속도로 처리할 수 없을 경우 클라이언트 시스템의 성능이 저하됩니다.

속도가 느린 시스템이 부하 대상인 경우 이를 쉽게 관찰할 수 있습니다. 좀 더 복잡한 설정에서는 부하 테스트의 영향이 전파될 때만 효과를 관찰할 수 있습니다. 분산 시스템에서 각 서비스 간의 응답 시간을 시각화할 수 있는 추적 솔루션은 결과를 더 빠르게 보여줄 뿐만 아니라 병목 현상을 일으키는 시스템을 식별하는 데 도움이 될 수 있습니다. 로그 파일에서 메시지 상관 관계 ID를 가져와서 병목 시스템을 식별할 수 있습니다. 각 요청은 부하 테스트를 거치는 모든 시스템에서 동일한 ID를 유지합니다.

상관 관계 ID를 사용하면 플랫폼의 다양한 구성 요소를 통한 단일 메시지의 전체 여정을 추적할 수 있습니다. 이 정보를 사용하면 메시지가 통과하는 각 단일 구성 요소의 처리 시간(processing_time = departure_time – arrival_time)을 계산하고 가장 느린 구성 요소를 식별할 수 있습니다. Zipkin, Jaeger 및 AWS X-Ray가 이 분야의 대표적인 솔루션입니다.

가장 신뢰할 수 있는 결과를 얻으려면 일정한 요청 속도 설정을 지원하는 도구를 선택합니다. 즉, 대상 시스템의 속도가 느려지면 테스트 도구의 동시성을 높이거나 req/s를 일정하게 유지해야 합니다. 시스템이 더 느리게 응답하기 시작하면 스레드가 더 많이 묶여 부하 생성 도구의 요청 속도가 낮아집니다. 요청 빈도가 일정한 도구는 발생 시 동시성을 높여야 합니다. 그러면 장애가 더 빨리 발생할 수 있습니다. 달성된 요청 수만큼 성능 저하를 측정하는 대신 지연 시간 및 실패한 요청까지도 기준으로 측정할 수 있습니다.

애플리케이션이 제대로 작동하는가?

일반적으로 부하를 많이 발생시키는 것이 아니라 기능을 확인하는 상당한 수의 요청을 생성합니다. 또한 고객이 테스트된 흐름을 방문하지 않을 때 프로덕션 환경에 대비하여 주기적으로 이 작업을 수행하여 추가 모니터링 계층을 마련할 수도 있습니다.

즉, 부하 테스트를 위해 이미 생성된 시나리오를 더 낮은 부하로 구성된 프로덕션에서 재사용할 수 있습니다.