서비스 수준 지표

서비스가 어떻게 돌고 있는지를 수치 하나로 재는 값입니다. 무엇을 어떤 방법으로 잴지가 미리 정해져 있습니다. 서비스가 멀쩡하다는 말을 사람마다 다른 뜻으로 쓰지 않게 붙잡아 주는 것이 이 값의 일입니다.

상세

집을 구할 때 어느 집이 괜찮으냐를 말로만 따지면 결론이 안 납니다. 그래서 볼 것을 둘로 줄입니다. 평일 아침에 집을 나서서 회사에 닿기까지 걸리는 시간과 한 달에 나가는 돈을 늘 같은 방법으로 재면 괜찮은 집이라는 말이 서로 같은 뜻이 됩니다.

서비스 수준 지표는 제공되는 서비스 수준의 어떤 측면을 신중하게 정의해 정량으로 잰 값입니다. 영어로는 SLI(Service Level Indicator)라고 씁니다. 정의를 신중하게 한다는 대목이 이 값의 절반을 차지합니다. 서비스는 무엇을 잴지부터 사람이 골라야 합니다. 무엇을 재는지가 흔들리면 같은 이름의 값이 자리마다 다른 뜻이 됩니다.

대부분의 서비스는 요청 지연을 핵심 지표로 봅니다. 요청에 응답을 돌려주기까지 걸리는 시간입니다. 흔히 쓰이는 다른 지표로는 오류율이 있습니다. 받은 전체 요청 중 얼마가 실패했는지의 비율로 적는 일이 많습니다. 처리량도 그런 지표입니다. 보통 초당 요청 수로 잽니다.

측정값은 대개 집계됩니다. 원자료를 측정 창 동안 모읍니다. 그 다음 비율이나 평균, 백분위로 바꿉니다. 그래서 지표 하나에는 재는 대상뿐 아니라 창의 길이와 통계 방식까지 딸려 있습니다.

flowchart TD
    원자료 --> 창["측정 창"]
    창 --> 집계["비율 · 평균 · 백분위"]
    집계 --> 값["지표 값"]

이상적으로는 지표가 관심 있는 서비스 수준을 직접 잽니다. 다만 원하는 측정값을 얻거나 해석하기가 어려울 수 있습니다. 그럴 때는 대리 지표만 쓸 수 있는 경우도 있습니다.

배경

서비스에서 어떤 동작이 정말 중요한지, 그 동작을 어떻게 재고 평가할지를 모르면 서비스를 제대로 관리할 수 없습니다. Google 의 SRE(Site Reliability Engineering, 사이트 신뢰성 엔지니어링) 책은 잘 관리하는 것은 고사하고 올바르게 관리하는 것조차 불가능하다고 적습니다. 멀쩡하냐 아니냐를 말로만 주고받으면 서비스를 굴리는 쪽과 쓰는 쪽이 서로 다른 것을 뜻하게 됩니다.

그래서 필요했던 것은 사용자에게 전달할 서비스 수준을 먼저 정의하는 일입니다. 직관과 경험, 그리고 사용자가 무엇을 원하는지에 대한 이해를 써서 재는 값을 세웁니다. 그렇게 세운 값을 서비스 수준 지표라고 부릅니다. 그 위에 목표와 협약이 얹힙니다.

모니터링 시스템이 추적할 수 있는 모든 메트릭을 지표로 쓰면 안 됩니다. 사용자가 시스템에서 무엇을 원하는지를 이해해야 그중 몇 개를 분별 있게 골라낼 수 있습니다. 너무 많이 고르면 정작 중요한 지표에 알맞은 주의를 주기가 어려워집니다. 너무 적게 고르면 시스템의 중요한 동작이 살펴지지 않은 채 남을 수 있습니다. 대표 지표 몇 개면 시스템의 건강을 평가하고 따져 보기에 대체로 충분합니다.

예시

Google SRE 워크북

워크북은 지표를 두 수의 비율로 다루기를 대체로 권합니다. 기준을 만족한 이벤트(good events) 수를 전체 이벤트 수로 나눈 값입니다. 워크북이 드는 예는 셋입니다. HTTP(HyperText Transfer Protocol) 요청, gRPC 호출, 검색 결과입니다.

성공한 HTTP 요청 수 / 전체 HTTP 요청 수
성공적으로 끝난 gRPC 호출 수 / 전체 gRPC 호출 수
전체 코퍼스를 사용한 검색 결과 수 / 우아하게 저하된 것을 포함한 전체 검색 결과 수

