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