성능 테스트를 위한 아키텍처 전략

다음 Azure Well-Architected Framework 성능 효율성 검사 목록 권장 사항에 적용됩니다.

PE:06 프로덕션과 유사한 환경에서 정기적으로 테스트하여 워크로드가 원하는 성능 목표에 도달하고 비즈니스 목표를 달성할 수 있도록 하여 워크로드 성능을 최적화합니다.

성능 테스트는 다양한 조건에서 워크로드가 작동하는 방식을 평가하는 데 사용되는 비기능 테스트 사례입니다. 이를 통해 성능 저하를 조기에 식별하고, 문제를 사전에 해결하고, 서비스 수준 계약에 지속적으로 부합하도록 할 수 있습니다.

응답 시간, 처리량, 리소스 사용량 및 안정성을 측정할 때 워크로드가 정의된 목표를 일관되게 충족하고 비즈니스에 필요한 성능 수준을 제공한다는 증거를 수집합니다.

이 문서의 주요 전략은 테스트를 위한 OE:09 아키텍처 전략에 설명된 기본 테스트 사례를 기반으로 합니다. 먼저 해당 문서를 검토하는 것이 좋습니다. 이 가이드의 권장 사항은 성능으로 범위가 지정되며 워크로드가 진화하는 비즈니스 목표에 맞게 유지되도록 성능 목표를 달성하는 데 집중합니다.

다음 표에서는 이 문서 전체에서 사용되는 주요 성능 용어를 정의합니다.

용어 Definition
성능 목표 응답 시간, 처리량 또는 동시 사용자 수와 같이 워크로드가 충족해야 하는 특정 성능 값입니다.
성능 임계값 지정된 메트릭에 대해 허용되는 성능과 허용되지 않는 성능을 구분하는 경계입니다.
성능 예산 워크로드의 각 계층 또는 구성 요소에 할당된 전체 성능 대상의 부분입니다.
오류 예산 SLO에 기반하여 도출된 허용되는 오류 또는 장애 수준입니다.
승인 조건 성능 요구 사항을 통과하기 위해 워크로드에 대해 테스트 결과가 충족해야 하는 조건입니다.
가설 기반 실험 성능에 대한 예측을 명시하고, 기준선에 대해 테스트하고, 측정된 결과로 유효성을 검사하는 테스트 메서드입니다.
성능 기준 테스트를 통해 유효성을 검사하는 정상적인 조건에서 워크로드의 동작을 나타내는 메트릭 집합입니다.
가상 트랜잭션 제어된 조건에서 시스템 성능을 측정하기 위해 실제 사용자 상호 작용을 시뮬레이션하는 스크립트된 요청입니다.
성능 회귀 코드, 구성 또는 인프라의 변경으로 인해 도입된 설정된 기준과 비교하여 성능이 저하됩니다.
성능 변화 설정된 기준에 대한 정기적인 테스트 없이는 눈에 띄지 않는 시간이 지남에 따라 성능이 점진적으로 감소합니다.

성능 테스트에 대한 측정 가능한 목표 설정

측정 가능한 성능 목표는 주관적인 기대치를 테스트하고 유효성을 검사할 수 있는 목표 조건으로 바뀝니다.

성능 목표를 정의하고 예산을 할당합니다. 지원해야 하는 동시 사용자 수와 같은 특정 성능 목표를 정의하고 문서화합니다. 이러한 대상이 SLO(서비스 수준 목표)와 일치하는지 확인하고 측정 가능한 테스트 목표로 변환합니다.

워크로드의 여러 계층에 성능 및 오류 예산을 할당합니다. 성능 테스트가 실패하면 예산은 책임 있는 계층과 최적화 노력에 집중할 위치를 식별하는 데 도움이 됩니다. 예산이 없으면, 성능 목표가 충족되지 않는다는 사실만 알 수 있을 뿐, 문제의 원인을 알아낼 수 없습니다.

예를 들어 API 응답 시간에는 400ms, 데이터베이스 쿼리의 경우 150ms, 실패한 요청에는 1개의% 한도로 예산을 설정할 수 있습니다. 테스트가 실패하면 각 계층의 결과를 예산과 비교하여 확인하여 문제가 느린 API 응답, 느린 데이터베이스 쿼리 또는 오류 급증인지 확인할 수 있습니다.

메모

사용자 흐름 및 성능 요구 사항을 이해하기 전에 SLO를 정의하지 마십시오. SLO는 임의 대상이 아닌 실제 사용자 요구 사항 및 비즈니스 목표를 기반으로 해야 합니다.