첫 줄이 성공률입니다. 분자와 분모가 무엇을 세는지가 지표 정의의 전부입니다. 워크북은 고객에게 가장 중요한 기능을 대표하는 지표 유형을 다섯 개 이하의 적은 수로 고르라고 권합니다. 가용성은 성공 응답으로 끝난 요청의 비율입니다. 요청 기반 지연은 어떤 임계값보다 빨랐던 요청의 비율입니다.

여기까지가 지표입니다. 워크북은 이어서 목표 쪽을 짚습니다. 가용성과 지연의 서비스 수준 목표는 꽤 흔합니다. 신선도와 내구성, 정확성, 품질, 커버리지의 서비스 수준 목표도 각자 자리가 있습니다.

Google Cloud Monitoring

Cloud Monitoring 은 지표를 두 갈래로 나눠 정의합니다. request-based 지표는 서비스의 원자적 단위를 셉니다. 성공한 HTTP 요청 수 같은 것입니다. windows-based 지표는 성능이 기준을 만족한 시간 구간의 수를 셉니다. 응답 지연이 정해진 임계값 아래로 내려간 구간 같은 것입니다.

컴플라이언스는 준수 기간 동안 잰 기준 만족 이벤트 수를 전체 이벤트 수로 나눈 비율입니다. 목표가 99.9% 라면 컴플라이언스가 99.9% 이상일 때 그 목표를 지킨 것입니다. 최댓값은 100% 입니다. windows-based 쪽의 실제 문구는 이렇게 생겼습니다.

95번째 백분위 지연 메트릭이 10분 창의 99% 이상에서 100ms 미만

여기서 창의 길이와 백분위, 임계값이 전부 문장 안에 못 박혀 있습니다. 세 값 중 하나만 바뀌어도 다른 지표입니다.

쿠버네티스

쿠버네티스 커뮤니티는 확장성 정의를 지표와 목표 두 개념 위에 세웁니다. 지표는 무엇을 어떻게 재는지만 정하는 일반형입니다. 구체적인 보장은 목표가 냅니다. 커뮤니티는 지표와 목표가 정밀하고 잘 정의돼 있기를 요구합니다. 사용자와 프로젝트가 무엇을 보장하는지를 똑같이 이해하는 것이 몹시 중요하기 때문입니다. 실제로 발행하는 공식 지표에는 API(Application Programming Interface) 호출 지연과 파드 기동 지연이 있습니다.

비스트리밍 읽기 전용 API 호출의 처리 지연
  (리소스, 스코프) 쌍마다, 기본 쿠버네티스 설치에서 최근 5분에 대한 99번째 백분위로 잰다
  클러스터-일당 99번째 백분위: scope=resource 이면 1초 이하,
  scope=namespace 나 scope=cluster 면 30초 이하

스케줄 가능한 스테이트리스 파드의 기동 지연
  이미지를 받는 시간과 init 컨테이너 실행 시간은 뺀다
  파드 생성 타임스탬프부터 모든 컨테이너가 시작됐다고 보고되고 watch 로 관측될 때까지
  기본 쿠버네티스 설치에서 최근 5분에 대한 99번째 백분위
  클러스터-일당 99번째 백분위: 5초 이하

무엇을 어느 단위로, 어느 창에서, 어떤 통계로 재는지를 적은 앞부분이 지표입니다. 1초, 30초, 5초 같은 수치는 그 위에 얹힌 목표입니다.

경계

가용성을 99.9% 로 지키겠다는 약속도 서비스 수준 지표인가. 아닙니다. 지표는 무엇을 어떻게 재는지와 그렇게 나온 값까지입니다. 목표값이나 값의 범위가 붙는 순간 그것은 SLO(Service Level Objective, 서비스 수준 목표)입니다. Google SRE 책은 목표의 자연스러운 구조를 목표치 이하의 지표, 또는 하한 이상 상한 이하의 지표로 적습니다. 약속이라는 말이 붙었다는 것 자체가 이미 지표 바깥으로 한 칸 나갔다는 뜻입니다.

flowchart TD
    지표["지표 · 무엇을 어떻게 재나"] -->|"목표값을 붙인다"| 목표["목표"]
    목표 -->|"못 지켰을 때의 결과를 붙인다"| 협약["협약"]

서비스 수준 지표

상세

배경

예시

Google SRE 워크북

Google Cloud Monitoring

쿠버네티스

경계

관련 항목

이 지표 위에 얹히는 목표·협약·예산

이 지표가 재는 대상

이 지표를 재는 방법과 도구

이 지표를 실제로 정의한 예시에 나오는 프로토콜·제품

이 지표를 다루는 SRE 실무와 도구