안정성 목표 정의에 대한 권장 사항
이 Power Platform Well-Architected Reliability 체크리스트 권장 사항에 적용:
| 제목:04 | 구성요소, 흐름, 전체 솔루션에 대한 안정성과 복구 목표를 정의하세요. 이상적인 상태를 달성하기 위해 협상하고, 합의를 얻고, 기대치를 설정하고, 조치를 취하는 목표를 시각화합니다. 정의된 목표를 사용하여 상태 모델을 구축합니다. 상태 모델은 정상, 저하, 비정상 상태를 정의합니다. |
|---|
이 가이드에서는 중요한 워크로드에 대한 가용성 및 복구 목표 메트릭을 정의하기 위한 권장 사항을 설명합니다. 신뢰성 목표는 비즈니스 이해 관계자와의 워크숍 실습을 통해 도출됩니다.
모니터링과 테스트를 통해 목표를 개선합니다. 내부 이해 관계자와 협력하여 신뢰성에 대한 현실적인 기대치를 설정하십시오. 또한 이 연습은 이해 관계자가 귀하의 건축 설계 선택을 지원하고 귀하가 합의한 목표를 가장 잘 충족하도록 설계하고 있음을 이해하는 데 도움이 됩니다.
Microsoft Power Platform은 대부분의 인프라 수준 가용성 및 안정성 문제를 처리합니다. 그러나 구축한 워크로드의 가용성은 공동 책임입니다. Microsoft높은 가용성에 대한 노력에도 불구하고 시스템 가동 중단 위험은 결코 0이 아니라는 점을 이해하는 것이 중요합니다.
비즈니스 요구 사항을 정량화하려면 다음 메트릭을 사용하는 것이 좋습니다.
| 용어 | 정의 |
|---|---|
| 서비스 수준 목표(SLO) | 구성 요소의 상태와 안정성 계층을 나타내는 백분율 목표입니다. 계층이 높을수록 구성 요소의 안정성이 높아집니다. 복합 SLO 는 전체 작업 부하의 집계된 목표를 나타내며 구성 요소 SLO를 설명합니다. |
| 서비스 수준 지표(SLI) | 서비스에서 발생하는 메트릭입니다. SLI 메트릭은 SLO 값을 수량화하기 위해 집계됩니다. |
| 서비스 수준 약정(SLA) | 서비스 제공자와 서비스 고객 간의 계약상의 합의입니다. 계약은 SLO를 정의합니다. 계약을 준수하지 못하면 서비스 공급자에 재정적 결과가 발생할 수 있습니다. |
| 평균 복구 시간(MTTR) | 오류가 감지된 후 구성 요소를 복원하는 데 걸리는 시간입니다. |
| 평균 실패 간격(MTBF) | 워크로드가 실패할 때까지 중단 없이 예상되는 기능을 수행할 수 있는 기간입니다. |
| 복구 시간 목표(RTO) | 인시던트 발생 후 애플리케이션을 사용할 수 없는 최대 허용 시간입니다. |
| 복구 지점 목표(RPO) | 인시던트 발생 시 허용되는 최대 데이터 손실 기간입니다. |
사용자 및 시스템 흐름의 맥락에서 이러한 메트릭에 대한 워크로드의 목표 값을 정의합니다. 귀하의 요구 사항에 얼마나 중요한지에 따라 해당 흐름을 식별하고 점수를 매겨보세요. 이 값을 사용하여 아키텍처, 검토, 테스트 및 사고 관리 작업 측면에서 워크로드 설계를 추진합니다. 목표를 달성하지 못하면 허용 수준을 넘어서 비즈니스에 영향을 미칩니다.
주요 디자인 전략
기술적인 논의가 중요한 흐름에 대한 안정성 목표를 정의하는 방법을 결정해서는 안 됩니다. 대신, 비즈니스 이해 관계자는 자신의 요구 사항과 워크로드 최종 사용자의 기대에 집중해야 합니다. 기술 전문가는 이해 관계자가 이러한 요구 사항을 충족하는 현실적인 수치 값을 할당하도록 돕습니다. 기술 전문가는 정보를 교환함으로써 실현 가능한 SLO에 대한 논의와 합의를 가능하게 합니다.
요구 사항을 측정 가능한 수치 값에 매핑하는 방법의 예를 고려해보세요. 이해 관계자는 중요한 사용자 흐름의 경우 정규 업무 시간 동안 한 시간의 가동 중지 시간이 발생하면 월 수익에서 X 달러의 손실이 발생할 것으로 추정합니다. 해당 달러 금액은 가용성 SLO가 99.9%가 아닌 99.95%인 흐름을 설계하는 데 드는 예상 비용과 비교됩니다. 의사 결정자는 수익 손실 위험이 이를 방지하는 데 필요한 추가 비용 및 관리 부담보다 더 큰지 논의해야 합니다.
흐름을 검사하고 전체 대상 목록을 작성할 때 이 패턴을 따르세요.
안정성 목표는 성능 목표와 다르다는 점을 기억하세요. 안정성 목표는 가용성과 복구에 중점을 둡니다. 안정성 목표를 설정하려면 먼저 가장 광범위한 요구 사항을 정의한 다음 높은 수준의 요구 사항을 충족하기 위해 보다 구체적인 메트릭을 정의하세요.
최고 수준의 안정성 및 복구 요구 사항과 상관 메트릭에는 예를 들어 모든 지역에 대해 99.9%의 애플리케이션 가용성 또는 미주 지역에 대해 5시간의 목표 RTO가 포함될 수 있습니다. 이러한 유형의 대상을 정의하면 해당 대상과 관련된 중요한 흐름을 식별하는 데 도움이 됩니다. 그런 다음 구성 요소 수준 목표를 고려할 수 있습니다.
가용성 메트릭
가용성 목표는 SLO, SLA 및 SLI 메트릭에 해당합니다.
SLO 및 SLA
가용성 메트릭은 SLA를 정의하는 데 사용하는 SLO와 상관 관계가 있습니다. 워크로드 SLO는 특정 기간 동안 허용할 수 있는 가동 중지 시간을 결정합니다. 예를 들어 한 달에 1시간 미만입니다. SLO 목표를 충족할 수 있는지 확인하려면 각 구성 요소의 SLA를 검토하세요. Microsoft
SLO를 설정하려면 다음 사항을 고려하세요.
향후 1~2년 동안 워크로드의 비기능적 요구 사항(예: 최대 요청 비율, 동시 사용자)
특정 기간 동안 측정할 수 있는 항목에 대한 사용 가능한 메트릭입니다. 이 데이터는 어떤 SLI를 지정해야 하는지 알려줍니다.
개별 워크로드 구성 요소에 대한 SLA를 수집한 후 복합 SLA를 계산합니다. 복합 SLA는 워크로드의 대상 SLO와 일치해야 합니다. 복합 SLA를 계산하는 데는 아키텍처 설계에 따라 여러 요소가 관련됩니다.
적절한 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를 구축할 때 이러한 차이점을 고려하십시오. 중요하지 않은 흐름에는 잠시 사용할 수 없는 경우 고객 경험에 영향을 주지 않으므로 계산에서 생략해야 하는 구성 요소가 있을 수 있습니다.
SLI
SLI를 SLO에 기여하는 구성 요소 수준 메트릭으로 생각하세요. 가장 중요한 SLI는 고객의 관점에서 중요한 흐름에 영향을 미치는 SLI입니다. 많은 흐름에서 SLI에는 지연 시간, 처리량, 오류율, 가용성이 포함됩니다. 좋은 SLI는 SLO가 위반될 위험이 있는 시기를 식별하는 데 도움이 됩니다. 가능하면 SLI를 특정 고객과 연관시키세요.
쓸모 없는 메트릭 수집을 방지하려면 각 흐름의 SLI 수를 제한하세요. 가능하다면 흐름당 SLI 3개를 목표로 하세요.
복구 메트릭
복구 목표는 RTO, RPO, MTTR 및 MTBF 메트릭에 해당합니다. 가용성 목표와 달리 이러한 측정에 대한 복구 목표는 SLA에 크게 의존하지 않습니다. Microsoft Microsoft SQL Database와 같은 일부 제품에 대해서만 RTO 및 RPO 보장을 게시합니다.
현실적인 복구 목표에 대한 정의는 실패 모드 분석과 비즈니스 연속성 및 재해 복구에 대한 계획 및 테스트에 따라 달라집니다. 이 작업을 완료하기 전에 이해 관계자들과 희망적인 목표에 대해 논의하고 아키텍처 설계가 이해하는 한도 내에서 복구 목표를 지원하는지 확인하십시오. 복구 메트릭에 대해 철저하게 테스트되지 않은 워크로드 부분에는 SLA가 보장되어서는 안 된다는 점을 이해 관계자에게 명확하게 전달합니다. 시간이 지나면서 워크로드가 업데이트됨에 따라 복구 목표가 변경될 수 있다는 점을 이해 관계자가 이해하도록 해야 합니다. 사용자 경험을 개선하기 위해 새로운 기술을 채택하면 워크로드가 더욱 복잡해질 수 있습니다. 이러한 변경으로 인해 복구 메트릭이 늘어나거나 줄어들 수 있습니다.
참고
MTBF는 정의하고 보장하기 어려울 수 있습니다. PaaS(Platform as a Service) 또는 SaaS(Software as a Service)는 클라우드 공급자의 알림 없이 장애 및 복구가 가능하며 프로세스가 완전히 투명할 수 있습니다. 이 메트릭에 대한 목표를 정의하는 경우 제어할 수 있는 구성 요소만 포함하십시오.
상태 모델 빌드
안정성 목표를 위해 수집한 데이터를 사용하여 각 워크로드 및 관련 중요 흐름에 대한 상태 모델을 빌드합니다. 상태 모델은 흐름 및 워크로드에 대해 정상, 저하 및 비정상* 상태를 정의합니다. 상태는 적절한 운영 우선 순위를 보장합니다. 이 모델은 신호등 모델이라고도 합니다. 모델은 정상을 녹색으로, 저하를 노란색으로, 비정상을 빨간색으로 지정합니다. 상태 모델을 사용하면 흐름 상태가 정상에서 성능 저하 또는 비정상으로 변경되는 시기를 알 수 있습니다.
정상, 저하 및 비정상 상태를 정의하는 방법은 안정성 목표에 따라 다릅니다. 다음은 상태를 정의할 수 있는 방법의 몇 가지 예입니다.
녹색 또는 정상 상태는 주요 비기능 요구 사항과 목표가 완전히 충족되었으며 리소스가 최적으로 사용되었음을 나타냅니다.
노란색 또는 성능 저하 상태는 흐름의 하나 이상의 구성 요소가 정의된 임계값에 대해 경고하고 있지만 흐름이 작동 중임을 나타냅니다. 예를 들어 스토리지 제한이 감지되었습니다.
빨간색 또는 비정상 상태는 성능 저하가 안정성 목표에서 허용하는 것보다 오래 지속되었거나 흐름을 사용할 수 없음을 나타냅니다.
참고
상태 모델은 모든 오류를 동일하게 처리해서는 안 됩니다. 상태 모델은 일시적 오류와 비일시적 오류를 구분해야 합니다. 예상된 일시적이지만 복구 가능한 오류와 실제 재해 상태를 명확하게 구분해야 합니다.
이 모델은 지속적인 개선 원칙에 따라 개발 및 운영되는 모니터링 및 경고 전략을 사용하여 작동합니다. 워크로드가 발전함에 따라 상태 모델도 함께 발전해야 합니다.
모니터링 및 알림 구성에 대한 자세한 지침은 상태 모니터링 가이드를 참조하세요.
시각화
운영 팀과 워크로드 이해 관계자에게 워크로드 상태 모델의 실시간 상태와 전반적인 추세에 대한 정보를 제공하려면 모니터링 솔루션에 대시보드를 만드는 것을 고려하세요. 이해 관계자와 시각화 솔루션에 대해 논의하여 그들이 가치 있고 소비하기 쉬운 정보를 제공할 수 있도록 하세요. 또한 매주, 매월 또는 분기별로 생성된 보고서를 보고 싶어할 수도 있습니다.
Power Platform 간편 사용
Power Platform SLA는 가동 시간과 연결성에 대한 약속을 제공합니다. Microsoft 서비스마다 SLA가 다르며, 서비스 내의 SKU에 SLA가 다른 경우도 있습니다. 자세한 내용은 온라인 서비스용 서비스 수준 약정을 참조하십시오.
Power Platform SLA에는 SLA가 충족되지 않을 경우 서비스 크레딧을 얻기 위한 절차와 각 서비스의 가용성 정의가 포함되어 있습니다. SLA의 해당 측면은 시행 정책의 역할을 합니다.
Microsoft 비즈니스 애플리케이션은 Dynamics 365와 SaaS 애플리케이션의 모든 생산 유형 환경에 비즈니스 연속성 및 재해 복구(BCDR) 기능을 제공합니다. Power Platform 지역적 중단 중에도 프로덕션 데이터의 복원력을 보장하는 방법 Microsoft 을 알아보세요.
조직 정렬
클라우드 채택 프레임워크는 조직 전체의 모니터링과 관련된 SLO 및 SLI에 대한 권장 사항에 대한 지침을 제공합니다.
자세한 내용은 클라우드 모니터링 SLO를 참조하세요.
안정성 체크리스트
전체 권장 사항 세트를 참조하세요.