안정성 대상을 정의하기 위한 권장 사항

이 Azure Well-Architected Framework 안정성 검사 목록 권장 사항에 적용됩니다.

RE:04	구성 요소, 흐름 및 전체 솔루션에 대한 안정성 및 복구 대상을 정의합니다. 목표를 시각화하여 이상적인 상태를 달성하기 위해 협상하고, 합의를 도출하고, 기대치를 설정하고, 작업을 추진합니다. 정의된 대상을 사용하여 상태 모델을 빌드합니다. 상태 모델은 정상 상태, 성능 저하 및 비정상 상태를 정의합니다.

이 가이드에서는 중요한 워크로드 및 흐름에 대한 가용성 및 복구 대상 메트릭을 정의하기 위한 권장 사항을 설명합니다. 안정성 목표는 비즈니스 관련자와의 워크샵 연습을 통해 파생됩니다. 대상은 모니터링 및 테스트를 통해 구체화됩니다.

내부 이해 관계자와 함께 관련자가 계약 계약을 통해 고객에게 이러한 기대치를 전달할 수 있도록 워크로드 안정성에 대한 현실적인 기대치를 설정합니다. 또한 현실적인 기대는 이해 관계자가 아키텍처 디자인 결정을 이해하고 지원하며, 사용자가 동의한 목표를 최적으로 충족하도록 설계하고 있음을 알 수 있도록 도와줍니다.

다음 메트릭을 사용하여 비즈니스 요구 사항을 정량화하는 것이 좋습니다.

용어	정의
SLO(서비스 수준 목표)	구성 요소 및 안정성 계층의 상태를 나타내는 백분율 대상입니다. 계층이 높을수록 구성 요소의 안정성이 높아집니다. 복합 SLO 는 전체 워크로드의 집계 대상을 나타내며 구성 요소 SLO에 대한 계정을 나타냅니다.
SLI(서비스 수준 표시기)	서비스에서 내보낸 메트릭입니다. SLI 메트릭은 SLO 값을 정량화하기 위해 집계됩니다.
SLA(서비스 수준 계약)	서비스 공급자와 서비스 고객 간의 계약 계약입니다. 규약은 SLO를 정의합니다. 계약을 충족하지 못하면 서비스 공급자에게 재정적인 결과가 발생할 수 있습니다.
평균 복구 시간(MTTR)	오류가 검색된 후 구성 요소를 복원하는 데 걸린 시간입니다.
실패 사이의 평균 시간(MTBF)	워크로드가 실패할 때까지 중단 없이 예상 함수를 수행할 수 있는 기간입니다.
복구 시간 목표(RTO)	인시던트 후 애플리케이션 중단이 허용되는 최대 시간입니다.
복구 지점 목표(RPO)	인시던트 중 허용되는 최대 데이터 손실 기간입니다.

사용자 흐름 및 시스템 흐름의 컨텍스트에서 이러한 메트릭에 대한 워크로드의 대상 값을 정의합니다. 요구 사항에 얼마나 중요한지 기준으로 이러한 흐름을 식별하고 점수를 매기세요. 값을 사용하여 아키텍처, 검토, 테스트 및 인시던트 관리 작업 측면에서 워크로드 디자인을 추진합니다. 목표를 충족하지 못하면 허용 오차 수준을 초과하는 비즈니스에 영향을 줍니다.

주요 디자인 전략

기술 토론은 중요한 흐름에 대한 안정성 목표를 정의하는 방법을 추진해서는 안 됩니다. 대신 비즈니스 관련자는 워크로드의 요구 사항을 정의할 때 고객에 집중해야 합니다. 기술 전문가는 관련자가 이러한 요구 사항과 상관 관계가 있는 현실적인 숫자 값을 할당할 수 있도록 지원합니다. 기술 전문가는 지식을 공유하면서 현실적인 SLO에 대한 협상 및 상호 합의를 허용합니다.

요구 사항을 측정 가능한 숫자 값에 매핑하는 방법의 예를 생각해 보세요. 관련자는 중요한 사용자 흐름의 경우 정기적인 업무 시간 동안 1시간의 가동 중지 시간으로 인해 월별 수익이 X 달러 손실되는 것으로 추정합니다. 해당 달러 금액은 가용성 SLO가 99.9%가 아닌 99.95%인 흐름을 설계하는 예상 비용과 비교됩니다. 의사 결정자는 해당 수익 손실의 위험이 이를 보호하는 데 필요한 추가 비용 및 관리 부담보다 더 큰지 여부를 논의해야 합니다. 흐름을 검사하고 전체 대상 목록을 작성할 때 이 패턴을 따릅니다.

