클라우드 모니터링 서비스 수준 목표

이 문서는 클라우드 모니터링 가이드의 시리즈의 일부입니다.

아래 섹션에서는 서비스 수준 목표의 기본 원칙과 이를 구현하고 적용하는 방법에 대해 알아봅니다.

개요

SLO(서비스 수준 목표)는 주요 고객 중심 SLA(서비스 수준 지표)에 대한 측정 가능한 목표입니다. 비즈니스 또는 인프라 워크로드에 대한 고객의 경험을 측정하고 비즈니스 서비스 공급자가 공식적으로 협상된 SLA(서비스 수준 계약) 또는 모든 당사자 간의 비공식 계약에서 수행한 약속을 충족하는지 여부를 결정합니다.

서비스 브로커는 Azure 서비스에 대한 Microsoft의 서비스 수준 계약에 정의된 대로 서비스의 안정성에 대한 Microsoft의 노력에 의존합니다. 이를 통해 가상 모니터링, 네트워크 연결, 보안 및 규정 준수와 같은 서비스 체인의 책임에 집중할 수 있습니다.

용어

다음은 이러한 각 용어에 대한 정의와 간략한 설명입니다. 이러한 정의는 Google의 SRE 핸드북에서 가져옵니다.

용어	설명
SLA(서비스 수준 계약)	일반적으로 서비스 공급자와 고객 간의 바인딩 약정입니다. 일반적으로 계약에는 SLO 대상 누락의 결과가 포함됩니다. 서비스의 특정 측면은 서비스 공급자와 서비스 소비자 간에 합의된 품질, 가용성 및 책임입니다.
Monitoring	서비스 및 시스템에 대한 정량적 실시간 데이터를 수집하는 방법입니다.
메트릭	관련 서비스 동작을 측정하고 서비스의 현재 작동 상태를 측정하고 동작을 정량화하기 위해 처리 및 집계되는 SLA(서비스 수준 표시기)로 집계할 수 있습니다. SLI는 서비스의 현재 상태에 대한 주요 지표이자 실시간 지표입니다.
로그	코드로 시작하고 코드 경로 또는 신중한 이벤트의 개별 실행에 대한 정보를 보고합니다. 이 정보를 사용하여 SLA/SLO로 측정된 고객 환경 및 서비스 안정성에 영향을 주는 근본 원인 문제를 해결하고 식별하는 데 도움이 됩니다.
SLO(서비스 수준 목표)	서비스가 얼마나 잘 수행되는지에 대한 기대치를 설정하는 서비스 수준 표시기(SLA)로 측정되는 서비스 수준에 대한 대상 값입니다. SLO는 특히 엔드투엔드 고객 환경을 추적합니다. 좋은 SLO를 설정하려면 일반적으로 원하는 환경을 정의한 다음 서비스 코드를 계측하여 해당 환경을 측정하고(관련 SLA 수집) 고객의 기대치를 충족하는 방법의 목표를 설정합니다.
SLI(서비스 수준 표시기)	서비스의 품질 또는 안정성을 수량화하는 메트릭입니다. 최소한 가용성, 대기 시간, 처리량 및 오류 속도의 네 가지 일반적인 SLA가 평가됩니다.
가용성	일반적으로 시스템이 작동하고 작동하는 시간 중 측정 가능하거나 관찰 가능한 백분율을 나타냅니다. 하나 이상의 안정성 문제(및 구성 변경, 적용된 업데이트 등과 관련된 기타 오류 모드)의 영향을 받는 경험의 연속성을 위한 고객 연결 대상으로 가용성을 측정합니다.
오류 예산	SLO와 관련된 re기본ing 버퍼의 백분율입니다. 오류 예산은 DevOps 도구이며 IT는 서비스 안정성과 혁신 속도의 균형을 맞추기 위해 사용합니다.

SLO의 목적

SLO는 다음을 포함하여 클라우드 워크로드의 개발 및 운영에 중요한 많은 목적을 제공합니다.

