성능 테스트
성능 테스트는 문제가 시스템 사용자에게 도달하기 전에 시스템을 제대로 유지 관리하고 결함을 수정하는 데 도움이 됩니다. 비즈니스 요구 사항과 비교할 때 애플리케이션의 효율성, 응답성, 스케일링 성능 및 속도를 유지하는 데 도움이 됩니다. 효과적으로 수행되면 성능 테스트는 성능 저하로 이어지는 병목 현상을 제거하는 데 필요한 진단 정보를 제공해야 합니다. 병목 현상은 워크로드를 처리할 용량이 부족하여 데이터 흐름이 중단되거나 중지될 때 발생합니다.
성능 저하를 방지하려면 시스템 성능 테스트에 시간과 리소스를 투입합니다. 성능 테스트의 두 가지 하위 집합인 부하 테스트와 스트레스 테스트는 각각 애플리케이션 용량의 상한(용량 한도에 근접) 및 최대(실패 지점) 한도를 결정할 수 있습니다. 이러한 테스트를 수행하면 예상 워크로드를 지원하는 데 필요한 인프라를 확인할 수 있습니다.
모범 사례는 인프라에 과부하가 걸리지 않고 임의의 급증을 수용할 수 있도록 부하 버퍼를 계획하는 것입니다. 예를 들어, 정상적인 시스템 부하가 초당 100,000개 요청인 경우 인프라는 총 용량의 80%(즉, 초당 125,000개 요청)에서 100,000개 요청을 지원해야 합니다. 애플리케이션이 초당 100,000개 요청을 계속 유지할 것으로 예상하고 현재 SKU(Stock Keeping Unit)가 초당 65,000개 요청의 대기 시간을 도입하는 경우 제품을 다음으로 높은 SKU로 업그레이드해야 할 가능성이 큽니다. 보조 지역이 있는 경우 더 높은 SKU도 지원하는지 확인해야 합니다.
성능 테스트의 규모에 따라 테스트 인프라를 계획하고 유지 관리해야 합니다. Azure Load Testing 미리 보기와 같은 클라우드 기반 도구를 사용하여 성능 테스트를 실행하는 데 필요한 인프라를 추상화할 수 있습니다.
기준 설정
먼저 애플리케이션에 대한 성능 기준을 설정합니다. 그런 다음, 테스트를 실행하기 위한 정기적인 주기를 설정합니다. 예약된 이벤트의 일부 또는 CI(연속 통합) 빌드 파이프라인의 일부로 테스트를 실행합니다.
기준은 애플리케이션과 지원 인프라의 현재 효율성 상태를 결정하는 데 도움이 됩니다. 기준은 개선을 위한 좋은 인사이트를 제공하고 애플리케이션이 비즈니스 목표를 충족하는지 판단할 수 있습니다. 완성도에 관계없이 모든 애플리케이션에 대한 기준을 만들 수 있습니다. 언제 기준을 설정하든지 지속적인 개발 중에 해당 기준에 대해 성능을 측정합니다. 코드 및/또는 인프라가 변경되면 성능에 대한 영향을 능동적으로 측정할 수 있습니다.
부하 테스트
부하 테스트는 워크로드가 증가함에 따라 시스템 성능을 측정합니다. 애플리케이션이 중단된 위치와 시기를 식별하므로 프로덕션으로 배송하기 전에 문제를 해결할 수 있습니다. 이는 일반적인 과부하 조건에서 시스템 동작을 테스트하여 수행합니다.
부하 테스트는 부하 단계에서 발생합니다. 이러한 단계는 일반적으로 VU(가상 사용자) 또는 시뮬레이션된 요청에 의해 측정되며 단계는 지정된 간격에 따라 발생합니다. 부하 테스트는 고객(내부 또는 외부)에 대한 SLA를 계속 충족하기 위해 애플리케이션을 스케일 인해야 하는 방법과 시기에 대한 인사이트를 제공합니다. 부하 테스트는 분산 애플리케이션 및 마이크로 서비스 전반의 대기 시간을 결정하는 데에도 유용할 수 있습니다.
다음은 부하 테스트를 위해 고려해야 할 핵심 사항입니다.
Azure 서비스 제한 파악: 다양한 Azure 서비스에는 소프트 및 하드 제한이 연결되어 있습니다. 소프트 제한 및 하드 제한이라는 용어는 현재 조정 가능한 서비스 제한(소프트 제한)과 최대 제한(하드 제한)을 설명합니다. 초과해야 하는 경우 차단되지 않도록 사용하는 서비스에 대한 제한을 이해합니다. 가장 일반적인 Azure 제한 목록은 Azure 구독 및 서비스 제한, 할당량 및 제약 조건을 참조하세요.
ResourceLimits 샘플은 일반적으로 사용되는 리소스의 한도 및 할당량을 쿼리하는 방법을 보여 줍니다.일반 부하 측정: 시스템의 일반 및 최대 부하를 알면 시스템이 디자인된 한도를 벗어나 작동할 경우를 이해하는 데 도움이 됩니다. 트래픽을 모니터링하여 애플리케이션 동작을 이해합니다.
다양한 규모에서 애플리케이션 동작 이해: 애플리케이션을 부하 테스트하여 다양한 규모에서 성능을 이해합니다. 먼저 애플리케이션이 일반적인 부하 조건에서 어떻게 작동하는지 테스트합니다. 그런 다음, 다양한 스케일링 작업을 사용하여 부하 조건에서 어떻게 작동하는지 테스트합니다. 전송되는 트래픽 양이 증가함에 따라 애플리케이션을 평가하는 방법에 대한 추가 정보를 가져오려면 자동 스케일링 모범 사례를 참조하세요.
스트레스 테스트
시스템이 처리하도록 디자인된 것을 처리할 수 있는지 확인하는 부하 테스트와 달리, 스트레스 테스트는 시스템이 고장날 때까지 시스템에 과부하를 가하는 데 중점을 둡니다. 스트레스 테스트는 시스템이 얼마나 안정적인지와 부하의 극심한 증가를 견딜 수 있는 기능을 결정합니다. 성능이 저하되고 실패하기 전에 시스템이 주어진 시간에 처리할 수 있는 다른 서비스의 최대 요청 수를 테스트하여 이를 수행합니다. 현재 환경이 적절하게 지원할 수 있는 부하의 종류를 이해하려면 이 최댓값을 찾습니다.
메모리, CPU 및 디스크 IOPS에 할당할 최대 수요를 결정합니다. 스트레스 테스트가 수행되면 최대 지원 부하와 운영 한계를 알 수 있습니다. 임계값에 도달하기 전에 스케일링을 수행할 수 있도록 작동 임계값을 선택하는 것이 가장 좋습니다.
일반적인 부하에서 허용 가능한 운영 한계와 응답 시간을 결정했으면 환경이 적절하게 구성되었는지 확인합니다. 이렇게 하려면 선택한 SKU가 원하는 한계를 기반으로 하는지 확인합니다. 한계에 최대한 가깝게 유지하도록 주의합니다. 너무 많이 할당하면 비용과 유지 관리가 불필요하게 증가할 수 있습니다. 너무 적게 할당하면 사용자 환경이 저하될 수 있습니다.
증가된 부하를 통한 스트레스 테스트 외에도 리소스를 줄여 컴퓨터 메모리가 부족할 때 발생하는 상황을 식별하여 스트레스 테스트를 수행할 수 있습니다. 대기 시간을 늘려 스트레스 테스트를 수행할 수도 있습니다(예: 데이터베이스 응답 시간이 10배, 스토리지에 쓰기 시간이 10배 더 오래 걸리는 등).
다중 지역 테스트
다중 지역 아키텍처는 단일 지역에 배포하는 것보다 더 높은 가용성을 제공할 수 있습니다. 지역 중단이 주 지역에 영향을 미치는 경우 Front Door를 사용하여 보조 지역을 사용할 수 있습니다. 이 아키텍처는 애플리케이션의 개별 하위 시스템이 고장난 경우에도 도움이 될 수 있습니다.
지역에 장애가 발생하지 않도록 사용자가 쌍으로 연결된 지역으로 다시 라우팅되는 데 걸리는 시간을 테스트합니다. 라우팅에 대한 자세한 내용은 Front Door 라우팅 방법을 참조하세요. 일반적으로 계획된 테스트 장애 조치는 리디렉션된 부하를 지원하기 위해 완전히 스케일링되는 데 필요한 시간을 확인하는 데 도움이 될 수 있습니다.
테스트 결과에 따라 환경 구성
테스트를 수행하고 증가된 부하 수준에서 허용 가능한 운영 한계와 응답을 찾았으면 성능 효율성을 유지하도록 환경을 구성합니다. 부하 증가 및 감소를 처리하기 위해 스케일 아웃 또는 스케일 인합니다. 예를 들어, 낮에는 높은 수준의 트래픽이 발생하고 주말에는 낮은 수준의 트래픽이 발생한다는 것을 알고 있을 수 있습니다. 부하가 실제로 변경되기 전에 부하가 증가할 때는 스케일 아웃하고 부하가 감소할 때는 스케일 인하도록 환경을 구성할 수 있습니다.
자동 스케일링에 대한 자세한 내용은 성능 효율성 핵심 요소에서 스케일링을 위한 디자인을 참조하세요.
참고
부하가 설정된 임계값 아래에 도달하면 환경을 다시 스케일 다운하도록 규칙이 구성되었는지 확인합니다. 이렇게 하면 비용이 절약됩니다.