명확한 통과 및 실패 임계값을 사용하여 수용 조건을 정의합니다. 대기 시간, 응답 시간, 처리량, 리소스 사용률, 오류 비율 및 성능 목표에 맞는 기타 성능 지표와 같은 성능 메트릭에 대한 수용 기준을 기반으로 합니다.

테스트에서 명확한 통과 또는 실패 결과를 생성할 수 있도록 각 메트릭에 대한 임계값을 정의합니다. SLO에서 200ms 이내에 95개% 요청을 완료해야 하는 경우 API 응답 시간 임계값을 95번째 백분위수에서 200ms로 설정합니다. 95번째 백분위수가 200ms를 초과하는 모든 테스트 실행은 실패합니다.

일찍 시작하고 지속적으로 테스트

초기 성능 분석은 아키텍처 병목 상태를 파악한 후 비용이 많이 들기 전에 해결합니다.

워크로드의 소프트웨어 개발 수명 주기에서 가능한 한 빨리 성능 테스트를 시작합니다. 전체 애플리케이션을 시작할 필요가 없습니다. 개발자는 코드를 로컬로 프로파일레이션하고, 응답 시간을 측정하고, 리소스 집약적 작업을 식별할 수 있습니다. 초기 테스트는 디자인 결정을 알리고, 성능 목표에 대한 아키텍처 선택 사항의 유효성을 검사하며, 최적화 기회를 식별합니다.

새로운 요구 사항을 충족하기 위해 워크로드가 발전함에 따라 지속적으로 테스트합니다. 각 코드 변경은 성능 회귀를 도입할 수 있습니다. 정기적으로 테스트를 실행하여 이러한 변경 내용을 조기에 catch합니다. 배포 파이프라인에 성능 테스트를 통합하고 주기적인 자동화된 테스트를 실행하여 프로덕션에 도달하기 전에 성능 드리프트를 검색합니다.

절충. 초기 성능 테스트에는 전용 인프라와 전문 지식이 필요하므로 운영 비용이 증가합니다. 투자 비용을 늦게 발견된 성능 문제와 프로덕션 문제의 비용과 비교하여 균형을 맞추십시오.

실제 조건에서 테스트

성능 테스트는 실제 조건과 일치해야 하므로 결과가 의미가 있습니다.

프로덕션 환경 미러링

테스트 환경은 프로덕션을 실용적으로 미러링해야 합니다. 워크로드의 위험 프로필에 따라 환경에 대한 접근 방식을 조정합니다.

중요 업무용 워크로드의 경우, 생산 환경을 다음과 같이 정확히 일치시킵니다.

  • 컴퓨터 SKU 및 구성
  • 자동 크기 조정 설정
  • 캐싱 구성
  • 네트워크 조건(대기 시간, 대역폭)
  • 외부 종속성

비임계 워크로드의 경우 프로덕션을 모방하는 스케일 다운 환경에서 테스트하면 더 저렴한 비용으로 유용한 인사이트를 제공할 수 있습니다.

구성 드리프트를 방지하십시오. 구성 드리프트로 인해 잘못된 테스트 결과가 발생할 수 있습니다. 자동화된 검사를 구현하여 테스트 환경이 프로덕션과 일치하는지 확인합니다. 테스트를 실행하기 전에 올바른 버전이 배포되었는지 확인합니다.

절충. 성능 테스트를 위한 전체 프로덕션 복제는 인프라 비용을 크게 증가시킵니다. 프로덕션에서 성능 문제의 위험이 워크로드에 대한 전용 성능 테스트 인프라 비용을 정당화하는지 여부를 평가합니다.

프로덕션 환경에서 성능 유효성 검사

테스트 환경은 성능에 영향을 주는 실제 조건을 완전히 복제할 수 없습니다. 프로덕션 테스트는 실제 사용량에서만 나타나는 문제를 노출하고 향후 최적화를 위한 정확한 기준을 제공합니다. 일부 성능 요구 사항은 실제 사용자, 데이터 및 인프라가 교차하는 경우에만 유효성을 검사할 수 있습니다.

제어된 프로덕션 테스트를 실행합니다. 비사용 시간대에 테스트를 예약하여 리소스가 고갈된 상태에서 워크로드가 어떻게 동작하는지와 실패에서 어떻게 복구하는지를 이해합니다.

