Azure Load Testing 및 Azure Chaos Studio를 사용한 지속적인 유효성 검사
클라우드 네이티브 애플리케이션 및 서비스가 더 복잡해짐에 따라 변경 내용과 새 릴리스를 배포하는 것은 어려울 수 있습니다. 오류 배포 또는 릴리스로 인해 중단이 자주 발생합니다. 그러나 배포 후 애플리케이션이 실제 트래픽을 수신하기 시작할 때, 특히 고도로 분산된 다중 테넌트 클라우드 환경에서 실행되고 여러 개발 팀에서 기본 있는 복잡한 워크로드에서도 오류가 발생할 수 있습니다. 이러한 환경에는 일반적으로 개발 프로세스 중에 테스트하기 어려운 재시도 논리 및 자동 크기 조정과 같은 더 많은 복원력 측정값이 필요합니다.
따라서 프로덕션 환경과 유사한 환경에서 지속적인 유효성 검사가 중요하므로 개발 주기 초기에 문제 또는 버그를 최대한 빨리 찾아서 해결할 수 있습니다. 워크로드 팀은 개발 프로세스 초기에 테스트하고(왼쪽 이동) 개발자가 프로덕션 환경에 가까운 환경에서 테스트를 편리하게 수행할 수 있도록 해야 합니다.
중요 업무용 워크로드의 고가용성 요구 사항은 각각 3, 4 또는 59(각각 99.9%, 99.99% 또는 99.999%)입니다. 이러한 목표를 달성하기 위해 엄격한 자동화된 테스트를 구현하는 것이 중요합니다.
연속 유효성 검사는 각 워크로드 및 아키텍처 특성에 따라 달라집니다. 이 문서에서는 Azure Load Testing 및 Azure Chaos Studio를 정규 개발 주기로 준비하고 통합하기 위한 가이드를 제공합니다.
1 – 예상 임계값에 따라 테스트 정의
지속적인 테스트는 적절한 준비가 필요한 복잡한 프로세스입니다. 테스트할 내용과 예상 결과는 명확해야 합니다.
성능 테스트 및 RE:08을 위한 권장 사항 PE:06 - 안정성 테스트 전략 설계를 위한 권장 사항 Azure Well-Architected Framework는 주요 시나리오, 종속성, 예상 사용량, 가용성, 성능 및 확장성 목표를 식별하여 시작하는 것이 좋습니다.
그런 다음 측정 가능한 임계값 집합을 정의하여 주요 시나리오의 예상 성능을 정량화해야 합니다.
팁
임계값의 예로는 예상 사용자 로그인 수, 지정된 API에 대한 초당 요청 수 및 백그라운드 프로세스에 대한 초당 작업이 포함됩니다.
임계값을 사용하여 애플리케이션에 대한 상태 모델을 개발해야 합니다. 테스트용 및 프로덕션 환경에서 애플리케이션을 운영하기 위한 것입니다.
다음으로, 값을 사용하여 애플리케이션 기준 성능을 테스트하고 예상 크기 조정 작업의 유효성을 검사하기 위한 실제 트래픽을 생성하는 부하 테스트를 정의합니다. 지속적인 인공 사용자 트래픽은 사전 프로덕션 환경에서 필요합니다. 사용이 없으면 런타임 문제를 밝히기 어렵기 때문입니다.
부하 테스트는 애플리케이션 또는 인프라에 대한 변경 내용이 문제를 일으키지 않고 시스템이 여전히 예상 성능 및 테스트 조건을 충족하는지 확인합니다. 테스트 조건을 충족하지 않는 실패한 테스트 실행은 기준을 조정해야 하거나 예기치 않은 오류가 발생했음을 나타냅니다.
자동화된 테스트는 일상적인 사용량을 나타내지만, 수동 부하 테스트를 정기적으로 실행하여 시스템이 예기치 않은 피크에 어떻게 반응하는지 확인해야 합니다.
지속적 유효성 검사의 두 번째 부분은 실패 주입(카오스 엔지니어링)입니다. 이 단계에서는 장애에 대한 응답 방식을 테스트하여 시스템의 복원력을 확인합니다. 또한 다시 시도 논리, 자동 크기 조정 등과 같은 모든 복원력 측정이 예상대로 작동하고 있습니다.
2 - 부하 테스트 및 Chaos Studio를 사용하여 유효성 검사 구현
Microsoft Azure는 부하 테스트 및 카오스 엔지니어링을 구현하기 위해 다음과 같은 관리되는 서비스를 제공합니다.
- Azure Load Testing은 애플리케이션 및 서비스에 가상 사용자 부하를 생성합니다.
- Azure Chaos Studio는 오류를 애플리케이션 구성 요소 및 인프라에 체계적으로 주입하여 카오스 실험을 수행 능력을 제공합니다.
Azure Portal을 통해 Chaos Studio 및 부하 테스트를 배포하고 구성할 수 있지만, 지속적인 유효성 검사의 컨텍스트에서 프로그래밍 방식과 자동화된 방식으로 테스트를 배포, 구성 및 실행할 API가 있어야 합니다. 이러한 두 도구를 함께 사용하면 시스템이 문제에 어떻게 반응하는지 관찰하고 인프라 또는 애플리케이션 오류에 대응하여 스스로 치유하는 기능을 관찰할 수 있습니다.
다음 동영상은 Azure DevOps에 통합된 Chaos 및 Load Testing의 결합된 구현을 보여 줍니다.
중요 업무용 워크로드를 개발하는 경우 Azure 중요 업무용 프로젝트 및 Azure Well-Architected Framework의 일부로 제공되는 참조 아키텍처, 자세한 지침, 샘플 구현 및 코드 아티팩트를 활용합니다.
중요 업무용 구현은 Terraform을 통해 부하 테스트 서비스를 배포하고 API를 통해 서비스와 상호 작용하는 PowerShell Core 래퍼 스크립트 컬렉션을 포함합니다. 이러한 스크립트는 배포 파이프라인에 직접 포함할 수 있습니다.
참조 구현의 한 가지 옵션은 개별(분기별) 개발 환경을 스핀업하는 데 사용되는 엔드투엔드(e2e) 파이프라인 내에서 직접 부하 테스트를 실행하는 것입니다.
파이프라인은 카오스 실험을 포함하거나 포함하지 않고(선택에 따라) 부하 테스트를 병렬로 자동 실행합니다.
참고 항목
부하 테스트 중에 카오스 실험을 실행하면 대기 시간이 길어지고 응답 시간이 길어지며 일시적으로 오류율이 높아질 수 있습니다. 카오스 실험이 없는 실행과 비교할 때 스케일 아웃 작업이 완료되거나 장애 조치(failover)가 완료될 때까지 더 높은 수치를 확인할 수 있습니다.
카오스 테스팅의 사용 설정 여부와 실험 선택에 따라 오류에 대한 허용 오차가 "정상" 상태와 "카오스" 상태에서 다를 수 있으므로 기준 정의가 달라질 수 있습니다.
3 – 임계값 조정 및 기준 설정
마지막으로, 일반 실행에 대한 부하 테스트 임계값을 조정하여 애플리케이션(여전히)이 예상된 성능을 제공하고 오류를 생성하지 않는지 확인합니다. 예상되는 오류율 급증과 일시적인 성능 저하를 허용하는 카오스 테스팅을 위한 별도의 기준을 마련합니다. 이 활동은 연속되며 정기적으로 반복되어야 합니다. 예를 들어, 새로운 기능을 도입한 후 서비스 SKU를 변경하는 등입니다.
Azure Load Testing 서비스는 테스트가 통과해야 하는 특정 조건을 지정할 수 있는 테스트 조건이라는 기본 제공 기능을 제공합니다. 이 기능을 사용하여 다양한 기준을 구현할 수 있습니다.
이 기능은 Azure Portal 및 부하 테스트 API를 통해 사용할 수 있으며 Azure 중요 업무용의 일부로 개발된 래퍼 스크립트는 JSON 기반 기준 정의를 전달하는 옵션을 제공합니다.
이러한 테스트를 CI/CD 파이프라인에 직접 통합하고 기능 개발 초기 단계에서 실행하는 것이 좋습니다. 예제는 Azure 중요 업무용 참조 구현의 샘플 구현을 참조하세요.
요약하면 복잡한 분산 시스템에서는 장애가 불가피하므로 장애를 처리할 수 있도록 솔루션을 설계(및 테스트)해야 합니다. 잘 설계된 프레임워크 중요 업무용 워크로드 지침 및 참조 구현은 매우 신뢰할 수 있는 애플리케이션을 설계하고 운영하여 Microsoft 클라우드에서 최대 가치를 도출하는 데 도움이 될 수 있습니다.
다음 단계
중요 업무용 워크로드에 대한 배포 및 테스트 디자인 영역을 검토합니다.