• NRT(근 실시간) : 고객이 경험한 대로 서비스의 상태를 NRT 보기로 제공합니다.
• TTN(알림 시간) 단축: 고객에게 서비스 문제에 대한 자동 알림을 유도하여 TTN(알림 시간)을 크게 줄입니다.
• 고객에게 기본 신호: 배포 작업의 기본 신호 역할을 하여 문제가 발생할 경우 자동화된 롤백을 유도하여 잠재적인 문제에 더 적은 고객을 노출합니다.
• 변경 확인: 예상되는 고객 환경 개선을 달성한 변경 내용에 대한 유효성 검사를 제공합니다.
• 우선 순위 결정: 팀이 기능을 빌드할지 또는 안정성에 대해 작업할지를 이해하는 데 도움이 됩니다.
• 서비스 상태 인사이트: 서비스 상태에 대한 객관적이고 고객 중심적인 토론을 사용하도록 설정합니다.
• 분석 시간 단축: 책임 있는 서비스에 초점을 맞춰 고객 문제의 완화 및 RCA(근본 원인 분석)를 가속화합니다.
• 아키텍처 종속성: 서비스가 종속성을 사용할 때 아키텍처 결정에 대한 필수 입력 역할을 합니다.
• 신뢰 구축: 팀 간에 신뢰를 구축하는 상태 측정값에 대한 공유 이해를 제공합니다.
• 투명성 가져오기: 고객이 비즈니스를 실행할 수 있도록 비즈니스를 실행하는 데 사용하는 것과 동일한 SLA를 고객에게 공개합니다.
• 단일 유리 창: 서비스에 대한 가로 단일 창 및 해당 종속성 및 고장 사일로를 사용하도록 설정합니다.

SLO를 사용하여 엔지니어링 프로세스를 추진하면 DevOps 및 IT는 Azure에서 빌드하거나 마이그레이션하는 애플리케이션 또는 인프라 서비스의 상태 조기에 이해할 수 있습니다. 그런 다음 이러한 서비스의 안정성에 대해 수행해야 하는 사용자 및 자동화된 의사 결정을 모두 구동하는 데 사용할 수 있습니다. 엔지니어링 사례의 이러한 변환은 단기적으로 해당 서비스의 안정성에 크게 영향을 줍니다.

SLO를 정의하는 방법

SLO의 목적은 고객의 관점에서 품질을 정확하게 측정하는 명확한 신호를 확보하는 것입니다. 각 서비스 팀은 서비스 소비자의 경험에 따라 서비스의 가장 중요한 측정 가능한 메트릭에 허용되는 범위를 정의하는 소규모의 SLO(서비스 수준 목표) 집합을 만듭니다. SLO는 서비스에서 내보낸 메트릭에 대해 정의된 숫자 목표입니다. 이러한 목표와 연관된 메트릭을 모니터링하여 서비스가 정상인지 여부를 확인할 수 있습니다.

예를 들어 내부 시간 추적 웹 기반 애플리케이션에 대한 SLO의 간소화된 예는 다음과 같습니다. 최근 5분 동안의 요청은 99번째 백분위수에서 1000밀리초 미만으로 제공됩니다.

메트릭은 SLA(서비스 수준 표시기)라는 시계열 데이터의 집계입니다. SLI가 수집되는 위치는 매우 중요합니다. 위의 예제에서 고객이 API를 사용하여 서비스와 상호 작용하는 경우 시스템 대기 시간 및 요청을 처리하는 시간을 측정하는 것은 정확한 SLA입니다. 그러나 고객이 웹 포털을 사용하여 서비스와 상호 작용하는 경우, 요청을 처리하는 총 시간에 웹 페이지의 JavaScript 성능도 포함되어야 합니다.

서비스 소유자의 초점은 다음을 결정하는 것입니다.

• 어떤 시나리오가 고객의 관점에서 서비스 상태에 대한 중요한 지표인지
• 어디에서 가능한 한 고객 경험과 가장 가까운 SLI를 수집할 수 있는지
• 이러한 SLA에 대한 SLO는 무엇인가 요?

SLO는 성취도를 높이기 위한 점진적인 접근 방식을 사용하여 정의하거나 비즈니스에서 직접 규정할 수 있습니다. 서비스에서 정의한 SLO를 사용하여 빌드 방법에 대한 아키텍처를 결정합니다. 따라서 측정할 시나리오와 측정할 기간을 신중하게 선택해야 합니다. 요약하자면 SLO는 다음과 같은 값으로 구성됩니다.

• SLI. 예를 들어 부하 분산 장치에서 측정된 충분히 빠른 요청의 비율은 400ms 미만입니다.
• 기간. 메트릭이 측정되는 기간입니다.
• 대상. 예를 들어 지정된 기간 동안 충족할 것으로 예상되는 총 요청(예: 90%)에 대한 빠른 요청의 목표 백분율입니다.

SLO 유형