프로덕션 테스트는 다음을 포함하여 실제 조건에서 성능 특성을 보여 줍니다.

  • 실제 사용자 동작 패턴 및 데이터 볼륨
  • 실제 네트워크 대기 시간 및 대역폭 변형
  • 지리적 분포 효과
  • 타사 API 성능 및 종속성
  • 실제 캐싱 동작 및 인프라 특성

점진적 테스트 기술을 사용합니다. 트래픽의 작은 비율로 시작하고 점차적으로 증가합니다. 각 단계에서 응답 시간, 처리량, 오류 비율 및 리소스 사용률을 모니터링합니다. 이 점진적 접근 방식은 중단점을 식별하고, 병목 상태를 표시하고, 증가하는 수요에 따라 시스템 동작을 정확하게 파악하는 동안 위험을 제한합니다.

프로덕션 테스트를 지속적으로 모니터링 하여 문제를 조기에 찾습니다. 자동화된 롤백 메커니즘 및 실시간 경고와 같이 사용자에게 부정적인 영향을 주는 경우 테스트를 중지하는 자동화된 보호 기능을 구현합니다. 이러한 기술은 신속한 대응을 보장하고 중단을 최소화합니다.

메모

프로덕션에서 제어된 성능 테스트를 실행하는 경우 테스트에서 생성된 추가 부하를 처리하기 위해 추가 용량을 할당해야 합니다.

위험: 프로덕션 테스트는 추가 부하를 생성하고 트래픽을 방해할 수 있으므로 실제 고객에게 직접적인 영향을 줍니다. 항상 안전 장치를 구현하고, 노출을 제한하며, 잠재적인 비즈니스 영향을 최소화할 준비가 된 롤백 계획을 갖습니다. 실제 테스트의 이점과 라이브 사용자 중단의 잠재적인 비즈니스 영향의 균형을 맞출 수 있습니다.

가설 기반 실험을 사용하여 변경 내용 유효성 검사

가설 기반 실험을 사용하여 성능 테스트를 안내합니다. 의미 있는 결과를 생성하도록 개별 성능 실험을 디자인합니다.

워크로드 성능에 대한 집중적인 가설부터 시작하고 실행 가능한 의사 결정으로 이어지는 측정 가능한 성공 기준을 정의합니다. 예를 들어 가설은 다음과 같습니다. "orders 테이블에 인덱스를 추가하면 최대 부하에서 쿼리 시간이 70% 줄어듭니다." 기준은 현재 스키마이고 변형은 새 인덱스가 있는 스키마입니다. 두 버전에 대해 동일한 부하 테스트를 실행합니다. 쿼리 대기 시간, 데이터베이스 CPU 사용량 및 처리량을 캡처한 다음 결과를 비교하여 가설이 true인지 여부를 확인합니다.

거래. 가설 기반 실험을 수행하려면 기준 및 변형 구성 모두에 대해 동일한 테스트를 실행해야 하므로 인프라 비용과 테스트 실행 시간이 증가합니다. 잠재적인 성능 향상이 추가 테스트 노력을 정당화하는 영향력이 큰 변경에 초점을 맞춥니다.

여러 성능 테스트 유형 적용

성능 테스트는 다양한 조건에서 속도, 안정성 및 확장성을 평가하는 다양한 테스트를 포함합니다. 각 테스트 유형은 워크로드의 고유한 성능 측면을 대상으로 합니다. 고유한 인사이트를 파악하고 기능 테스트를 넘어서는 전체 평가를 가능하게 합니다.

여러 테스트 유형을 사용하여 다양한 각도에서 워크로드의 유효성을 검사합니다. 예를 들어 스트레스 테스트는 최대 부하 하에서 중단점을 찾지만 지구력 테스트만 몇 시간 또는 며칠에 걸쳐 표면화되는 메모리 누수만 표시됩니다.

유효성을 검사해야 하는 항목에 따라 테스트 유형을 선택합니다.

다음 표에서는 각 테스트 유형을 사용하는 시기와 워크로드에 대해 표시되는 내용을 보여 줍니다. 이 테이블은 전체 목록은 아니지만 설명 예제로 사용됩니다.