안정성 목표는 성능 목표와 다릅니다. 안정성 대상은 가용성 및 복구에 중점을 줍니다. 안정성 목표를 설정하려면 가장 광범위한 요구 사항을 정의한 다음 상위 수준 요구 사항을 충족하도록 보다 구체적인 메트릭을 정의합니다.

가장 높은 수준의 안정성 및 복구 요구 사항 및 상관 관계 메트릭에는 예를 들어 모든 지역에 대해 99.9%의 애플리케이션 가용성 또는 미주 지역의 경우 5시간의 대상 RTO가 포함될 수 있습니다. 이러한 유형의 대상을 정의하면 해당 대상에 관련된 중요한 흐름을 식별하는 데 도움이 됩니다. 그런 다음 구성 요소 수준 대상을 고려할 수 있습니다.

절충: 워크로드 구성 요소의 기술적 제한 사항과 비즈니스에 대한 의미(예: 초당 메가비트의 처리량과 초당 트랜잭션 수) 사이에 개념적 차이가 있을 수 있습니다. 이러한 두 보기 간에 모델을 만드는 것은 어려울 수 있습니다. 솔루션을 과도하게 사용하는 대신 경제적이지만 의미 있는 방식으로 접근하려고 합니다.

가용성 메트릭

SLO 및 SLA

가용성 메트릭은 SLA를 정의하는 데 사용하는 SLO와 상관 관계가 있습니다. 워크로드 SLO는 지정된 기간(예: 매월 1시간 미만)에 허용되는 가동 중지 시간을 결정합니다. SLO 대상을 충족할 수 있는지 확인하려면 각 구성 요소에 대한 Microsoft SLA를 검토합니다. 높은 SLA를 충족하는 데 필요한 중복성에 주의하세요. 예를 들어 Microsoft는 단일 지역 배포에 대해 보장하는 것보다 Azure Cosmos DB의 다중 지역 배포에 대해 더 높은 SLA를 보장합니다.

참고

Azure SLA가 서비스의 모든 측면을 항상 다루지는 않습니다. 예를 들어 Azure Application Gateway 가용성 SLA가 있지만 Azure Web Application Firewall 기능은 악의적인 트래픽이 통과하지 못하도록 보장하지 않습니다. SLA 및 SLO를 개발할 때 이 제한을 고려합니다.

개별 워크로드 구성 요소에 대한 SLA를 수집한 후 복합 SLA를 계산합니다. 복합 SLA는 워크로드의 대상 SLO와 일치해야 합니다. 복합 SLA를 계산하려면 아키텍처 디자인에 따라 몇 가지 요소가 포함됩니다. 다음 예제를 고려해 보세요.

참고

다음 예제의 SLA 값은 가상 이며 데모용으로만 사용됩니다. Microsoft 에서 지원하는 현재 값을 나타내기 위한 것이 아닙니다 .

복합 SLA에는 가용성 수준이 다른 애플리케이션을 지원하는 여러 서비스가 포함됩니다. 예를 들어 Azure SQL Database에 쓰는 Azure App Service 웹앱을 고려해 보세요. 가설적으로 이러한 SLA는 다음과 같습니다.

• App Service 웹앱 = 99.95%
• SQL Database = 99.99%

이 애플리케이션에 대해 예상할 수 있는 최대 가동 중지 시간은 어떻게 됩니까? 서비스 중 하나가 중단되면 전체 애플리케이션이 중단됩니다. 각 서비스 실패 확률은 독립적이므로 이 애플리케이션의 복합 SLA는 99.95%× 99.99% = 99.94%입니다. 이 값은 개별 SLA보다 낮습니다. 여러 서비스에 의존하는 애플리케이션에 더 많은 잠재적인 실패 지점이 있기 때문에 이 결론은 놀라운 일이 아닙니다.

독립적인 대체 경로를 만들면 복합 SLA를 높일 수 있습니다. 예를 들어 SQL Database를 사용할 수 없으면 트랜잭션을 큐에 배치하여 나중에 처리할 수 있습니다.

이 디자인에서는 데이터베이스에 연결할 수 없는 경우에도 애플리케이션을 계속 사용할 수 있습니다. 그러나 데이터베이스와 큐가 동시에 실패하면 실패합니다. 동시 실패에 대한 예상 시간 비율은 0.0001 × 0.001이므로 이 결합된 경로에 대한 복합 SLA는 다음과 같습니다.

데이터베이스 또는 큐 = 1.0 - (0.0001 × 0.001) = 99.999999%

총 복합 SLA:

웹앱 및 (데이터베이스 또는 큐) = 99.95% × 99.99999% = ~99.95%

이 접근 방식은 다음과 같은 절충을 야기합니다.

• 애플리케이션 논리는 더 복잡합니다.
• 큐에 대한 요금을 지불합니다.
• 데이터 일관성 문제를 고려해야 합니다.

