SLO란 무엇인가: 엔지니어링팀의 신뢰도 목표

SLO란 무엇인가? 서비스 레벨 목표(Service Level Objective)는 팀이 스스로에게 정한 내부 신뢰도 목표입니다. 고객과의 계약이 아니고, 당신의 모니터링 스택에서 나온 원시 지표도 아닙니다. SLO는 한 가지 질문에 답합니다. 이 서비스가 얼마나 신뢰할 수 있어야 하고, 우리는 그것을 어떻게 측정할 것인가?

완전한 SLO는 이렇게 생겼습니다. /api/checkout에 대한 HTTP 요청의 99.9%가 성공 상태를 반환하고 300ms 이내에 완료되며, 30일 롤링 윈도우에서 측정됩니다. 세 가지 요소가 있습니다. 측정, 목표, 윈도우. 세 가지 모두 중요합니다.

SLI, SLO, SLA: 다르게 의미하는 세 개의 약자

이 세 용어는 항상 함께 나타납니다. 팀들은 그것들을 같은 의미로 사용합니다. 하지만 서로 다른 것을 나타냅니다.

**SLI(Service Level Indicator)**는 당신의 모니터링 시스템이 생산하는 원시 측정입니다. 전체 요청에 대한 에러율의 백분율. 밀리초 단위의 P99 레이턴시. 성공한 데이터베이스 쓰기의 백분율. SLI는 Datadog, Grafana 또는 당신이 운영하고 있는 모든 스택에서 나오는 숫자입니다. 그것은 당신에게 무엇이 일어났는지 알려줍니다.

**SLO(Service Level Objective)**는 SLI 위에 정의하는 목표입니다. 이 SLI가 취할 수 있는 모든 가능한 값 중에서, 어느 범위가 허용 가능한가? 당신의 SLI가 에러율이고 당신의 SLO가 "5분 윈도우의 99%에서 에러율이 0.1% 미만"이라면, 대시보드의 숫자만 보는 것이 아니라 통과/실패 테스트가 있습니다.

**SLA(Service Level Agreement)**는 같은 로직의 외부 버전이며 계약상의 결과가 있습니다. 당신의 SLA는 "99.5% 가동 시간 또는 20% 서비스 크레딧을 발급"이라고 말할 수 있습니다. 당신의 SLO는 그 임계값 위에 있어야 하므로 당신의 팀은 SLA 위반이 고객 대화가 되기 전에 성능 저하를 알게 됩니다.

SLO와 SLA 사이의 격차는 부주의에 대한 패딩이 아닙니다. 그것은 "우리는 위반을 향해 트렌드하고 있습니다"를 "우리는 지금 고칠 시간이 있습니다"로 변환하는 설계된 마진입니다.

한 가지 중요한 구분이 더 있습니다. SLI는 연속적으로 측정되지만 SLO는 윈도우에서 평가됩니다. 같은 에러율을 7일 대 30일 윈도우에서 측정하면 매우 다른 통과/실패 결과를 낳습니다. 한 시간의 나쁜 시간은 7일 윈도우에서 많은 의미를 가집니다. 30일 윈도우에서는 대략 기간의 1%입니다. 올바른 윈도우를 선택하는 것은 올바른 목표를 선택하는 것만큼 중요합니다.

"얼마나 신뢰할 수 있나?"는 완전한 질문이 아닙니다

숫자를 선택하기 전에, 서비스가 성능 저하할 때 사용자가 경험하는 것을 이해해야 합니다. "우리는 5개의 9가 필요해"는 야망의 표현이지 측정이 아닙니다. 99.999% 가용성의 체크아웃 API는 대략 월별 26초의 에러를 의미합니다. 초당 10개의 거래를 처리하는 서비스의 경우 허용 가능할 수 있습니다. 실시간 금융 결제를 처리하는 서비스의 경우 그렇지 않을 수 있습니다.

올바른 SLO는 두 가지 요소에 따라 다릅니다. 성능 저하의 사용자 영향과 더 엄격한 목표를 유지하기 위한 운영 비용입니다.

