성능 효율성 원칙
성능 효율성은 워크로드가 효율적인 방식으로 사용자가 요구 사항에 맞게 조정하는 기능입니다. 이러한 원칙은 성능 효율성을 개선하기 위한 전반적인 전략을 안내하기 위한 것입니다.
가로 크기 조정을 위한 디자인
수평 크기 조정을 통해 탄력성을 사용할 수 있습니다. 인스턴스는 로드 변경에 따라 추가(스케일 아웃) 또는 제거(스케일 인)됩니다. 스케일 아웃하면 중복성을 구축하여 복원력을 향상시킬 수 있습니다. 스케일 인은 초과 용량을 종료하여 비용을 줄이는 데 도움이 될 수 있습니다.
접근 방식 | 이점 |
---|---|
비즈니스 요구 사항에 따라 용량 모델 정의 | 예측 및 임의 급증 및 부하 변동에 대한 제한을 테스트하여 애플리케이션의 크기를 조정할 수 있는지 확인합니다. 지역 오류가 있는 경우 애플리케이션이 예상대로 확장되도록 SKU 서비스 제한 및 지역 제한을 고려합니다. |
PaaS 제품 사용 | 사용자 지정 구현이 필요하고 오류가 발생하기 쉬운 수동 크기 조정 작업에 투자하는 대신 크기 조정 작업을 자동으로 트리거 하는 기본 제공 기능을 활용합니다. |
적절한 리소스 및 적절한 크기 선택 | 리소스가 예상 부하를 지원할 수 있는지 확인합니다. 또한 선택 항목의 비용 영향을 정당화합니다. |
디자인에 전략을 조기에 적용 | 중요한 변경 없이 채택을 가속화합니다. 예를 들어 상태 비저장 애플리케이션을 위해 노력하고 상태를 외부적으로 데이터베이스 또는 분산 캐시에 저장합니다. 가능한 경우 캐싱을 사용하여 처리 부하를 최소화합니다. |
다른 방법은 수직 크기 조정(스케일 업)입니다. 그러나 결국 더 큰 시스템이 없고 더 이상 확장할 수 없는 한계에 도달할 수 있습니다. 이 시점에서 추가 크기 조정은 수평적이어야 합니다. 따라서 초기에 스케일 아웃 아키텍처를 사용하는 것이 좋습니다.
성능 테스트 시 Shift-left
조기에 테스트하고 자주 테스트하여 문제를 조기에 catch합니다.
접근 방식 | 이점 |
---|---|
부하 및 스트레스 테스트 실행 | 미리 정해진 부하량으로 애플리케이션의 성능을 측정하고 애플리케이션 및 해당 인프라가 견딜 수 있는 최대 부하도 측정합니다. |
성능 기준 설정 | 애플리케이션 및 지원 인프라의 현재 효율성을 결정합니다. 부하가 악화되기 전에 병목 상태를 조기에 식별할 수 있습니다. 또한 이 전략은 개선 전략 으로 이어질 수 있으며 애플리케이션이 비즈니스 목표를 충족하는지 여부를 결정할 수 있습니다. |
CI(연속 통합) 빌드 파이프라인에서 테스트를 실행합니다. | 문제를 조기에 검색합니다. 코드베이스를 변경해도 성능에 부정적인 영향을 주지 않도록 모든 개발 노력은 지속적인 성능 테스트를 거쳐야 합니다. |
프로덕션의 성능을 지속적으로 모니터링
시스템을 전체적으로 관찰하여 솔루션의 전반적인 상태를 평가합니다. 개발/테스트 환경뿐만 아니라 프로덕션 환경에서도 테스트 결과를 캡처합니다. 프로덕션에서 모니터링 및 로깅은 병목 상태와 개선 기회를 식별하는 데 도움이 될 수 있습니다.
접근 방식 | 이점 |
---|---|
전체 솔루션의 상태 모니터링 | 인프라, 애플리케이션 및 종속 서비스의 확장성 및 복원력에 대해 알아봅니다. 주요 성능 카운터를 정기적으로 수집하고 검토합니다. |
반복 가능한 프로세스에서 데이터 캡처 | 시간이 지남에 따라 수요에 따라 자동 크기 조정을 허용하는 메트릭을 평가합니다. 안정성을 위해 사전 개입이 필요할 수 있는 조기 경고 신호를 찾습니다. |
워크로드의 요구 사항을 지속적으로 다시 평가 | 해결 계획을 사용하여 개선 기회를 식별합니다. 이러한 노력에는 보다 적합한 솔루션을 위해 업데이트된 구성 및 사용 중단이 필요할 수 있습니다. |
다음 섹션
이 검사 목록을 사용하여 성능 설계 관점에서 애플리케이션 아키텍처를 검토합니다.
관련 링크
성능 효율성은 전체 아키텍처 스펙트럼에 영향을 미치며 Microsoft Azure Well-Architected Framework의 다른 핵심 요소와 상호 관련됩니다.
Microsoft Azure Well-Architected 검토 도구를 사용하여 워크로드를 평가합니다.