다중 지역 배포의 경우 복합 SLA는 다음과 같이 계산됩니다.

• N 은 한 지역에 배포된 애플리케이션의 복합 SLA입니다.

• R은 애플리케이션이 배포된 지역의 수입니다.

모든 지역에서 동시에 애플리케이션 장애가 발생할 확률은 ((1 − N) ^ R)입니다. 예를 들어 가상 단일 지역 SLA가 99.95%인 경우:

• 두 지역에 대한 결합된 SLA = (1 - (1 - 0.9995) ^ 2) = 99.999975%

• 4개 지역에 대한 결합된 SLA = (1 - (1 - 0.9995) ^ 4) = 99.9999999%

적절한 SLO를 정의하려면 시간과 신중한 고려가 필요합니다. 비즈니스 관련자는 주요 고객이 앱을 사용하는 방법을 이해해야 합니다. 또한 안정성 허용 오차를 이해해야 합니다. 이 피드백은 대상에게 알려야 합니다.

SLA 값

다음 표에서는 일반적인 SLA 값을 정의합니다.

SLA	주간 가동 중지 시간	월간 가동 중지 시간	연간 가동 중지 시간
99%	1.68시간	7.2시간	3.65일
99.9%	10.1분	43.2분	8.76시간
99.95%	5분	21.6분	4.38시간
99.99%	1.01분	4.32분	52.56분
99.999%	6초	25.9초	5.26분

흐름 컨텍스트에서 복합 SLA를 생각할 때는 흐름에 따라 중요도 정의가 다릅니다. 복합 SLA를 빌드할 때 이러한 차이점을 고려합니다. 비임계 흐름에는 잠시 사용할 수 없는 경우 고객 환경에 영향을 주지 않으므로 계산에서 생략해야 하는 구성 요소가 있을 수 있습니다.

참고

고객 지향 워크로드 및 내부 사용 워크로드에는 서로 다른 SLO가 있습니다. 일반적으로 내부 사용 워크로드는 고객 관련 워크로드보다 훨씬 덜 제한적인 가용성 SLO를 가질 수 있습니다.

SLA

SLO를 SLO에 기여하는 구성 요소 수준 메트릭으로 간주합니다. 가장 중요한 SLA는 고객의 관점에서 중요한 흐름에 영향을 주는 SLA입니다. 많은 흐름의 경우 SLA에는 대기 시간, 처리량, 오류율 및 가용성이 포함됩니다. 좋은 SLI는 SLO가 위반될 위험이 있는 시기를 식별하는 데 도움이 됩니다. 가능한 경우 SLI를 특정 고객과 상호 연결합니다.

쓸모없는 메트릭을 수집하지 않도록 하려면 각 흐름에 대한 SLA 수를 제한합니다. 가능한 경우 흐름당 3개의 SLA를 목표로 합니다.

복구 메트릭

복구 대상은 RTO, RPO, MTTR 및 MTBF 메트릭에 해당합니다. 가용성 목표와 달리 이러한 측정에 대한 복구 대상은 Microsoft SLA에 크게 의존하지 않습니다. Microsoft는 SQL Database 같은 일부 제품에 대해서만 RTO 및 RPO 보증을 게시합니다.

현실적인 복구 대상에 대한 정의는 실패 모드 분석 과 비즈니스 연속성 및 재해 복구를 위한 계획 및 테스트에 의존합니다. 이 작업을 완료하기 전에 관련자와 포부 목표를 논의하고 아키텍처 디자인이 가장 잘 이해할 수 있도록 복구 대상을 지원하는지 확인합니다. 복구 메트릭에 대해 철저히 테스트되지 않은 흐름 또는 전체 워크로드가 SLA를 보장해서는 안 된다는 것을 이해 관계자에게 명확하게 전달합니다. 관련자가 워크로드가 업데이트되면 시간이 지남에 따라 복구 대상이 변경된다는 것을 이해해야 합니다. 고객이 추가되거나 고객 환경을 개선하기 위해 새로운 기술을 채택함에 따라 워크로드가 더 복잡해질 수 있습니다. 이러한 변경은 복구 메트릭을 늘리거나 줄일 수 있습니다.

참고

MTBF는 정의하고 보장하기 어려울 수 있습니다. PaaS(Platform as a Service) 또는 SaaS(Software as a Service)는 클라우드 공급자의 알림 없이 실패하고 복구할 수 있으며 프로세스는 사용자 또는 고객에게 완전히 투명할 수 있습니다. 이 메트릭에 대한 대상을 정의하는 경우 사용자가 제어하는 구성 요소만 다룹니다.

