안정성 디자인 원칙

클라우드에서 신뢰할 수 있는 애플리케이션을 구축하는 것은 기존 애플리케이션 개발과는 다릅니다. 과거에는 전체 애플리케이션 플랫폼이 실패할 가능성을 최소화하기 위해 고급 하드웨어를 중복해서 구매하곤 했습니다.

클라우드에서도 오류가 발생한다는 것을 인정합니다. 목표는 모든 장애를 막는 것이 아니라 단일 장애 구성 요소의 영향을 최소화하는 것입니다.

Microsoft Azure Well-Architected Framework의 원칙을 사용하여 워크로드를 평가하려면 Microsoft Azure Well-Architected 검토를 참조하세요.

다음 디자인 원칙은 다음 사항을 제공합니다.

이러한 중요 디자인 원칙은 Azure에 배포된 애플리케이션의 안정성을 평가하는 렌즈로 사용됩니다. 이러한 렌즈는 애플리케이션 평가 질문에 대한 프레임워크를 제공합니다.

비즈니스 요구 사항을 고려한 디자인

안정성은 주관적인 개념입니다. 애플리케이션의 안정성을 적절하게 높이려면 애플리케이션을 둘러싼 비즈니스 요구 사항을 반영해야 합니다.

예를 들어 SLA(서비스 수준 계약)가 99.999%인 중요 업무용 애플리케이션은 SLA가 95%인 다른 애플리케이션보다 높은 수준의 안정성을 요구합니다.

안정성과 가용성을 높이려면 비용 상승이 불가피합니다. 어떻게 절충할 것인지 신중하게 고려해야 합니다.

Azure처럼 고도로 분산된 다중 테넌트 환경에서 오류는 필연적으로 발생합니다.

개별 구성 요소부터 전체 Azure 지역까지 발생 가능한 오류를 예상하면 복원력 있는 방식으로 솔루션을 개발하여 안정성을 높일 수 있습니다.

애플리케이션 안정성에 영향을 주는 문제를 완화하려면 먼저 이러한 문제를 감지해야 합니다.

애플리케이션 운영을 정상 상태와 비교하여 모니터링하면 안정성 문제를 감지하고 예측할 수 있습니다.

모니터링을 통해 신속하게 수정 작업을 수행할 수 있습니다.

애플리케이션 가동 중지 시간의 주요 원인 중 하나는 충분히 테스트하지 않은 소프트웨어 배포 또는 구성 오류로 인한 인적 오류입니다.

인적 오류의 가능성과 결과를 최소화하려면 클라우드 솔루션의 모든 측면을 자동화하기 위해 노력하는 것이 중요합니다.

자동화는 다음을 향상합니다.

자가 복구는 시스템이 오류를 자동으로 처리하는 기능을 말합니다. 오류 처리는 미리 정의된 수정 프로토콜을 통해 발생합니다. 이러한 프로토콜은 솔루션 내의 오류 모드에 연결됩니다.

모니터링 및 자동화를 이용하는 높은 수준의 시스템 완성도가 필요한 고급 개념입니다.

자가 복구는 처음부터 안정성 극대화라는 목표를 위해 고안되었습니다.

스케일 아웃은 수평 확장을 통해 수요에 대응하는 시스템 기능에 초점을 맞춘 개념입니다. 트래픽이 증가하면 기존 리소스의 크기를 늘리는 대신 더 많은 리소스 단위가 병렬로 추가됩니다.

배율 단위를 통해 시스템은 전반적인 안정성에 필수적인 예상 트래픽 증가 및 예기치 않은 트래픽 증가를 처리할 수 있습니다.

배율 단위는 단일 리소스 오류의 영향을 더욱 줄입니다.