안정성 대상을 정의하기 위한 권장 사항
이 Azure 잘 설계된 프레임워크 안정성 검사 목록 권장 사항에 적용됩니다.
RE:04 | 구성 요소, 흐름 및 전체 솔루션에 대한 안정성 및 복구 대상을 정의합니다. 목표를 시각화하여 이상적인 상태를 달성하기 위해 협상하고, 합의를 도출하고, 기대치를 설정하고, 작업을 추진합니다. 정의된 대상을 사용하여 상태 모델을 빌드합니다. 상태 모델은 정상 상태, 성능 저하 및 비정상 상태를 정의합니다. |
---|
이 가이드에서는 중요한 워크로드 및 흐름에 대한 가용성 및 복구 대상 메트릭을 정의하기 위한 권장 사항을 설명합니다. 비즈니스 관련자와 워크샵 연습에서 안정성 목표를 도출해야 합니다. 그런 다음 워크로드를 모니터링하고 테스트하여 해당 대상을 구체화합니다.
워크로드 안정성에 대한 내부 이해 관계자와 현실적인 기대치를 설정합니다. 그런 다음 계약 계약을 사용하여 이러한 기대치를 고객에게 전달할 수 있습니다. 또한 현실적인 기대는 이해 관계자가 아키텍처 설계 결정을 이해하고 지원하며, 사용자가 동의한 목표를 최적으로 충족하도록 설계하고 있음을 알 수 있도록 도와줍니다.
다음 메트릭을 사용하여 비즈니스 요구 사항을 정량화하는 것이 좋습니다.
용어 | 정의 |
---|---|
SLO(서비스 수준 목표) | 워크로드 또는 애플리케이션의 성능 및 안정성 측정값입니다. SLO는 특정 고객 상호 작용에 대해 설정한 측정 가능한 특정 대상입니다. 고객이 예상하는 서비스 품질에 따라 워크로드 또는 애플리케이션에 대해 설정하는 대상입니다. |
SLI(서비스 수준 표시기) | 서비스 성능의 특정 측면을 정량적으로 측정합니다. SLI를 사용하여 워크로드의 SLO 준수를 측정할 수 있습니다. |
SLA(서비스 수준 계약) | 서비스 공급자와 서비스 고객 간의 계약 계약입니다. 계약을 충족하지 못하면 서비스 공급자에게 재정적인 결과가 발생할 수 있습니다. |
MTTR(평균 복구 시간) | 오류가 감지된 후 구성 요소를 복원하는 데 걸린 시간입니다. |
실패 간 평균 시간(MTBF) | 워크로드가 실패할 때까지 중단 없이 예상 함수를 수행할 수 있는 기간입니다. |
RTO(복구 시간 목표) | 인시던트 후 애플리케이션을 사용할 수 없는 최대 허용 시간입니다. |
복구 지점 목표(RPO) | 인시던트 중에 허용되는 최대 데이터 손실 기간입니다. |
주요 디자인 전략
안정성 목표는 사용자 및 비즈니스 관련자에게 약속된 대로 워크로드 의 원하는 품질 목표를 나타냅니다. 이 목표에는 워크로드의 가용성과 복구 가능성이 모두 포함됩니다. 안정성 대상은 성능 목표와 다르지만 안정성 대상에 성능 목표를 포함해야 합니다. 다음 안정성 목표를 고려합니다.
가용성 대상은 시스템의 품질 표준을 정의하여 접근성과 기능을 유지합니다. 이러한 표준을 충족하지 않는 경우 시스템은 신뢰할 수 없는 것으로 간주됩니다. SLO를 사용하여 시스템이 이러한 표준을 충족하는지 여부를 확인합니다. 비즈니스 및 기술 관련자는 협업하여 현실적인 SLO를 설정하고 비교 분석, 사용자 환경 및 워크로드 프로필과 같은 요소를 고려합니다.
정확성 대상은 워크로드가 일관된 품질로 해당 기능을 제대로 수행하도록 합니다. 정확성을 측정하려면 워크로드의 지표를 수량화하여 통합된 목표 점수로 결합할 수 있습니다.
복구 대상은 RTO, RPO, MTTR 및 MTBF 메트릭에 해당하며, 이는 비즈니스 연속성 및 재해 복구를 위한 계획 및 테스트의 효율성을 정량화합니다.
안정성 목표를 설정하기 위해 비즈니스 관련자는 광범위한 요구 사항을 정의합니다. 그런 다음 기술 전문가는 워크로드의 현재 상태를 평가하고 모니터링 및 경고를 통해 목표를 달성하고 유지 관리하기 위해 노력합니다. 양측은 현실적인 목표에 동의해야 합니다.
비즈니스 요구 사항에 대한 중요도에 따라 사용자 및 시스템 흐름을 식별하고 점수를 매깁니다. 이러한 점수를 사용하여 워크로드의 디자인, 검토, 테스트 및 인시던트 관리를 안내합니다. 이러한 흐름에 대한 안정성 목표를 설정하고 이러한 목표를 충족하지 못하면 비즈니스에 큰 영향을 줄 수 있음을 이해합니다.
절충: 처리량과 초당 트랜잭션과 같이 시스템의 기술적 제한과 비즈니스 영향 사이에 차이가 있을 수 있습니다. 이 격차를 해소하는 것은 어려울 수 있습니다. 과도하게 작업하는 대신 실용적이고 비용 효율적인 솔루션을 목표로 합니다.
가용성 목표 설정
워크로드의 전체 SLO는 모든 종속성을 포함하여 전체적인 품질을 반영 합니다. SLO의 완성도 선언은 해당 종속성의 복합이 아니라 해당 워크로드의 전체 비즈니스 목표를 나타내야 합니다. 예를 들어 고객이 99.99%의 가용성을 기대하는 경우 전체 SLO는 한 부분이 99.80%만 달성하더라도 해당 목표를 목표로 해야 합니다.
관련자는 고객 환경을 평가하고 가동 중지 시간이 수익에 미치는 영향을 고려합니다. 이러한 손실을 비즈니스 흐름 설계 및 운영 비용과 비교합니다. 그런 다음 의사 결정자는 수익 손실을 피하고 평판을 유지하기 위해 안정성에 더 많은 돈을 지출해야 하는지 여부를 결정합니다.
워크로드 소유자는 재무 목표를 사용하여 목표를 결정합니다. 비즈니스 요구 사항은 측정 가능한 메트릭에 매핑됩니다. 목표는 고객 환경의 품질에 영향을 주는 일련의 요인을 식별하는 것입니다.
워크로드 설계자는 SLO를 기반으로 많은 기술적 결정을 내립니다. SLO는 다음을 수행할 수 있습니다.
다른 종속성을 고려할 때 아키텍처 결정에 중요한 입력 역할을 합니다.
워크로드의 상태에 대한 거의 실시간 보기 및 공유 이해를 제공하여 객관적인 토론을 가능하게 합니다. 또한 워크로드 팀이 안정성을 개선하고 새로운 기능을 개발하기 위한 노력의 우선 순위를 정하는 데 도움이 됩니다.
배포 작업의 기본 신호로 작동합니다. 이 신호는 문제가 발생할 경우 자동화된 롤백을 구동하고 변경 내용이 고객 환경의 예상된 개선을 달성한다는 유효성 검사를 제공합니다.
목표에 집중하여 수정 및 복구 속도를 높이고, 고객에게 문제에 대한 자동 알림을 유도하고, 조직의 팀 간에 신뢰를 구축합니다.
Important
SLA와 SLO의 차이점을 알아야 합니다. SLA 및 SLO는 유사한 데이터를 사용하거나 표시할 수 있지만 의도는 다릅니다. SLA는 조직과 고객 간의 공식 계약이며, 조직이 약속을 이행하지 못할 경우 직접적인 재정적 및 법적 영향을 미칩니다. 조직은 SLO를 사용하여 잠재적 가동 중지 시간이 허용되는 제한 내에 있는지 여부를 평가합니다.
SLO 및 SLA는 비즈니스 관계를 공유하며 독립적으로 제어되어야 합니다. SLA가 비즈니스 전술로 사용되는 경우 조직은 의도적으로 비즈니스 소유자의 목표에 따라 높은 가치로 설정할 수 있습니다. 반대로 SLO는 더 높을 수 있습니다. 중요 업무용 워크로드를 예로 들어 보세요. 이 워크로드 클래스는 재정적 손실과 인간의 안전에 대한 위협을 포함한 영향이 중요하기 때문에 긴 가동 중지 시간을 감당할 수 없습니다. 따라서 SLO는 일반적으로 99.999% 가동 시간을 대상으로 하며 일반적으로 5개의 9개라고 합니다. SLO가 이러한 목표를 충족하지 못하는 경우 조직은 신속하게 대응하여 오류를 완화하고 실패한 SLA의 결과를 방지해야 합니다.
이 문서의 예제에서는 비즈니스 목표를 지원하기 위해 높은 SLA를 설정합니다.
클라우드 플랫폼 및 기술 공급자는 제품에서 SLA를 게시합니다. SLA를 SLO 계산의 일부로 고려해야 하지만 SLA의 적용 범위를 이해하지 않고 그대로 사용하면 안 됩니다. 자세한 내용은 Microsoft SLA의 영향 평가를 참조 하세요.
일반적인 SLO 및 영향을 주는 요인 고려
모든 SLO는 특정 품질 기준을 대상으로 합니다. 안정성을 위해 이러한 일반적인 SLO를 고려합니다. 이 목록은 완전하지 않습니다. 비즈니스 요구 사항에 따라 SLO를 추가합니다.
성공률은 오류를 반환하거나 작업에 실패한 요청과 프로세스의 성공을 측정합니다.
대기 시간은 작업 요청이 시작된 시간과 결과를 사용할 수 있거나 프로세스가 완료된 시점 사이의 시간을 측정합니다.
용량은 제한 기반 응답 수와 같은 동시 사용량을 측정합니다.
가용성은 고객의 관점에서 가동 시간을 측정합니다.
처리량 은 특정 시간 동안 최소 데이터 전송 속도를 측정합니다. 처리량은 TPS(초당 트랜잭션 수) 또는 RPS(초당 요청 수)와 같은 데이터 속도 단위로 측정됩니다.
Azure에서 워크로드에 대한 시나리오 및 허용 오차를 이해합니다. Azure 서비스 및 애플리케이션 구성 요소는 모두 워크로드 SLO에 영향을 줍니다. 다음 표의 응답을 결합하여 전체 SLO를 파생합니다. 이러한 질문을 예로 사용하여 워크로드 구성 요소의 유틸리티를 평가합니다.
구성 요소 특성 | 고객 상호 작용 | 기타 요인 |
---|---|---|
- 요청 또는 응답 API를 노출 하나요? - 쿼리 API가 있나요? - 컴퓨팅 구성 요소인가요? - 작업 처리 구성 요소인가요? |
- 공용 Azure 서비스에 대한 제어 평면 및 관리 평면 액세스 입니다. - 데이터 평면 액세스(예: CRUD( 만들기, 읽기, 업데이트 및 삭제) 작업) |
- 릴리스 프로세스에 가동 중지 시간이 포함됩니까? - 버그를 도입할 가능성은 어떻게 됩니까? 워크로드가 다른 시스템과 통합되는 경우 통합 버그를 고려해야 할 수 있습니다. - 패치와 같은 일상적인 작업이 가용성 대상에 어떤 영향을 주나요? 파트너 종속성을 고려했나요? - 지속적인 긴급 및 긴급 백업 온-콜 회전을 지원하기에 인력이 충분한가요? - 애플리케이션에 잠재적으로 중단을 일으킬 수 있는 제어 범위를 벗어난 시끄러운 인접 항목이 있나요? |
SLO 범위 확인
시스템의 각 애플리케이션, 워크로드 또는 특정 흐름과 같은 다양한 수준에서 SLO를 설정할 수 있습니다. 각 구성 요소의 중요도에 따라 SLO를 사용자 지정할 수 있도록 수준별 SLO를 설정합니다.
SaaS(Software as a Service) 솔루션에서 고객당 SLO를 측정하여 각 고객의 환경을 최적화합니다. 고객은 세그먼트에 서로 다른 인프라 리소스를 가질 수 있습니다. 이러한 경우 고객 세그먼트에 걸쳐 모든 리소스를 집계하는 시스템 전체 SLO는 의미가 없을 수 있습니다. 대신 각 고객의 특정 컨텍스트에 맞는 SLO를 측정합니다. 자세한 내용은 다중 테넌트 솔루션에 대한 테넌트 모델을 참조 하세요.
복합 SLO 대상 정의
SLO는 관찰 가능성 창 내에서 측정 가능하고 측정되어야 합니다.
SLO는 종종 99.90%와 같은 백분율이지만 문일 수도 있습니다. 두 메서드를 모두 사용하여 모든 요소를 포함하는 숫자 값을 가져옵니다.
SLO는 허용되는 요소를 정의하는 측정 가능한 SLA로 구성됩니다. SLA는 경고할 수 있는 설정된 임계값을 가진 메트릭입니다. 플랫폼 또는 애플리케이션에서 수집할 수 있습니다. 서로 다른 구성 요소는 관련 SLA를 내보낸다. SLA를 선택할 때 SLO에 영향을 주는 요소를 고려합니다.
예를 들어 응답을 사용하고 API를 요청하는 흐름에 대한 SLO를 계산하려면 서버 대기 시간 및 요청 처리 시간을 측정합니다. 처리량 및 오류 비율은 VM(가상 머신), 확장 집합 또는 Azure Batch와 같은 연속 컴퓨팅 환경에 적용되지 않습니다.
컨트롤 플레인 액세스의 경우 API 응답 및 리소스 생성과 같은 장기 실행 작업에 대한 오류율 및 대기 시간을 고려합니다. 데이터 평면 액세스는 각각 자체 SLO 대상이 있는 사용되는 API에 따라 달라집니다.
좋은 SLI는 SLO를 위반할 수 있는 시기를 보여줍니다. 일반적으로 백분위수로 측정됩니다. 다음은 일반적으로 사용되는 몇 가지 백분위수 및 예상 가용성을 준수하지 않는 예상 시간입니다.
목표 | 주당 비준수 | 월별 비준수 | 연간 비준수 |
---|---|---|---|
99% | 1.68시간 | 7.20시간 | 3.65일 |
99.90% | 10.10분 | 43.20분 | 8.76시간 |
99.95% | 5분 | 21.60분 | 4.38시간 |
99.99% | 1.01분 | 4.32분 | 52.56분 |
99.999% | 6초 | 25.90초 | 5.26분 |
Important
복합 SLO 값은 기여 요인의 제품 분포입니다.
복합 SLO의 예는 99.95% × 99.99999% = ~99.95%입니다.
다양한 흐름에 대한 복합 SLO를 만들 때 다양한 중요도 및 관련성을 고려합니다. 흐름에는 비임계로 간주하고 계산에서 생략하는 구성 요소가 있을 수 있습니다. 짧은 사용 불가가 고객의 경험에 영향을 미치는지 여부에 따라 누락을 정당화할 수 있습니다. 경우에 따라 구성 요소가 SLO에 대해 고려하는 사용 사례와 관련이 없을 수 있습니다. 이러한 구성 요소도 계산에서 생략할 수 있습니다.
동일한 원칙이 작업에 적용됩니다. 특정 작업은 위험을 발생시키거나 SLO에 영향을 줄 수 있으며 다른 작업은 중요하지 않습니다. 결정은 명시적이고 합의에 기초해야 합니다.
SLO 및 SLA를 정의하고 측정하는 방법에 대한 설명 예제는 예제 섹션을 참조하세요.
Microsoft SLA의 영향 평가
Microsoft SLA는 Microsoft가 커밋하는 영역의 가용성에 대한 인사이트를 제공합니다. SLA는 제품 전체를 보장하지 않습니다. SLA를 평가할 때 게시된 백분위수 주위에 제공되는 적용 범위를 잘 이해합니다.
Azure 앱 Service의 기능인 Web Apps를 고려해 보세요. 이 기능은 지정된 사용 사례에서 200 OK 상태를 반환할 때 사용할 수 있는 것으로 간주됩니다. 특정 컨텍스트 및 시간 범위 내에서 간편한 인증 또는 슬롯 전환과 같은 기능의 가용성에 대한 재정적으로 지원되는 보장은 다루지 않습니다. 규약에 명시적으로 언급되지 않은 영역을 플랫폼의 최선의 노력으로 사용할 수 있는 것으로 고려해야 합니다.
따라서 워크로드가 배포 슬롯에 의존하는 경우 App Service SLA에서만 SLO를 파생시킬 수 없습니다. 워크로드 팀으로서 가동 시간 가용성을 헤지하고 예측해야 합니다. 그러나 이 예측은 불확실할 수 있으므로 SLO를 플랫폼의 SLA에 밀접하게 연결하는 것이 문제가 될 수 있습니다.
또 다른 예를 생각해 보십시오. Azure Front Door의 가용성이 99.99%인 경우 디자인은 계약에 게시된 특정 조건을 준수해야 합니다. 예를 들어 백 엔드에는 스토리지가 포함되어야 하고, 크기가 50KB 이상인 파일을 검색할 수 있는 작업이 필요하며 GET
, 지리적으로 다양한 위치가 5개 이상 있는 여러 위치에 에이전트를 배포해야 합니다. Azure Front Door의 이 좁은 사용 사례는 캐싱, 라우팅 규칙 또는 웹 애플리케이션 방화벽과 같은 기능을 보장하지 않습니다. 이러한 측면은 SLA의 범위를 벗어집니다.
다중Region 대상 구현
안정성 관점에서 다중 리전 배포는 중복성 원칙의 구현입니다. 목표는 지역 가동 중단 또는 성능 저하의 위험을 완화하는 것입니다. 제대로 설계된 이 전략은 장애 조치(failover) 목적으로 보조 지역을 추가하므로 SLO를 개선할 수 있습니다.
두 가지 주요 사용 사례가 있습니다.
더 많은 용량을 위해 지역에 부하를 분산하는 고가용성 패턴입니다. 고가용성으로 인해 워크로드 사용자가 지역으로 제한되지 않으며 전체 시스템의 성능이 SLO에 영향을 줍니다.
고객을 특정 지역으로 제한하여 분할하는 격벽 패턴입니다. 이러한 경우 각 지역에서 다중 리전 배포를 별도의 배포 또는 스탬프로 처리합니다. 워크로드에 적합한 SLA를 사용하여 각 스탬프의 상태를 개별적으로 측정합니다. 각 스탬프의 상태에 따라 전체 워크로드의 SLO를 고려합니다. 스탬프 간에 장애 조치(failover)할 수 있는 경우 한 스탬프의 오류를 다른 스탬프로 장애 조치(failover)를 통해 복구할 수 있기 때문에 전체 워크로드 SLO가 더 높습니다.
절충: 위험 감소가 복잡성을 더할 만한 가치가 있는지 확인합니다. 또한 다중Region 대상은 배포 조정, 데이터 일관성 보장 및 대기 시간 처리와 같은 운영 복잡성을 도입합니다. 이러한 작업은 복구하는 동안 중요합니다. 팀은 이러한 복잡성을 증가된 복원력과 비교할 수 있어야 합니다.
높은 SLO를 충족하는 데 필요한 중복성에 주의하세요. 예를 들어 Microsoft는 단일 지역 배포에 대해 보장하는 것보다 Azure Cosmos DB의 다중 리전 배포에 대해 더 높은 SLA를 보장합니다.
복구 메트릭 정의
RTO, RPO, MTTR 및 MTBF 메트릭과 같은 현실적인 복구 대상에 대한 정의는 오류 모드 분석 및 비즈니스 연속성 및 재해 복구를 위한 계획 및 테스트에 의존합니다. 이러한 대상을 정의할 때 플랫폼 제공 복구 보장을 고려합니다. Microsoft는 Azure SQL Database와 같은 일부 제품에 대해서만 RTO 및 RPO 보증을 게시합니다.
이 작업을 완료하기 전에 이해 관계자와 포부를 가진 목표를 논의하고 아키텍처 디자인이 가장 잘 이해할 수 있도록 복구 대상을 지원하는지 확인합니다. 복구 메트릭에 대해 철저히 테스트되지 않은 흐름 또는 전체 워크로드가 SLA를 보장해서는 안 된다는 점을 이해 관계자에게 명확하게 전달합니다. 관련자가 워크로드가 업데이트되면 시간이 지남에 따라 복구 대상이 변경된다는 것을 이해해야 합니다. 고객을 추가하거나 고객 환경을 개선하기 위해 새로운 기술을 채택할 때 워크로드가 더 복잡해질 수 있습니다. 이러한 변경은 복구 메트릭을 늘리거나 줄일 수 있습니다.
참고 항목
MTBF는 정의하고 보장하기 어려울 수 있습니다. PaaS(Platform as a Service) 또는 SaaS 모델은 클라우드 공급자의 알림 없이 실패하고 복구할 수 있으며 프로세스는 사용자 또는 고객에게 완전히 투명할 수 있습니다. 이 메트릭에 대한 대상을 정의하는 경우 제어할 수 있는 구성 요소만 다룹니다.
복구 대상을 정의할 때 복구를 시작하는 임계값을 정의합니다. 예를 들어 웹 노드를 5분 이상 사용할 수 없는 경우 풀에 새 노드를 자동으로 추가합니다. 모든 구성 요소에 대한 임계값을 정의하고 다른 구성 요소 및 종속성에 미치는 영향을 포함하여 특정 구성 요소에 대한 복구에 어떤 영향을 미치는지 고려합니다. 또한 임계값은 복구 작업을 너무 빨리 시작하지 않도록 일시적인 오류를 고려해야 합니다. 복구 작업의 고객에 대한 데이터 손실 또는 세션 중단과 같은 잠재적 위험을 관련자와 문서화하고 공유합니다.
대상 모니터링 및 시각화
안정성 대상에 대해 수집하는 데이터를 사용하여 각 워크로드 및 관련 중요 흐름에 대한 상태 모델을 빌드합니다. 상태 모델은 흐름 및 워크로드에 대한 정상 상태, 성능 저하 및 비정상 상태를 정의합니다. 상태가 변경되면 모델은 책임 당사자에게 경고해야 합니다. 자세한 디자인 고려 사항 및 권장 사항은 상태 모델링 지침을 참조 하세요.
운영 팀과 워크로드 관련자에게 정보를 제공하려면 워크로드 상태 모델의 실시간 상태 및 전반적인 추세를 반영하는 시각화를 만듭니다. 이해 관계자와 시각화 솔루션을 논의하여 가치 있고 사용하기 쉬운 정보를 제공할 수 있도록 합니다. 또한 생성된 보고서를 매주, 매월 또는 분기별로 보고 싶을 수도 있습니다.
Azure 촉진
Azure SLA는 가동 시간 및 연결에 대한 Microsoft 약정을 제공합니다. 서비스에는 SLA가 다르며 서비스 내의 제품에 SLA가 다른 경우도 있습니다. 자세한 내용은 온라인 서비스 SLA를 참조하세요.
Azure SLA에는 워크로드가 SLA를 충족하지 않는 경우 서비스 크레딧을 얻기 위한 절차와 각 서비스의 가용성 정의가 포함되어 있습니다. SLA의 이러한 측면은 적용 정책의 역할을 합니다.
시각화 시스템에 대한 Azure Monitor 대시보드를 탐색합니다.
예시
Contoso, Ltd.는 이벤트 티켓 시스템을 위한 새로운 모바일 환경을 설계하고 있습니다. 다음은 고급 아키텍처입니다.
Grafana 로고는 해당 회사의 상표입니다. 이 상표의 사용은 어떠한 보증도 의미하지 않습니다.
구성 요소
다음은 SLO 정의의 개념을 설명하는 몇 가지 구성 요소입니다. 이 아키텍처에는 다음 목록에 포함되지 않은 구성 요소가 있습니다. 예를 들어 Key Vault가 중요한 요청 흐름의 일부인 경우에도 응답 사용 사례의 일부가 아닙니다. Key Vault를 사용할 수 없는 경우 애플리케이션은 시작 중에 로드된 비밀을 사용하여 계속 작동합니다. 그러나 애플리케이션의 크기를 조정해야 하는 경우 새 노드를 비밀로 로드해야 하므로 Key Vault 가용성이 중요해집니다. 이 예제에서는 크기 조정 작업이 고려되지 않습니다. 다른 구성 요소는 간결하게 하기 위해 생략됩니다.
Azure Front Door 는 고객이 요청을 보내는 데 사용하는 API를 노출하는 단일 진입점입니다.
Azure Container Apps 는 워크로드 팀이 소유하고 애플리케이션에 대한 비즈니스 논리를 실행하는 데 사용하는 환경입니다.
SQL Managed Instance 는 다른 팀이 소유하고 관리하며 워크로드의 중요한 종속성입니다.
Azure Private Link 는 Azure Front Door와 Container Apps 배포 간에 프라이빗 연결을 제공합니다. 또한 SQL Managed Instance는 프라이빗 엔드포인트를 통해 애플리케이션에 노출됩니다.
이 아키텍처에서 API 팀은 애플리케이션의 중요한 흐름에 대한 초기 SLO 대상을 정의합니다. SLO에 영향을 주는 요인에 설명된 전략을 채택합니다. 추가 기능을 지나치게 강조하지 않고 핵심 기능을 다루는 목표를 정의하는 것을 목표로 합니다. 모든 핵심 클라우드 기능을 포함하고 배포에서 코드를 실행하는 세 가지 중요한 사용자 흐름의 상태를 측정합니다. 그러나 이러한 흐름은 모든 코드 또는 데이터 액세스를 다루지는 않습니다. 다음은 영향을 주는 요인입니다.
복합 SLO 계산
Azure 가용성 SLO: Azure에 대한 재무 약정 SLA는 플랫폼 안정성을 평가하는 프록시 역할을 합니다.
Azure 구성 요소 적용 가능한 SLA 적용 범위 SLA에서 다루지 않음 조정된 SLO Azure Front Door 성공적인 HTTP GET
작업의 경우 99.99%캐싱, 규칙 엔진 99.98% Container Apps 기본 제공 수신으로 연결할 수 있는 배포된 앱 기반 99.95% 자동 크기 조정, 토큰 저장소 기능 99.95% SQL Managed Instance SQL Server 인스턴스에 대한 연결 기준 99.99% 성능, 데이터 보존 99.80% Private Link 99.99% 프라이빗 엔드포인트 네트워크가 트래픽을 허용하지 않거나 트래픽이 엔드포인트와 Private Link 서비스 간에 흐르지 않은 시간(분)을 기준으로 합니다. 1분 미만 지속되는 개별 오류 99.99% 조정은 워크로드 팀의 목표에 대한 약속에 따라 달라지는 몇 가지 요인을 기반으로 합니다. 한 가지 요인은 이전 환경을 기반으로 플랫폼의 기능에 대한 신뢰도일 수 있습니다. 예를 들어 Container Apps 및 Private Link의 경우 팀은 SLA 값을 있는 그대로 사용하는 것이 편합니다.
미묘한 요소도 있습니다. 예를 들어 팀은 스키마 변경 및 백업 수행과 같은 데이터 작업의 잠재적 오류를 고려하여 SQL Managed Instance의 SLO 값을 99.80%로 낮춥니다.
팀은 조정된 개별 SLO 값의 영향을 계산하여 복합 SLO를 설정합니다. 이 값은 99.72%입니다.
다른 기여 요인이 있습니다. 아키텍처는 게시된 SLA가 없는 가상 네트워크 및 NSG(네트워크 보안 그룹)와 같은 Azure 네트워킹 구성 요소를 사용합니다. 워크로드 팀은 각 구성 요소에 대해 99.99%의 가용성을 가진 이러한 요소를 고려하기로 결정합니다.
예측된 플랫폼 가용성을 기반으로 하는 복합 SLO: 매월 99.68%
애플리케이션 코드 SLO: 팀은 애플리케이션 코드 또는 저장 프로시저의 버그가 시스템 가용성에 영향을 줄 수 있음을 인정하고 코드 관련 오류를 고려하여 매월 1시간의 가동 중지 시간을 할당합니다.
일반적인 가동 중지 시간 백분위수 는 코드 결함, 크기 조정 문제 및 기타 코드 관련 고려 사항과 같은 개별 요인에 대해 SLO를 추정하는 데 사용됩니다.
코드 및 데이터 가용성을 기반으로 하는 복합 SLO: 매월 99.86%
리소스 및 애플리케이션 구성 SLO: 팀은 클라우드 리소스 및 애플리케이션 코드를 올바르게 구성해야 한다는 것을 인식합니다. 이 대상에는 자동 크기 조정 규칙 설정, NSG 규칙 배포 및 올바른 SKU 크기 선택 등이 포함됩니다. 구성 오류를 고려하기 위해 매월 가동 중지 시간의 10분(가용성 약 99.98%)을 예산으로 책정합니다.
구성 가용성을 기반으로 하는 복합 SLO: 매월 99.95%
운영 SLO: 워크로드 팀은 운영 우수성에 대한 잘 설계된 프레임워크 원칙을 따라 좋은 DevOps 문화를 개발합니다. 모든 스프린트에서 클라우드 리소스, 구성 및 코드를 배포합니다.
팀은 실행 중인 시스템을 불안정하게 만들 수 있으므로 배포를 위험으로 간주합니다. TLS 인증서 업데이트, DNS 변경 또는 도구 오류로 인해 오류가 발생할 수 있습니다. 팀은 또한 비상 수정으로 인한 잠재적 가동 중지 시간을 고려합니다. 총 20분의 월별 가동 중지 시간을 예산으로 설정하며 이는 약 99.95%의 가용성입니다.
유지 관리 기간은 시스템 유지 관리 또는 업데이트가 발생하는 기간으로 지정됩니다. API는 대부분 매일 약 4시간 동안 사용되지 않습니다. 사용 불가 위험을 줄이기 위해 팀은 덜 활동적인 시간 동안 유지 관리 작업을 예약할 수 있습니다. 이 방법은 더 높은 SLO로 이어지지만 팀은 유지 관리 기간을 SLO의 일부로 포함하지 않기로 결정합니다.
작업 가용성을 기반으로 하는 복합 SLO: 매월 99.95%
외부 종속성 SLO: 팀은 SQL Managed Instance를 기본 종속성으로 간주하며, 이는 전체 플랫폼 가용성에 이미 99.80%의 가용성을 고려합니다. 다른 외부 종속성은 고려되지 않습니다.
외부 종속성을 기반으로 하는 복합 SLO: 해당 없음
전체 복합 SLO 결과 확인
전체 복합 SLO 대상은 99.45%로 설정되며 이는 매월 약 4시간의 가동 중지 시간에 해당합니다.
워크로드 팀은 매월 4시간만 사용할 수 없는 SLO 목표를 달성하기 위해 온-콜 회전을 설정합니다. 고객 지원 및 가상 트랜잭션 모니터링은 SRE(온-콜 사이트 안정성 엔지니어링) 지원을 호출하여 SLO 문제를 해결하기 위한 복구 단계를 즉시 시작할 수 있습니다.
워크로드 SLA 설정
워크로드에 대한 SLA는 매월 99.90%의 가용성입니다.
워크로드 팀의 법률 및 재무 부서는 워크로드에 대한 SLA를 매월 99.90%의 가용성으로 설정하여 SLO 목표인 99.45%를 초과합니다. 매력적인 SLA를 기반으로 재무 지급액과 예상 고객 성장을 분석한 후 이 결정을 내립니다. SLA는 두 가지 핵심 사용자 흐름을 다루며 가용성뿐만 아니라 성능 고려 사항을 포함합니다. 비즈니스 팀이 비즈니스에 이익을 주기 위해 취한 계산된 위험이며 엔지니어링 팀은 이러한 약속을 잘 알고 있습니다.
정확성 SLO 설정
애플리케이션의 핵심 사용자 흐름은 사용 가능하고 사용 가능하거나 경쟁적으로 응답해야 합니다. 팀은 특히 API에 대한 응답 시간 SLO를 설정하며, 클라이언트 처리 시간 및 인터넷 네트워크 순회를 제외합니다. 가용성 기간 동안에만 이 SLO를 평가합니다. 75번째 백분위수를 SLO 대상과 성능 측정값으로 모두 선택합니다. 이 측정값은 일반적인 고객 환경을 캡처하고 최악의 시나리오를 제외합니다.
관련 링크
Azure에서 중요 업무용 워크로드의 상태 모델링 및 관찰 가능성
안정성 검사 목록
전체 권장 사항 집합을 참조하세요.