복구 대상을 정의할 때 복구를 시작하기 위한 임계값을 정의합니다. 예를 들어 웹 노드를 5분 이상 사용할 수 없는 경우 새 노드가 풀에 자동으로 추가됩니다. 다른 구성 요소 및 종속성에 미치는 영향을 포함하여 특정 구성 요소에 대한 복구와 관련된 항목을 고려하여 모든 구성 요소에 대한 임계값을 정의합니다. 또한 임계값은 일시적인 오류를 고려하여 복구 작업을 너무 빨리 시작하지 않도록 해야 합니다. 고객에 대한 데이터 손실 또는 세션 중단과 같은 복구 작업의 잠재적 위험을 관련자와 문서화하고 공유합니다.

상태 모델 빌드

안정성 목표에 대해 수집한 데이터를 사용하여 각 워크로드 및 관련 중요 흐름에 대한 상태 모델을 빌드합니다. 상태 모델은 흐름 및 워크로드에 대한 정상, 성능 저하 및 비정상 상태를 정의합니다. 상태는 적절한 운영 우선 순위를 보장합니다. 이 모델을 신호등 모델이라고도 합니다. 모델은 정상을 위해 녹색, 저하된 경우 노란색, 비정상인 경우 빨간색을 할당합니다. 상태 모델은 흐름의 상태가 정상에서 성능 저하 또는 비정상으로 변경되는 시기를 알 수 있도록 합니다.

정상, 성능 저하 및 비정상 상태를 정의하는 방법은 안정성 목표에 따라 달라집니다. 다음은 상태를 정의할 수 있는 방법의 몇 가지 예입니다.

• 녹색 또는 정상 상태는 주요 비기능 요구 사항 및 대상이 완전히 충족되고 리소스가 최적으로 사용됨을 나타냅니다. 예를 들어 요청의 95%는 AKS(Azure Kubernetes Service) 노드 사용이 X%인 =500ms로 처리<됩니다.

• 노란색 또는 성능 저하 상태는 흐름의 하나 이상의 구성 요소가 정의된 임계값에 대해 경고하지만 흐름이 작동 중임을 나타냅니다. 예를 들어 스토리지 제한이 검색되었습니다.

• 빨간색 또는 비정상 상태는 성능 저하가 안정성 대상에서 허용하는 것보다 오래 지속되었거나 흐름을 사용할 수 없게 되었음을 나타냅니다.

참고

상태 모델은 모든 오류를 동일하게 처리해서는 안 됩니다. 상태 모델은 일시적 오류와 비 정상 오류를 구분해야 합니다. 예측되는 일시적 오류이지만 복구 가능한 오류와 실제 재해 상태를 명확하게 구분해야 합니다.

이 모델은 지속적인 개선 원칙에 따라 개발 및 작동하는 모니터링 및 경고 전략을 사용하여 작동합니다. 워크로드가 발전함에 따라 상태 모델은 함께 진화해야 합니다.

계층화된 애플리케이션 상태 모델에 대한 자세한 디자인 고려 사항 및 권장 사항은 중요 업무용 워크로드 디자인 영역에서 찾은 상태 모델링 지침을 참조하세요. 모니터링 및 경고 구성에 대한 자세한 지침은 상태 모니터링 가이드를 참조하세요.

시각화

운영 팀과 워크로드 관련자에게 워크로드 상태 모델의 실시간 상태 및 전반적인 추세에 대한 정보를 유지하려면 모니터링 솔루션에서 대시보드를 만드는 것이 좋습니다. 이해 관계자와 시각화 솔루션을 논의하여 가치 있고 사용하기 쉬운 정보를 제공할 수 있도록 합니다. 또한 생성된 보고서를 매주, 매월 또는 분기별로 보고 싶을 수도 있습니다.

Azure 촉진

Azure SLA는 가동 시간 및 연결에 대한 Microsoft 약정을 제공합니다. 서비스에 따라 SLA가 다르고 서비스 내의 SKU에 다른 SLA가 있는 경우도 있습니다. 자세한 내용은 온라인 서비스 대한 서비스 수준 계약을 참조하세요.

Azure SLA에는 SLA가 충족되지 않는 경우 서비스 크레딧을 얻는 절차와 각 서비스의 가용성 정의가 포함되어 있습니다. SLA의 이러한 측면은 적용 정책의 역할을 합니다.

조직 맞춤

클라우드 채택 프레임워크 organization 모니터링과 관련된 SLO 및 SLA에 대한 권장 사항에 대한 지침을 제공합니다.

자세한 내용은 클라우드 모니터링 SLO를 참조하세요.

관련 링크

• 상태 모델링을 위한 Well-Architected Framework 중요 업무용 지침: Azure에서 중요 업무용 워크로드의 상태 모델링 및 가시성

안정성 검사 목록

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

안정성 검사 목록