당신의 서비스가 지난 90일 동안 99.3%의 가용성을 기록했다면, 99.9%의 SLO로 첫 번째 SLO를 시작하는 것은 야심적이며, 보정된 것이 아닙니다. 실용적인 접근법은 지난 90일의 SLI 데이터를 가져오고, SLO를 현재 성능보다 약간 더 엄격하게 설정한 다음, 분기별로 검토하는 것입니다. 99.5%의 SLO를 실제 에러 버짓 정책과 함께 하는 것이 99.9%의 SLO보다 낫습니다. 99.9%는 매번 위반할 때 무시됩니다.

서비스 유형별 일반적인 SLO 목표:

• 사용자 대면 API(체크아웃, 인증): 99.9% 가용성, P99 레이턴시 500ms 미만

• 내부 서비스(데이터 파이프라인, 배치 작업): 99.5% 성공률, 작업 완료에서 측정

• 관리 도구: 99% 가용성은 종종 충분합니다

• 백그라운드 워커: HTTP 상태가 아닌 작업 완료 시간에 SLO를 설정합니다

측정할 SLI를 선택할 때, Google의 SRE 책의 네 가지 신호를 시작점으로 사용하세요. 가용성(요청이 성공했나요?), 레이턴시(얼마나 오래 걸렸나요?), 처리량(시스템이 얼마나 많은 요청을 처리하고 있나요?), 에러율(몇 개가 실패했나요?). 모든 서비스가 네 가지를 모두 필요로 하지는 않습니다. 대부분의 팀은 가용성과 하나의 레이턴시 백분위수에서 실제 신호를 얻습니다. 첫 두 개의 신뢰할 수 있는 기준이 없기 전에 더 많은 SLI를 추가하는 것은 통찰력을 얻지 못하면서 잡음을 만드는 일반적인 방법입니다.

에러 버짓: 목표에서 운영 결정까지

에러 버짓은 당신의 SLO의 수학적 역입니다. 당신의 가용성 SLO가 99.9%라면, 측정 윈도우에서 요청의 0.1%는 실패할 수 있습니다. 월별 100만 개의 요청을 받는 서비스의 경우 SLO가 위반되기 전에 1,000개의 요청이 실패합니다.

에러 버짓은 SLO를 운영 도구로 만듭니다. 없으면 SLO는 위반되고 논의되는 임계값입니다. 에러 버짓 정책을 사용하면 의사결정 프레임워크가 됩니다.

에러 버짓이 건강할 때, 예를 들어 윈도우의 2주 남은 상태에서 80% 남아 있을 때, 팀은 빠르게 배포할 수 있습니다. 새로운 기능, 실험, 더 위험한 배포가 모두 범위 내입니다. 에러 버짓은 속도가 현재 제약이 아니라는 신호입니다.

에러 버짓이 빠르게 소비될 때, 팀은 전환합니다. 중요하지 않은 변경은 보류됩니다. 배포 정책은 더 엄격해집니다. 신뢰도 수정이 우선 순위가 됩니다. 에러 버짓이 결정을 했습니다. 관리자의 판단 호출이 아닙니다.

구체적인 시나리오는 이렇습니다. 체크아웃 서비스는 화요일 오후에 12분의 성능 저하를 겪었고, 월간 에러 버짓의 15%를 소비했습니다. 목요일의 두 번째 사건은 또 다른 12%를 소비했습니다. 월 첫 주에 27%를 소비했으므로, 에러 버짓 정책이 트리거됩니다. 사후분석이 완료되고 근본 원인이 패치될 때까지 새로운 기능 배포가 없습니다. 그 결정은 제품/엔지니어링 협상이 아닙니다. 그것은 데이터의 읽음입니다.

Google은 SRE Workbook에서 에러 버짓 정책을 발표했습니다. 분기별 에러 버짓의 20% 이상을 소비하는 단일 사건은 사후분석을 필요로 합니다. 그것은 적응할 구체적인 정책입니다.

버짓 소소 알림은 이를 더 나아갑니다. 에러 버짓이 거의 없을 때까지 기다리는 대신, 소비율이 윈도우가 끝나기 전에 버짓을 소진할 것을 제안할 때 알림이 시작됩니다. 당신의 서비스가 정상 속도의 14배로 에러 버짓을 소비하고 있다면, 약 50시간 안에 30일 버짓을 소진할 것입니다. 그 속도의 알림은 팀에 응답할 2일을 제공합니다. 그것을 설정하지 않는 것은 고객이 이미 알아챘을 때 SLO 위반을 발견합니다. Datadog과 Grafana는 기본적으로 다중 윈도우, 다중 버짓 속도 알림을 지원합니다. 설정하는 데는 오후가 걸립니다.

