서비스 수준 목표
서비스 수준 목표는 재고 있는 값에 미리 그어 두는 목표선입니다. 이만큼은 지키겠다는 수준을 숫자로 정해 둡니다. 정해 두면 지켰는지 못 지켰는지를 나중에 따질 수 있습니다.
상세
일곱 시에 만나기로 했으면 속으로는 여섯 시 사십 분 도착을 잡아 둡니다. 안쪽에 그어 둔 이 선은 넘겼다고 무엇을 물어내는 선이 아닙니다. 하루치로 따지지 않고 몇 달을 모아 놓고 늦는 날이 잦아졌는지를 봅니다.
구글이 펴낸 사이트 신뢰성 엔지니어링 책은 이 낱말을 정의해서 씁니다. 책은 서비스 수준 목표(SLO, Service Level Objective)를 서비스 수준 지표(SLI, Service Level Indicator)로 재는 서비스 수준에 대한 목표값 또는 목표값의 범위라고 적습니다. 서비스 수준 지표는 제공되는 서비스 수준의 어떤 면을 조심스럽게 정의해 정량으로 잰 측도라고 적습니다.
그래서 목표선은 지표 위에 세워집니다. 책은 목표선이 자연스럽게 두 가지 꼴을 띤다고 적습니다. 지표가 목표값 이하인 꼴입니다. 또는 지표가 아래 경계와 위 경계 사이에 드는 꼴입니다.
목표값을 고르는 일은 복잡하다고 책은 적습니다. 값을 늘 고를 수 있는 것도 아닙니다. 바깥에서 들어오는 요청의 초당 질의 수(QPS, Queries Per Second)는 사실상 사용자가 원하는 만큼으로 정해집니다. 그래서 여기에는 목표를 제대로 걸 수는 없다고 적습니다. 반대로 요청당 평균 지연에는 목표를 걸 수 있습니다. 그렇게 걸어 둔 목표가 낮은 지연을 내도록 프론트엔드를 짜거나 그런 장비를 사도록 이끌 수도 있다고 적습니다.
목표선은 한 번의 결과가 아니라 여러 번을 모아 놓고 판정합니다. 그래서 목표선 하나만 덜렁 적어 두면 나중에 판정이 안 됩니다. 책은 최대한 명확하려면 목표를 어떻게 재는지와 어떤 조건에서 유효한지를 함께 적어야 한다고 적습니다. 목표선 하나에는 셋이 같이 붙습니다. 무엇을 재는지, 얼마를 목표로 하는지, 어느 구간을 놓고 재는지입니다.
배경
서비스를 굴리는 쪽은 그 서비스에서 어떤 동작이 실제로 중요한지를 알아야 합니다. 그 동작을 어떻게 재고 평가할지도 알아야 합니다. 사이트 신뢰성 엔지니어링 책은 그것을 모르면 서비스를 제대로 관리하는 일이 불가능하다고 적습니다. 잘 관리하는 것은 말할 것도 없다고 덧붙입니다.
필요했던 것은 어느 수준으로 서비스를 내주겠다는 말을 정해서 전달하는 일이었습니다. 내부 API(Application Programming Interface, 응용 프로그램 인터페이스)를 쓰는 쪽이든 공개된 제품을 쓰는 쪽이든 같습니다. 책은 직관과 경험, 그리고 사용자가 무엇을 원하는지에 대한 이해를 써서 서비스 수준 지표와 서비스 수준 목표, 서비스 수준 계약(SLA, Service Level Agreement)을 정의한다고 적습니다. 이 세 낱말이 적힌 자리가 그 책의 4장입니다.
숫자를 정할 때 100퍼센트로 잡으면 될 것 같습니다. 후속인 사이트 신뢰성 엔지니어링 워크북은 그것이 틀린 목표라고 적습니다. 목표가 고객 만족과 맞물려 있다면 100퍼센트는 합리적인 목표가 아니라고 적습니다. 부품을 여러 벌 두고 상태 점검을 자동화하고 장애 조치를 즉시 하도록 해 두어도, 부품 하나 이상이 동시에 고장 날 확률은 0 이 아닙니다. 그러면 가용성은 100퍼센트 아래로 내려갑니다. 시스템 안에서 100퍼센트를 이뤄 낸다 해도 고객이 겪는 것은 100퍼센트가 아니라고 적습니다. 나와 고객 사이에 놓인 시스템의 사슬은 흔히 길고 복잡합니다. 그중 어느 부품이든 고장 날 수 있습니다.
예시
API 서비스의 4주 목표
사이트 신뢰성 엔지니어링 워크북은 어떤 API 서비스의 4주치 지표를 이렇게 적습니다. 전체 요청은 3,663,253건입니다. 성공한 요청은 3,557,865건으로 97.123퍼센트입니다. 90번째 백분위수 지연은 432밀리초, 99번째 백분위수 지연은 891밀리초입니다.
이 값을 놓고 제안한 목표는 셋입니다. 같은 책은 그 목표를 4주 구간의 오류 예산으로도 바꿔 적습니다.
| 제안된 목표 | 4주 동안 허용되는 실패 |
|---|---|
| 가용성 97퍼센트 | 109,897건 |
| 요청의 90퍼센트가 450밀리초 안에 | 366,325건 |
| 요청의 99퍼센트가 900밀리초 안에 | 36,632건 |
목표값과 집계 구간이 한 줄에 같이 들어가 있습니다. 4주라는 구간을 빼면 허용되는 실패 건수가 안 나옵니다.
Kubernetes 의 API 호출 지연 목표
목표선은 서비스를 굴리는 쪽만 긋는 것이 아닙니다. Kubernetes 커뮤니티 저장소의 확장성 분과 문서는 프로젝트가 자기 자신에게 건 목표를 적어 둡니다. 공식으로 표시된 정상 상태 목표는 이렇습니다.
단일 객체에 대한 변경 API 호출의 처리 지연입니다. 리소스와 동사 쌍마다 최근 5분의 99번째 백분위수로 잽니다. 기본 설치에서 가상 리소스와 집계 리소스, 커스텀 리소스 정의(CRD, Custom Resource Definition)를 뺀 모든 쌍에 대해 클러스터-일 단위 99번째 백분위수가 1초 이하여야 합니다.
스트리밍이 아닌 읽기 전용 API 호출의 처리 지연입니다. 리소스와 스코프 쌍마다 최근 5분의 99번째 백분위수로 잽니다. 기본 설치에서 가상 리소스와 집계 리소스, 커스텀 리소스 정의(CRD)를 뺀 모든 쌍에 대해, 스코프가 리소스면 클러스터-일 단위 99번째 백분위수가 1초 이하여야 합니다. 스코프가 네임스페이스나 클러스터면 30초 이하여야 합니다.
스케줄 가능한 무상태 파드의 기동 지연입니다. 이미지를 받는 시간과 init 컨테이너를 도는 시간은 뺍니다. 파드 생성 타임스탬프부터 모든 컨테이너가 시작됐다고 보고되어 watch 로 관측될 때까지를 잽니다. 최근 5분의 99번째 백분위수로 재고, 기본 설치에서 클러스터-일 단위 99번째 백분위수가 5초 이하여야 합니다.
Google Cloud 모니터링의 목표 필드
Google Cloud 모니터링 문서는 서비스 수준 목표를 일정 기간에 걸쳐 잰 서비스 수준 지표의 목표값이라고 적습니다. 서비스가 어떤 지표를 쓸 수 있는지 정하고, 사용자는 그 지표를 바탕으로 목표를 지정합니다. 목표가 무엇을 양호한 서비스로 칠지 정한다고 적습니다.
같은 문서는 목표가 세 가지 정보 위에 세워진다고 적습니다. 서비스의 성능을 재는 서비스 수준 지표입니다. 원하는 성능 수준을 지정하는 성능 목표입니다. 그리고 지표를 성능 목표와 견주는 기간인 준수 기간입니다.
문서가 든 요구 문장은 이렇습니다. 지연이 300밀리초를 넘는 것은 이동하는 30일 구간에서 요청의 5퍼센트 안에서만 허용됩니다. 시스템은 달력 주 단위로 재어 99퍼센트 가용성을 가져야 합니다.
경계
계약서에 99.9퍼센트라고 적혀 있으면 그게 서비스 수준 목표인가. 아닙니다.
사이트 신뢰성 엔지니어링 책은 서비스 수준 계약을 사용자와 맺는 명시적이거나 묵시적인 계약이라고 적습니다. 그 계약은 안에 담긴 목표를 지켰을 때 또는 못 지켰을 때 따르는 결과를 포함한다고 적습니다. 결과는 환급이나 위약금 같은 금전 형태일 때 가장 알아보기 쉽습니다. 다만 다른 형태를 띨 수도 있다고 적습니다.
그래서 둘을 가르는 손쉬운 방법은 하나를 물어보는 것입니다. 목표를 못 지키면 어떻게 되는가. 명시적인 결과가 없으면 거의 틀림없이 서비스 수준 목표를 보고 있는 것이라고 책은 적습니다.
flowchart TD
A["지표에 숫자를 못 박아 뒀다"] --> B{"못 지키면 따르는 결과가 명시돼 있나"}
B -->|있다| C["서비스 수준 계약"]
B -->|없다| D["서비스 수준 목표"]
같은 숫자가 두 자리에 나란히 놓이지도 않습니다. 책은 안전 여유를 두라고 적습니다. 사용자에게 알린 목표보다 내부 목표를 더 빡빡하게 잡아 두면 만성적인 문제가 밖에서 보이기 전에 대응할 여지가 생긴다고 적습니다. Google Cloud 모니터링 문서도 같은 지침을 적습니다. 목표는 보통 공개된 약속이나 계약상 약속보다 엄격합니다. 그렇게 해 두면 목표를 어기는 일이 생겨도 약속이나 계약을 어기기 전에 알아채고 고칠 수 있다고 적습니다.
관련 항목
이것과 같은 장에서 정의되는 용어
이것이 지키는 성질
목표선을 거는 지표
가용성 · 지연 · 요청 성공률 · 초당 질의 수 · 백분위수 · 준수 기간 · 오류율 · 처리량
목표를 지키려고 두는 수단
다중화 · 상태 점검 · 장애 조치 · 모니터링 · 경보 · 관측성 · 대시보드
이 목표에서 파생되는 값
오류 예산 · 번 레이트
다른 이름: SLO · Service Level Objective