테스트 유형 기본 용도 적용 시기 그것이 드러내는 것 Environment
부하 테스트 시스템이 정상 및 최대 사용량에서 예상 사용자 볼륨을 처리하는지 확인합니다. 일찍 시작, 자주 실행 기준 성능, 용량 제한, 크기 조정 효율성 스테이징 또는 프로덕션과 유사한 환경
스트레스 테스트 시스템 제한 및 중단점 이해 시스템이 프로덕션 준비되기 전에 최대 용량, 실패 모드, 복구 동작 전용 성능 테스트 환경
스파이크 테스트 시스템이 갑작스러운 트래픽 급증을 처리하는지 확인 특히 퍼블릭 앱의 경우 일찍 시작 자동 확장 응답성, 큐 처리, 정상적인 성능 저하 스테이징 또는 프로덕션 환경
내구성/지속 테스트 장기간에만 나타나는 문제 검색 초기 부하 테스트 통과 후 메모리 누수, 리소스 소모, 연결 풀 문제 전체 리소스 할당이 있는 프로덕션과 유사한 환경

모든 테스트 형식을 즉시 구현하지 마세요. 기본 부하 테스트로 시작하여 기준 성능을 이해합니다. 위험을 식별하고 경험을 쌓으면 스트레스 테스트, 스파이크 테스트 및 최종 지구력 테스트로 확장합니다.

절충. 모든 테스트 유형에서 성능 테스트를 수행하기 위해서는 상당한 시간과 인프라 투자가 필요합니다. 테스트 투자를 비즈니스 위험과 일치시킬 수 있습니다.

실제 사용 패턴 및 데이터 특성 사용

실제 데이터를 사용하여 테스트하면 리소스 사용량, 시스템 동작 및 숨겨진 성능 문제에 대한 정확한 인사이트를 얻을 수 있습니다.

다양한 시나리오, 사용자 프로필 및 데이터 볼륨을 나타내는 다양한 테스트 데이터 집합을 만듭니다. 입력 변형 및 임의화를 사용하여 실제 사용자 다양성을 모방합니다. 대용량 페이로드, 복잡한 쿼리 또는 높은 동시성 등 성능 문제를 일으킬 수 있는 에지 사례를 포함합니다.

테스트 데이터는 실제 프로덕션 데이터처럼 보입니다. 프로덕션 데이터 특성이 있는 합성 데이터를 사용합니다. 트랜잭션 일관성, 대기 시간 및 볼륨 처리와 같은 데이터 관리 동작을 강조 표시하는 등의 특정 시나리오에 대해 프로덕션 데이터 세트를 예약합니다(제대로 익명화됨).

실제 사용자 워크플로를 모방하는 가상 트랜잭션을 시뮬레이션합니다. 이러한 트랜잭션을 스크립션하고 반복적으로 실행하여 워크로드가 실제로 사용되는 방식을 반영하는 부하를 생성합니다.

테스트 시나리오는 동시 사용자 액세스, 최대 로드 기간 및 특정 트랜잭션 시퀀스와 같은 실제 사용 패턴을 반영해야 합니다. 성능 결과가 진정한 사용자 가치를 반영할 수 있도록 시나리오가 비즈니스 목표에 부합하는지 확인합니다.

부하를 테스트할 때 실제 타사 API 호출을 포함합니다. 외부 종속성을 모의하면 테스트가 더 빠르고 예측 가능하게 실행되지만 실제 성능 문제가 숨겨집니다. 앱이 결제 프로세서 API에 종속된 경우 실제 호출로 테스트하여 엔드 투 엔드 대기 시간을 이해합니다.

테스트 결과를 사용하여 디자인 결정 안내

테스트 결과는 신뢰할 수 있는 기준을 설정하고 최적화 노력을 안내하여 디자인 결정을 내립니다.

기준 측정값을 설정합니다. 기준은 추세 및 변칙을 식별하고 최적화 변경이 향상된 기능을 제공하는지 여부를 식별하는 데 도움이 됩니다. 시간에 따른 성능 추세를 추적하려면 신뢰할 수 있는 기준이 필요합니다.

초기 테스트 중에 성능 메트릭을 기록합니다. 이 기록은 "정상" 성능의 스냅샷인 기준입니다. 후속 실행에서 이 기준선과 새 결과를 비교하여 성능 변경을 검색합니다. 다양한 조건에서 시스템 동작을 이해하기 위해 데이터를 검사할 때 사용자 영향, 빈도, 수정 비용 및 변경 조건의 위험을 고려합니다. 성능이 저하되는 위치를 보여 주는 패턴을 찾습니다. 이 인사이트를 사용하여 최적화 작업의 우선 순위를 지정합니다.