첫 SLO를 번호를 잘못하지 않고 설정합니다

가장 흔한 실수는 측정을 설정하기 전에 목표부터 시작하는 것입니다.

1단계: SLI를 정의합니다. "가용성"은 SLI가 아닙니다. "비-에러 상태(2xx/3xx)를 반환하는 HTTP 요청을 모든 HTTP 요청으로 나눈 것"은 SLI입니다. 측정은 당신이 이미 가지고 있는 텔레메트리에서 생성될 수 있어야 합니다. "곧" 계획하고 있는 것을 약속하는 것은 SLO에 데이터 소스가 없다는 의미입니다.

2단계: 역사적 데이터를 가져옵니다. 지난 60~90일을 보세요. SLI는 실제로 어떤 모습인가요? 가장 나쁜 이틀은 무엇이었나요? 이것은 오늘 달성 가능한 목표와 첫 위반 전에 얼마나 많은 헤드룸이 있는지를 알려줍니다.

3단계: 측정 윈도우를 설정합니다. 30일 롤링 윈도우가 가장 일반적이며 응답성 있고 항상 최신인 데이터를 제공합니다. 달력 월 윈도우는 월 경계에서 절벽 효과를 만듭니다. 7일 롤링 윈도우는 더 민감하지만 신뢰도 근육을 구축 중인 팀에는 너무 자주 트리거될 수 있습니다.

4단계: 필요하기 전에 에러 버짓 정책을 씁니다. 어느 에러 버짓 소비율에서 팀은 중요하지 않은 변경을 중지합니까? 어느 속도에서 온콜이 상승합니까? 이 사건 중에가 아니라 미리 이것을 문서화합니다.

5단계: 한 개의 서비스로 시작합니다. 한 번에 15개 서비스의 SLO를 정의하면 아무도 읽지 않는 15개의 대시보드가 생깁니다. 가장 사용자 눈에 띄는 서비스로 시작하고, 한 분기 실행하고, 조정한 다음, 확장합니다.

측정 윈도우 옵션과 장단점:

• 7일 롤링: 빠른 피드백, 짧은 사건에 더 민감, 알림 피로를 유발할 수 있음

• 30일 롤링: 가장 일반적, 신호와 잡음의 균형

• 90일 롤링: 배치 작업과 같은 드물지만 중요한 작업에 유용

작동하는 예시입니다. 이커머스 API의 경우, 당신의 첫 번째 SLO를 다음과 같이 설정할 수 있습니다. "/checkout에 대한 요청의 95%가 성공하고 500ms 이내에 반환되며, 28일 롤링 윈도우에서 측정됩니다." 이것은 구체적인 SLI(성공률과 결합된 레이턴시)를 제공합니다. 특정 목표(95%), 정의된 윈도우(28일). 거기서 당신은 에러 버짓을 계산합니다. SLO가 위반되기 전에 총 요청의 5%가 실패하거나 느릴 수 있습니다. 일일 200,000개의 요청을 받는다면, 월간 에러 버짓은 대략 280,000개의 요청이 실패하기 전입니다.

SLO 모니터링이 코드베이스 작업과 연결되는 곳

예상보다 빠르게 소비되는 에러 버짓은 인프라 문제보다는 코드베이스 문제입니다. 레이턴시 급증은 코드 검토에서 발견되지 않은 N+1 쿼리로 추적됩니다. 가용성 감소는 특정 부하 조합에서만 트리거되는 코드 경로의 null 포인터 예외로 추적됩니다. SLO는 증상을 감지합니다. 코드베이스는 원인을 포함합니다.

이것은 "알림이 작동"에서 "근본 원인을 식별"까지의 시간이 실질적인 제약이 되는 곳입니다. 체크아웃 서비스가 에러 버짓의 30%를 3일 만에 소비하고 있고 온콜 엔지니어가 150,000줄 모놀리스에서 재시도 로직을 grep해야 하는 상황에서, SLO가 하는 일입니다. 근본 원인 분석을 위한 도구가 있지 않습니다.