업계를 전반적으로 살펴보면 다음과 같은 두 가지 유형의 SLO가 존재합니다.

• 서비스 중심 SLO - 이러한 SLO는 팀이 시간이 지남에 따라 서비스의 품질을 점진적으로 개선하기 위해 정의하는 전술적 목표입니다. 엔지니어링 이정표에서 달성할 수 있는 실용적인 목표가 되도록 설계되었습니다. 예를 들어 서비스가 현재 99.7%의 가용성을 달성하고 있는 경우 팀은 다음 분기에 99.9%의 가용성에 도달하겠다는 목표를 설정할 수 있습니다.

• 고객 중심 SLO - 이러한 SLO는 이상적인 미래 상태 또는 목표를 정의합니다. 이 시점에서, 품질에 대한 추가 투자는 고객의 기대를 완전히 충족하기 때문에 불필요한 것으로 간주됩니다.

예를 들어 고객이 운영하는 비즈니스 또는 인프라 서비스가 99.99%의 가용성을 제공하고 서비스가 현재 99.8%의 가용성만 달성한다고 예상되는 경우 고객 중심 SLO는 여전히 99.99%입니다.

적절한 SLO를 정의하려면 시간이 걸립니다. 첫 번째 단계는 고객과 대화하고 사용자가 서비스에서 원하는 것을 이해하여 소수의 지표를 파생시키고 문서화하는 것입니다. 서비스를 사용하는 방법과 서비스가 비즈니스를 성공적으로 실행하기 위해 제공해야 하는 사항에 대한 시나리오 및 허용 오차를 알아봅니다. 이는 일반적으로 반복적인 과정입니다. 고객의 기대치는 수익원에 영향을 전혀 미치지 않고 모든 조건에서 100% 가용성 실현에 이를 수 있으며, 고객 부문 간에 크게 다를 수 있는 여러 기대치를 관리해야 합니다.

서비스(또는 서비스 인스턴스) 상태만 보는 모니터링 접근 방식은 스펙트럼의 양쪽 끝에서 누락된 고객 환경 문제에 취약합니다. 서비스 상태가 항상 고객 환경의 품질과 관련이 있는 것은 아닙니다. 이는 Azure PaaS와 SaaS 서비스 간에 다양한 동작 특성, 해당 Azure 서비스의 구성, 리소스가 배포되는 방법 및 위치(즉, 지역) 및 사용자 지정 코드/논리 추가가 있어 복잡성을 더하기 때문입니다.

SLO를 정의할 때 클라우드 공급자는 SLA에 대한 종속성임을 기억해야 합니다. 각 서비스에 대해 지정된 서비스 수준 계약에 대한 계정입니다. Azure의 경우 온라인 서비스에 대한 SLA(서비스 수준 계약)를 참조 하세요.

SLI를 정의하려면 어떻게 해야 할까요?

SLI 사양은 대기 시간 또는 가용성과 같은 서비스에 대한 특정 안정성 차원에 대한 사용자의 기대에 대한 공식적인 설명입니다.

측정하고 수집할 올바른 메트릭을 선택하여 간단하게 시작하고 의미가 없는 메트릭을 너무 많이 수집하여 과도하게 컴파일하지 마세요. 정의한 SLI가 고객 경험과 직접적인 관련이 있는지 확인하세요. 이 때문에 몇 가지 지표로 시작하는 사용자의 관점을 이해해야 합니다.

서비스가 메모리 또는 CPU와 같은 어떤 방식으로든 리소스가 제한된 경우 해당 포화도 뛰어난 SLI가 될 수 있습니다. 그러나 포화는 가난한 사용자 환경에 직접 해당하지 않으므로 SLO로 사용하면 안 됩니다(서비스는 높은 메모리 사용률을 가질 수 있지만 사용자는 영향을 받지 않음).

최대 3개의 지표를 만드는 것이 좋습니다. 세 개가 넘는 지표를 사용하더라도 유의미한 가치가 더해지지는 않습니다. 종종 지표의 과도한 수는 기본 지표의 증상을 포함 의미 할 수있다. 트래픽 및 포화는 다른 서비스 지표의 해석에 대한 서비스 부하 및 지원을 설명하므로 이러한 세 가지 기본 지표에 추가되어야 합니다.

SLO를 구현하려면 어떻게 해야 하나요?