최적화는 반복적인 프로세스이며 데이터에 의해 구동되어야 합니다. 성능 최적화를 위해 개발 주기에서 전용 시간을 따로 둡니다. 기준을 사용하여 변경의 영향을 측정하고 회귀를 도입하지 않고 예상되는 개선 사항을 제공할 수 있습니다.

성능과 비즈니스 메트릭의 상관 관계를 지정합니다. 성능 향상을 수익, 사용자 참여, 고객 만족도 및 전환율과 같은 비즈니스 결과에 연결하여 성능 최적화에 대한 지속적인 투자를 정당화합니다.

메모

아키텍처 변경, 새로운 기능 또는 크기 조정과 같이 워크로드를 크게 변경한 후 정기적으로 기준을 검토하고 업데이트합니다. 이 작업을 수행하면 성능 목표가 관련성을 유지합니다.

테스트 자산을 현재 사용 패턴에 맞게 유지

성능 테스트 자산에는 워크로드의 예상 동작, 허용 가능한 성능 임계값 및 실제 트래픽 패턴에 대한 중요한 지식이 포함되어 있습니다.

테스트 도구 모음을 유형별로 구성합니다. 부하 테스트, 스트레스 테스트 및 지구력 테스트를 별도의 제품군에 보관합니다. 혼합하지 마십시오. 각 형식에는 서로 다른 설정 요구 사항, 실행 기간 및 성공 기준이 있습니다. 구성된 제품군을 사용하면 대상 테스트를 더 쉽게 실행하고, 실행 간에 결과를 비교하고, 각 제품군을 독립적으로 유지 관리할 수 있습니다.

정기적으로 테스트 데이터를 새로 고칩니다. 오래된 테스트 데이터는 비현실적인 결과로 이어집니다. 데이터 모델이 변경되거나, 데이터 볼륨이 증가하거나, 사용자 인구 통계가 변화할 때마다 현재 프로덕션 데이터 특성을 반영하도록 테스트 데이터를 다시 생성합니다.

워크로드가 발전함에 따라 테스트 시나리오를 검토합니다. 시나리오에 실제 사용량이 계속 반영되도록 정기적인 검토를 예약합니다. 시나리오는 다음과 같이 오래됩니다.

  • 시간이 지남에 따라 사용자 동작이 바뀝니다.
  • 사용자 기반이 증가함에 따라 트래픽 패턴이 변경됨
  • 새로운 기능에는 다양한 사용 패턴이 도입되었습니다.
  • 새로운 용량 요구 사항을 충족하기 위한 인프라 확장

Azure 지원

Azure Pipelines 사용하면 성능 테스트를 CI/CD 파이프라인에 통합할 수 있습니다. 부하 테스트를 파이프라인의 한 단계로 추가하여 애플리케이션의 성능과 확장성의 유효성을 검사할 수 있습니다.

Azure Chaos Studio 제어된 오류 주입 실험을 실행할 수 있도록 애플리케이션에 실제 오류를 삽입하는 데 도움이 됩니다. 실험은 클라우드 애플리케이션 및 서비스 복원력을 측정, 이해 및 개선하는 데 도움이 됩니다.

Azure Load Testing 은 모든 애플리케이션에서 대규모 부하를 생성하는 부하 테스트 서비스입니다. 부하 테스트는 부하 테스트를 자동화하고 CI/CD(지속적인 통합 및 지속적인 업데이트) 워크플로에 통합하는 기능을 제공합니다. 평균 응답 시간 또는 오류 임계값과 같은 테스트 조건을 정의하고 특정 오류 조건에 따라 부하 테스트를 자동으로 중지할 수 있습니다. 부하 테스트는 부하 테스트 중에 Azure 애플리케이션 구성 요소의 라이브 업데이트 및 자세한 리소스 메트릭을 제공하는 대시보드를 제공합니다. 테스트 결과를 분석하고, 성능 병목 상태를 식별하고, 여러 테스트 실행을 비교하여 시간에 따른 성능 회귀를 이해할 수 있습니다.

Azure Monitor 클라우드 및 온-프레미스 환경에서 원격 분석을 수집, 분석 및 응답하기 위한 포괄적인 모니터링 솔루션입니다. Application Insights 는 APM 기능을 제공하는 모니터의 확장입니다. Application Insights를 사용하여 개발 및 테스트 중 및 프로덕션 환경에서도 애플리케이션을 모니터링할 수 있습니다.

성능 효율성 체크리스트

전체 권장 사항 집합을 참조하세요.