그들의 관찰 스택과 함께 AI 보조 코드 검색을 계획한 팀들은 사건 중에 진단 시간이 눈에 띄게 짧아진 것을 보고합니다. 지불 서비스가 503 응답을 재시도하는 방법에 대한 자연어 쿼리는 5개 파일과 하나의 Confluence 페이지를 읽는 데 걸리는 20분이 아니라 몇 초 안에 관련 함수를 표시합니다. 43분의 에러 버짓 윈도우는 코드를 읽는 데가 아니라 문제를 수정하는 데 사용됩니다.

SLO를 얻는 팀의 네 가지 방법

너무 많은 SLO. 12개의 SLO를 동시에 추적하는 팀은 2개월 안에 알림을 배경 잡음으로 취급할 것입니다. 10명의 엔지니어 팀에서 가장 사용자 눈에 띄는 동작에 집중한 3~5개의 SLO가 작동할 수 있는 천장입니다. 더 필요하다면 계층으로 구성합니다. 중요한 SLO는 에러 버짓 정책을 트리거하고, 정보 SLO는 데이터를 생성합니다.

인프라 측정, 사용자 경험이 아닙니다. CPU 사용률, 메모리 사용량, 디스크 I/O는 유용한 디버그 신호입니다. 당신이 사용자 눈에 띄는 성능 저하와 직접적으로 상관관계가 있음을 증명할 수 없다면 좋지 않은 SLI입니다. 사용자가 경험하는 것을 측정합니다. 요청 성공률, P95 또는 P99의 응답 시간, 첫 번째 의미 있는 데이터를 렌더링하는 시간.

SLO는 운영 비용 분석 없이 설정됩니다. 99.99% 가용성 달성은 일반적으로 활성 중복성, 다중 지역 페일오버, 모든 시간에 즉각적인 온콜 응답을 필요로 합니다. 팀이 지속적으로 그렇게 운영할 수 없다면 SLO는 정기적으로 위반되고 무시될 것입니다. 위반되고 무시된 SLO는 SLO가 없는 것보다 악합니다. 팀에 신뢰도 알림을 무시하도록 훈련합니다.

에러 버짓 데이터를 사용하여 비난을 배정합니다. 소비된 에러 버짓에 대한 첫 반응이 그것을 야기한 변경을 배포한 사람을 식별하는 것이라면, 보고는 정직하지 않게 될 것입니다. 에러 버짓은 팀 자원입니다. 버짓이 부족할 때, 질문은 "우리는 무엇을 수정하나요?"입니다. "누가 책임이 있나요?"입니다.

조직적 건강 테스트는 이렇습니다. 엔지니어링 올-핸즈 모임에서 현재 에러 버짓 상태를 공유할 수 있을까요? 그것을 하지 않고. 그렇다면 SLO 주변의 문화는 대상 자체보다 더 많은 주의가 필요합니다. 신뢰도 지표는 팀이 문제를 보고하는 것이 개인적 위험을 만들지 않는다고 신뢰할 때만 의사결정 도구로 작동합니다.

SLO는 분기별 검토, 연간이 아닙니다

SLO를 설정하는 것은 일회성 보정이 아닙니다. 서비스가 변하고, 트래픽 패턴이 변하고, 주어진 신뢰도 수준을 유지하는 비용이 변합니다.

90일마다 네 가지 질문을 거쳐가세요:

1. SLO가 견뎠나요? 그렇다면 편안했나요? 대상이 더 엄격할 수 있다고 제안하나요?

2. 에러 버짓이 완전히 소비되었나요? 어떤 사건들이 그것을 운전했나요?

3. SLO가 유용한 신호를 표시했나요, 아니면 팀이 에러 버짓 정책을 무시했나요?

4. 측정 윈도우가 서비스가 사용되는 방식에 여전히 적절한가요?

팀이 분기별로 에러 버짓 정책을 2회 이상 무시했다면 SLO는 아마도 잘못 보정되어 있습니다. 대상이 너무 엄격하거나, 윈도우가 너무 짧거나, 측정이 사용자가 실제로 경험하는 것을 반영하지 않습니다.

SLO는 보정 도구입니다. 신뢰도가 개선되고, 트래픽이 증가하고, 비즈니스가 다운타임에 대한 허용도를 변경할 때 조정하도록 설계되었습니다. 분기별로 SLO를 검토하고 조정하는 팀은 신뢰도 실행을 운영합니다. 한 번 설정한 이후 손대지 않은 팀에는 아무도 관심 없는 숫자가 있는 대시보드가 있습니다.