estudy 한국어/English

SLO와 SLI의 비교

1,983 단어·4 분·원문(.md)

모니터링 시스템의 데이터를 다루다 보면 결국 우리가 잘하고 있는가? 를 측정해야하는 순간이 온다.

이때 헷갈리기 쉬운 SLO, SLI 비교와 활용법을 알아보겠다.

개념적 정의 #

SLI, SLO는 서비스의 신뢰성 reliability를 측정하고 관리하기 위한 핵심 지표다.

두 개념은 항상 한 세트로 움직이지만 역할은 완전히 다르다.

**SLI(Service Level Indicator, 서비스 수준 지표)**는 서비스가 현재 얼마나 잘 작동하고 있는가를 나타내는 실제 측정값 reality이다.

유저가 체감한 서비스의 상태를 정량화한 펙트 그 자체고 계산식은 주로 전체 이벤트중 성공한 이벤트의 비율로 정의한다.

SLI=Successful EventsTotal Events×100SLI = \frac{\text{Successful Events}}{\text{Total Events}} \times 100

(예: 최근 30일동안 전체 api요청중 200 ok 응답 비율은 99.95%일때 여기서 99.95%가 SLI이다.)

SLO(Service Level Objective, 서비스 주누 목표): SLI가 어느 정도 수준을 유지해야하는가에 대한 내부적인 목표치다. 엔지니어링 팀과 비즈니스 팀이 합의한 마지노선이다.

예를들어 우리 서비스의 성공적인 api 응답 비율 SLI를 99.9% 이상 유지하자에서 여기서 99.9가 SLO인것.

결과적으로 현재의 SLI가 설정된 SLO를 만족하고 있는가?를 지속적으로 추적하는것이 신뢰성 관심의 핵심이다.

참고로 SLO를 지키지 못했을때 고객에게 위약금을 물어준다던가 하는, 외부적인 비즈니스 계약이 SLA인것.

Problem Definition #

SLI와 SLO를 잘못 설정하거나 개념을 혼동하면 엔지니어들은 의미없는 알람의 홍수속에 빠지거나 서비스 혁신 속도가 늦춰지는 부작용이 있을 수 있다.

  • 원인(Cause) 기반의 잘못된 SLI 선정: cpu 사용률 80% 초과, 메모리 사용룽 90% 초과 같은 인프라 지표를 SLI로 삼는 경우가 많은데, 하지만 cpu 99%를 쳐도 유저가 api응답을 0.1초 만에 정상적으로 받고있다면 서비스는 정상인 상태다. 유저의 체감과 무관한 지표를 SLI로 잡으면 엔지니어는 헛고생만 하게되는것이다.
  • 비현실적인 100% SLO 설정의 저주: 우리 서비스는 절대 죽으면 안돼 SLO는 100%!! 라고 설정하는 순간 힘들어지는데, 100% 가용성은 기술적으로 불가능할 뿐만 아니라 에러를 단 하나도 허용하지 않겠다는 뜻이라 새로운 기능 배포나 인프라 업데이트도 전부 올스톱을 해야한다.
  • 에러 버짓 error budget의 부재: SLO가 없다면 우리가 한 달에 어느 정도의 장애까지는 허용할 수 있는가에 대한 여유 자산을 계산할 수 없다. 기준이 없으니 배포를 강행할지 아니면 멈추고 안정화에 집중할지 감으로만 결정하게 된다.

Example #

최악의 상황을 예시로 잘못된 지표와 목표 부재를 예를 들어보겠다.

운영팀이 데이터베이스 cpu 사용률 85%이하를 암묵적인 목표로 삼고있는데, 트래픽이 몰리는 저녁 8시마다 cpu가 90%를 찍고 알람이 울려 담당자가 매일밤 랩탑을 킨다.

하지만 정작 고객들은 아무런 느려짐을 느끼지 못하고 결제가 펑펑하고 있다. 엔지니어는 번아웃이오고 진짜 장애가 났을때 알람을 무시하게 될수도 있게된다.

올바른 상황 SLI/SLO 기반의 에러 버짓 활용

팀에서 합의하여 사용자 결제 api응답속도가 500ms 이내로 떨어지는 비율 SLI를 한달 기준 99.9% SLO로 유지하자라고 설정했다. (고객기반)

즉 한달 약 43,200분 중 0.1% 43분 만큼은 결제가 느려지니 실패해도 허용하겠다는 에러버짓이 생겼다.

이번주에 대규모 신규 기능 배포를 앞두고있다 했을때 SLI를 측정해보니 99.98로 에러 버짓이 넉넉하게 남아있으므로 자신있게 배포를 진행한다. risk taking인건데, 에러 버짓이 명확하게 정의되어있으므로 어느정도는 허용한다는 자세로 들어가는게 편하다.

Solution #

모니터링 시스템 prometheus에서 유저가 체감하는 증상 기반의 메트릭을 추출해 실제 SLI를 계산하고 이를 SLO와 비교하는 과정을 터미널에서 직접 수행해보자.

PromQL을 이용해 터미널에서 30일 기준 가용성 SLI 계산 #

HTTP %xx 에러가 아닌 정상 응답 2xx, 3xx, 4xx 비율을 계산해 우리 서비스의 팩트 SLI를 확인한다.

curl을 통해서 prometheus http api에 질의해서 확인해보자.

# 지난 30일(30d) 동안 전체 요청 중 서버 에러(5..)가 아닌 정상 요청의 비율을 계산 (PromQL)
$ curl -s "http://prometheus:9090/api/v1/query" --data-urlencode 'query=sum(rate(http_requests_total{status!~"5.."}[30d])) / sum(rate(http_requests_total[30d])) * 100' | jq '.data.result[0].value[1]' | tr -d '"'

99.9523104

결과를 분석해보면 현재 우리 서비스의 최근 30일간 실제 가용성과 측정값 SLI는 99.95%로 계산되어 있다.

목표치 SLO를 99.9로 잡았다면 목표를 성공적으로 달성하고 있는 형태인 것이다.

남은 에러 버짓을 계산하고 번 레이트 burn rate를 확인하는 예시도 이어서 알아보자.

단순히 SLI가 SLO보다 높은지를 보는것을 넘어 허용된 에러 0.1%중 우리가 현재 얼마나 에러를 까먹고 있는지 파악한다.

# 전체 허용된 에러량(1 - SLO) 대비 현재 발생한 에러 비율을 계산하여 에러 버짓 소진율을 확인 (예: SLO가 99.9%인 경우)
$ curl -s "http://prometheus:9090/api/v1/query" --data-urlencode 'query=(sum(rate(http_requests_total{status=~"5.."}[30d])) / sum(rate(http_requests_total[30d]))) / (1 - 0.999) * 100' | jq '{ "error_budget_consumed_percent": .data.result[0].value[1] }'

{
  "error_budget_consumed_percent": "47.6895"
}

터미널 확인결과 한달동안 허용된 에러버짓중 47,6%를 소진했고 아직 절반이상의 여유가 남아있으므로 계획된 신규 기능 배포나 마이그레이션 작업을 승인해도 안전한 상태임을 데이터로 증명이 가능하다.

이처럼 SLI, SLO는 단순히 대시보드에 띄워놓는 예쁜 숫자가 아니라 개발팀이 배포를 할 것인가, 멈출것인가를 결정하는 강력한 기준점이 된다.

SRE/question/q_33.md