가장 중요한 SLA는 고객의 관점에서 서비스에 미치는 영향을 가장 명확하게 나타내는 SLA입니다. 많은 서비스의 경우 대기 시간, 처리량, 오류 속도 및 가용성이 포함됩니다. 서비스에 고객 환경에 영향을 주는 특별한 고려 사항이 있는 경우 해당 영역에 대한 SLA도 측정해야 합니다. 예를 들어 메시징 서비스에 대한 엔드 투 엔드 처리 대기 시간은 고객 환경을 직접 나타내는 지표이며 SLI에서 처리해야 합니다.

SLO 예제

인적 자원은 내부 시간 추적 웹 기반 애플리케이션을 현대화하고 엔터프라이즈 IT를 통해 Azure 클라우드에서 호스팅하는 데 관심이 있습니다. 이들은 서비스가 조직의 모든 사용자에게 계속해서 도달하기를 바라므로, 다음과 같은 사항에 관심이 있습니다.

• 사용 현황 보고서 및 시간에 따라 서비스를 사용하는 사용자 수
• 가용성, 성능, 보안 및 규정 준수(서비스 보증)와 같은 정기적인 상태 모니터링
• 서비스 월별 비용과 같은 비용입니다.
• 사이버 보안은 제로 트러스트 보안 전략에 따라 리소스 및 데이터에 대한 액세스를 제어합니다.

위의 예제에서 볼 수 있듯이 SLO/SLI 범주 및 예제는 서비스 디자인 초기에 정의해야 합니다. 지금까지 빌드한 온-프레미스 서비스와 마찬가지입니다.

SLO 테이블/SLI 범주

다음 예제에는 단지 일부만 포함되어 있을 뿐입니다. 안정성 및 유지 관리성 SLO는 수십 년 동안 시스템의 주요 특징으로서 기능해 왔지만, 사이버 보안, 품질 및 사용자 환경 및 비용에 대한 조치를 포함하는 SLO도 정의할 수 있습니다.

Services

서비스 또는 시스템의 일반적인 상위 수준 측정값은 일반적으로 서비스 계약에서 명문화됩니다. 대부분의 최신 계약은 주요 SLO로 가용성을 측정하고 인증 토큰, 사서함 또는 스토리지 계정과 같은 주요 워크로드 항목 또는 프로덕션 단위에 따라 간단한 가동 중지 시간 측정값을 사용합니다.

범주	설명	예시
가용성	유지 관리 또는 운영 가용성 간의 간단한 가동 중지 시간 또는 평균 시간(MTBM/(MTBM+MDT))	월간 99.99%
용량	적절한, 최대 또는 최적의 비즈니스 및 서비스 성능, 처리량, 스토리지, 사람, 대역폭, 수요, 리소스 및 서비스 기능을 보장합니다. 트리거 역할을 하는 노동 및 시간 제한 포함	% 사용률(CPU, 스토리지, 메모리, 대기 시간, 처리량, 크기 조정)
보안	비즈니스, 자산 및 데이터에 해를 끼칠 수 있거나 피해를 입힐 수 있는 활성 위협 및 취약성(내부 및 외부)입니다.	HAFNIUM 위협 감지
규정 준수	업데이트, 서비스 수준, 규정 준수 강화, 원하는 구성 드리프트	모든 자산에 대한 99.5% 서비스 업데이트
연속성	대규모 재해 및 외부 이벤트에서 생존하고 복구할 수 있는 능력	시간(재구성)
서비스 품질(QoS)	시간에 따른 사용자 실제 경험의 특징	Teams 통화 품질 - 수신한 패킷 손실률 < 2%

안정성

클래식 SLO의 안정성은 시스템, 서비스, 리소스 또는 구성 요소에서 오류 및 장애 조치(failover)에 대한 종속성, 내구성 및 품질 수준을 의미하며, 운영 시간 또는 가용성을 높이기 위해 오류(예: 중복성 강화 또는 콘텐츠 배달 네트워크 추가)에 대한 관리 노력이 적용됩니다. 또한 SLO를 측정하는 데 사용되는 데이터의 정확도, 충실도, 무결성 및 신뢰성을 의미할 수도 있습니다. 이는 시스템이 온도 스트레스와 같은 지정된 조건에서 의도한 함수를 수행할 수 있는 클래식 확률 을 의미할 수 있습니다. 복원력에는 크기 조정, 냉각, 부하 분산, 복구, 예측할 수 없는 수요, 심각한 스트레스로 성능 저하, 대규모 재해의 연속성을 위한 설계(일반적으로 별도의 SLO)와 같은 적응성을 제공하는 기본 제공 디자인 요소 또는 기능이 포함되어 있습니다.

