SLI(서비스 수준 지표) 및 SLO(서비스 수준 목표)
지금까지 이 모듈에서 우리는 운영 인식을 높이고 안정성에 대한 이해와 프레임을 확장하는 방법을 배웠으며 작업에 필요한 Azure Monitor 도구를 살펴보았습니다. 이제 이 모듈에서 가장 중요한 아이디어 중 하나와 이를 구현하는 프로세스를 살펴볼 시간입니다.
"우리 조직의 안정성을 개선하기 위해 이 모든 것을 어떻게 사용해야 하는가?"라는 질문에 답해 보겠습니다.
피드백 루프 시작
다음은 문제를 드러낼 수 있는 중요한 아이디어입니다.
적절한 피드백 루프는 조직의 안정성을 개선합니다.
조직의 안정성을 개선하는 것은 반복적인 프로세스입니다. 이 단원에서는 조직에서 신뢰성을 향상시키는 데 도움이 되는 일종의 피드백 루프를 만들고 육성하기 위해 사이트 신뢰성 엔지니어링 세계에서 매우 효과적인 사례를 살펴볼 것입니다. 최소한 객관적인 데이터를 기반으로 한 안정성에 대한 조직 내 구체적인 대화를 시작할 것입니다.
이 모듈의 앞부분에서 사이트 안정성 엔지니어링의 정의로 다음을 언급했습니다.
사이트 안정성 엔지니어링은 조직이 시스템, 서비스, 제품에서 적절한 수준의 안정성을 지속적으로 달성하도록 지원하는 엔지니어링 원칙입니다.
여기서 적절한 수준의 안정성 개념이 사용됩니다.
SLI(서비스 수준 지표)
SLI(서비스 수준 지표)는 안정성에 대한 폭넓은 이해에 관한 이전의 논의와 연결됩니다. 이 다이어그램이 기억나시나요?
SLI는 시스템의 안정성을 측정하는 방법을 지정하려는 시도입니다. 서비스가 안정적으로 작동(예상대로 수행)되고 있다는 지표는 무엇입니까? 이 질문에 답하려면 무엇을 측정해야 할까요?
예: 웹 서버 사용 가능성 및 대기 시간
우리가 웹 서버와 그 가용성에 대해 작업하고 있다고 가정해 보겠습니다. 웹 서버가 수신한 HTTP 요청 수와 웹 서버가 성공적으로 응답한 HTTP 요청 수가 유용할 수 있습니다. 보다 정확하게 말하면 총 요청 대비 성공한 요청의 비율을 이해하여 웹 서버가 얼마나 성공적이었는지 파악하려고 합니다.
총 요청 수를 성공한 요청 수로 나누면 비율이 나옵니다. 이 비율에 100을 곱하면 백분율을 얻을 수 있습니다. 어림수를 사용하는 예의 경우, 웹 서버가 100개의 요청을 수신하고 80개에 성공적으로 응답한 경우 비율은 0.8입니다. 이 값에 100을 곱하면 사용 가능성은 80%라고 할 수 있습니다.
하나 더 해 보겠습니다. 이번에는 웹 서비스의 대기 시간과 관련된 측정을 지정하겠습니다. 총 작업 수 대비 10밀리초 이내에 완료된 작업 수의 비율을 파악하고자 할 수 있습니다. 총 요청 100개를 임계값보다 빠르게 반환된 요청 80개로 나눈 동일한 계산을 수행하면 다시 0.8의 비율을 계산합니다. 100을 곱하면 여기에서도 이 측정을 통해 대기 시간 요구 사항에 대해 80% 성공했다고 말할 수 있습니다.
분명히 말씀드리자면 이것은 단지 웹사이트만의 문제가 아닙니다. 데이터를 처리하는 파이프라인 서비스가 있는 경우 적용 범위(예: 처리한 데이터의 양)를 측정해야 한다고 말할 수 있습니다. 매우 다른 시스템이지만 기본 수학은 동일합니다.
SLI: 측정 위치
객관적인 데이터를 사용하는 구체적인 토론에서 SLI가 유용하려면 측정 대상 외에 지정해야 하는 다른 부분이 있습니다. SLI를 만들 때 무엇을 측정했는지 뿐만 아니라 어디에서 측정했는지도 기록해야 합니다.
예를 들어 앞서 언급한 웹 서버의 사용 가능성을 측정한다고 할 때 총 HTTP 요청 수와 성공한 HTTP 요청 수를 어디에서 검색했는지 밝히지 않았습니다. 동료들과 이 웹 서버의 신뢰성에 대해 대화를 하려고 하는데 서버 앞의 부하 분산 장치에서 수집된 요청 통계를 보지만 그들은 서버 자체의 통계를 보는 경우 이 대화는 그렇지 않을 수 있습니다. 잘 가. 부하 분산 장치는 네트워크로 들어오는 모든 요청을 볼 수 있지만 네트워크 또는 부하 분산 장치 자체에 문제가 있는 경우 일부 요청이 서버에 도달하지 않을 수 있기 때문에 숫자가 근본적으로 다를 수 있습니다. 두 가지 다른 데이터 세트를 기반으로 결론을 도출합니다.
이 문제를 해결하는 간단한 방법은 SLI의 데이터 소스에 대해 구체적으로 지정하는 것입니다. 웹 서버 사용 가능성의 경우 "부하 분산 장치에서 측정된 총 요청에 대한 성공한 요청의 비율"이라고 할 수 있습니다. 지연 시간은 "클라이언트에서 측정된 총 작업 수에 대한 10밀리초 미만 내에 완료된 작업 수의 비율"과 같은 것입니다.
이것은 논리적 질문으로 이어집니다. SLI를 측정하기에 가장 좋은 곳은 어디입니까? 불행히도 보편적으로 "올바른" 대답은 없습니다. 어느 쪽이든 일장일단이 있다는 것을 이해하고 결정해야 합니다. 제공할 수 있는 한 가지 지침은 안정성에 대한 이전의 논의를 떠올리게 합니다. 즉, 고객 환경을 가장 정확하게 반영하는 위치에서 측정하려고 노력하라는 것입니다.
SLO(서비스 수준 목표)
측정할 항목과 위치를 결정하는 것은 훌륭한 시작이지만 목표까지 절반쯤 온 것에 불과합니다. 웹 서버의 가용성 SLI에 필요한 메트릭을 검색하고 실제로 80%의 가용성을 찾았다고 가정해 보겠습니다.
좋은 건가요, 나쁜 건가요? "적절한 수준의 안정성"인가요?
이러한 질문에 답하려면 해당 SLI의 목표, 즉 SLO(서비스 수준 목표)를 설정해야 합니다. 이 목표는 해당 서비스의 목표를 분명하게 명시합니다.
SLO를 만드는 기본적 레시피는 다음과 같은 재료로 구성됩니다.
측정하려는 "것" - 요청 수, 스토리지 검사, 작업 등 측정하는 항목
원하는 비율 - 예를 들어 "50%의 시간에 성공", "99.9%의 시간에 읽을 수 있음", "90%의 시간에 10ms 이내 반환"
기간 목표에 대해 고려할 기간은 무엇입니까? 지난 10분 동안, 지난 분기 동안, 30일 기간 동안? SLO는 서로 다른 기간의 데이터를 비교할 수 있도록 "월"과 같은 달력 단위 대신 롤링 창을 사용하여 지정되지 않는 경우가 더 많습니다.
이러한 구성 요소를 합치고 중요한 위치 정보를 포함한 샘플 SLO는 다음과 비슷합니다.
지난 30일 동안 부하 분산 장치의 보고에 따르면 HTTP 요청의 90%가 성공함.
마찬가지로 기본 SLO 측정 대기 시간은 다음과 같이 표시될 수 있습니다.
지난 30일 동안 클라이언트의 보고에 따르면 HTTP 요청의 90%가 20ms 이내에 반환되었습니다.
조직에 관행을 도입할 때는 이와 같은 간단한 기본 SLO로 시작합니다. 필요한 경우 나중에 더 복잡한 SLO를 만들 수 있습니다.
Azure Monitor의 SLI 및 SLO
이 단원의 마지막 부분으로 Log Analytics를 사용하여 Azure Monitor에서 간단한 SLI/SLO를 나타내는 방법을 알아보겠습니다. 일관성을 위해 웹 서버 예시로 돌아갑니다.
마지막 단원에서 KQL(Kusto Query Language)을 사용하여 Log Analytics에서 쿼리를 만들 수 있다는 것을 배웠습니다. 다음은 웹 서비스의 사용 가능성 SLI를 표시하는 KQL 쿼리입니다.
requests
| where timestamp > ago(30d)
| summarize succeed = count (success == true), failed = count (success == false), total = count() by bin(timestamp, 5m)
| extend SLI = succeed * 100.00 / total
| project SLI, timestamp
| render timechart
이전처럼 데이터의 원본인 requests 테이블을 지정하는 것으로 시작합니다. 그런 다음 작업할 데이터의 범위를 지난 30일 분량의 정보로 좁힙니다. 그런 다음 성공한 요청 수, 실패한 요청 수 및 총 요청 수를 수집합니다(5분 버킷). SLI는 이전에 본 쉬운 산술을 사용하여 생성됩니다. 우리는 KQL에게 타임스탬프와 함께 해당 SLI를 플로팅하고 싶다고 말한 다음 다음과 같은 차트를 생성합니다.
이제 간단한 SLO 표현 레이어를 추가해 보겠습니다.
requests
| where timestamp > ago(5h)
| summarize succeed = count (success == true), failed = count (success == false), total = count() by bin(timestamp, 5m)
| extend SLI = succeed * 100.00 / total
| extend SLO = 80.0
| project SLI, timestamp, SLO
| render timechart
이 예에서는 이전 예에서 2개의 선이 변경되었습니다. 첫 번째는 SLO에 사용할 숫자를 정의합니다. 두 번째는 SLO가 차트에 포함되어야 함을 KQL에 알립니다. 결과는 다음과 같습니다.
이 차트에서 가용성 목표 아래로 떨어진 시간을 쉽게 확인할 수 있습니다.
SLI/SLO 사용
변함없이 SLI 및 SLO와 함께 수행해야 하는 일부 조정이 있습니다(결국 이것은 반복 프로세스임). 그러나 일단 완료되면 정보로 무엇을 합니까?
희소식은 SLI와 SLO를 구축하는 것만으로도 조직에 긍정적인 영향을 미칠 것이라는 사실을 알게 될 것입니다. 그러려면 관련자와의 논의 및 올바른 방향을 설정하는 의사소통이 필요합니다. SLI와 SLO로 무엇을 할 것이냐에 대한 그 다음 논의도 마찬가지로 도움이 됩니다.
궁극적으로 SLI와 SLO는 작업 계획 도구입니다. 이러한 요청은 "서비스의 새로운 기능을 작업해야 합니까, 안정성 작업에 집중해야 합니까?" 같은 엔지니어링 결정을 내리는 데 도움이 되며, 앞에서 설명한 여러 피드백 루프에도 도움이 됩니다.
부차적이지만 상당히 일반적인 SLI와 SLO의 용도는 보다 즉각적인 모니터링/응답 시스템의 일부로 사용하는 것입니다. 작업 계획 측면(먼저 집중해야 함) 외에도 많은 사람들이 이를 작업 신호로 사용합니다. 예를 들어 서비스가 오랜 시간 동안 SLO 아래로 떨어지면 직원에게 경고하도록 선택할 수 있습니다. 이러한 종류의 경고는 이 모듈의 다음 단원으로 연결됩니다.