범주	설명	예시
실패율	총 운영 시간 동안 발생한 오류 수	973시간 동안 5회 실패(.00514)
MTBF(실패 간 평균 시간)	MTBF는 실패율의 역입니다	194.6시간

유지 관리

가용성을 측정할 수 있도록 안정성 SLO와 함께 인시던트 및 문제 관리와 같은 IT 서비스 관리 프로세스에 대한 지원 SLO를 결합합니다.

범주	설명	예시
서비스 인시던트 성능	범주 또는 제품 또는 우선 순위별	인시던트 수명 주기의 각 단계에 대한 시간 및 비용 측정값
보안 인시던트 성능	범주 또는 제품 또는 우선 순위별	인시던트 수명 주기의 각 단계에 대한 시간 및 비용 측정값
구성 요소 MTTR(평균 복구 시간)	이벤트 검색부터 복원 또는 수정까지의 시간
MTBM(유지 관리 간 평균 시간)	정상적인 프로덕션 작업이 발생하는 예방 작업을 포함하여 모든 기본 테넌트 작업 간의 평균 또는 평균 시간입니다.	유지 관리 지연 시간 참조
MDT(유지 관리 지연 시간)	감지에서 복구까지의 총 시간(물류 및 관리 지연 포함)	주문, 배송 및 설치를 포함하도록 하드웨어를 교체할 시간입니다.

고객 환경

범주	설명	예시
처리량	시간에 따라 시스템에 배치된 워크로드 또는 생산성 부하의 양, 비율 또는 속도	시간 단위당 트랜잭션
오류율	총 오류 수를 백분율로 표시합니다.	% 보안 이벤트
대기 시간	입력-출력 시간 또는 지연, 프로세스를 통한 작업 이동 또는 애플리케이션-사용자 작업 이동의 측정값	평균 시간(초)

기타

범주	설명	예시
비용	서비스, 구성 요소 또는 시간별로 지출, 청구 및 청구서를 측정합니다.	자본 비용 또는 운영 비용
범위	관리 중인 구성 요소, 시스템 및 서비스의 비율(규정 준수)	규정 준수
피드 안정성	하트비트, 커넥터, 변경 내용 등의 오류입니다.	중요 업무용 회사 데이터의 변경 내용 추적
생산성	작업을 생산적으로 수행하기 위한 효율성	노동, 직원별 시간, 분석가 생산성

고려 사항

• 액세스를 확인합니다. 조직의 관리자 및 기타 가상 사용자가 중복되지 않도록 이들에게 Azure Monitor 또는 다른 Azure 서비스, 특히 Azure SaaS 및 PaaS에서 사용할 수 있는 시각화에 대한 액세스 권한이 부여되었는지 확인합니다.

• 모니터링 범위 또는 총 자산 가시성을 확인하세요. 관리 및 보안이 필요한 모든 자산에 대한 에이전트, 내보낸 로그, 테이블 및 쿼리를 확인하고 SLO에서 리얼리즘을 보장하기 위해 "사각지대" 또는 검사 간격을 식별합니다.

• 올바른 소비자 앞에서 올바른 데이터를 가져옵니다. SLO 및 SLA의 소비자가 기본 데이터를 해석하여 신뢰를 구축하고 데이터에서 얻은 정보를 사용하여 의사 결정을 내릴 수 있는지 확인합니다.

• 합리적인 약속을 합니다. 특히 비용 관리가 필수적인 경우 SLO를 대상으로 설정하는 경우 실제 시스템 성능이 지나치게 수행되거나 제공이 부족하지 않도록 하거나 고객의 기대치를 관리하도록 대상을 조정합니다.

• 예기치 않은 외부 이벤트를 고려하세요. 연속성 계획 및 위험 평가 개발 시 날씨, 정전 또는 재해와 같이 통제되지 않는 이벤트를 고려합니다.

• 변경을 고려하세요. SLO가 서비스 변경 또는 기술 안정성, 처리량, 품질 및 기본 지속성 변경(예: 지원 직원 감소)을 고려하도록 합니다.

• 균형 잡힌 SLO 집합을 제공하세요. 서비스 또는 시스템에 대한 균형 잡힌 또는 360도 관점을 제공하고 안정성에 중점을 두는 다양한 SLO를 보장합니다.

다음 단계

올바른 데이터 수집