오류율

전체 요청 가운데 실패한 것이 차지하는 비율입니다. 시스템이 얼마나 자주 약속을 못 지켰는지를 숫자 하나로 보여줍니다. 무엇을 실패로 셀지는 재는 쪽이 정합니다.

상세

택배 100개를 보냈는데 3개가 주소를 못 찾고 돌아왔습니다. 오류율은 돌아온 3이라는 개수가 아니라 100분의 3이라는 비율입니다.

오류율은 전체 가운데 오류로 판정된 것이 차지하는 비율입니다. 요청을 세는 자리에서는 분모가 받은 요청 전체이고 분자는 그중 실패한 요청입니다. 정의가 정하는 것은 여기까지입니다.

실패는 세 갈래로 갈립니다. 명시적 실패는 응답이 스스로 실패라고 말하는 것입니다. HTTP(HyperText Transfer Protocol) 500 번대 응답이 여기 듭니다. 암묵적 실패는 응답이 성공이라고 말하는데 내용이 틀린 것입니다. 200 성공 응답에 엉뚱한 본문이 실려 나가는 경우가 그렇습니다. 정책상 실패는 약속을 못 지킨 것입니다. 1초 안에 응답하기로 약속했다면 1초를 넘긴 요청은 오류입니다.

flowchart TD
    A[요청 하나] --> B{응답이 실패라고 말하나}
    B -->|예| E[오류로 센다]
    B -->|아니오| C{성공인데 내용이 틀렸나}
    C -->|예| E
    C -->|아니오| D{약속한 선을 넘겼나}
    D -->|예| E
    D -->|아니오| F[성공으로 센다]

정책상 실패라는 갈래가 정의 안에 들어 있다는 것은, 무엇을 오류로 셀지가 그 서비스가 무엇을 약속했느냐에 달려 있다는 뜻입니다.

배경

먼저 있던 방식은 가동 시간으로 신뢰성을 재는 것이었습니다. 시스템이 떠 있던 시간을 전체 시간으로 나눈 값입니다. 이 값은 시스템이 한 덩어리로 서 있거나 누워 있을 때 뜻이 통합니다.

사이트 신뢰성 엔지니어링 책은 전 세계에 흩어져 도는 서비스에서는 그 전제가 깨진다고 적습니다. 고장이 서로 번지지 않게 떼어 두면 어느 순간에도 그 서비스의 트래픽 일부는 세계 어딘가에서 처리되고 있을 가능성이 매우 높습니다. 그러면 시스템은 언제나 적어도 부분적으로는 떠 있는 상태이고, 가동 시간 기반 지표는 대체로 뜻을 잃습니다.

필요한 것은 시간이 아니라 요청 단위로 세는 지표였습니다. 그래서 그 책은 가용성을 가동 시간 대신 요청 성공률로 다시 정의합니다. 성공하지 못한 쪽이 차지하는 비율에 붙은 이름이 오류율입니다.

예시

Prometheus 질의

관측 시스템에서 오류율은 요청을 세는 계수기 위에서 만들어집니다. Prometheus 공식 문서는 요청 계수기의 지난 5분간 초당 증가율을 이렇게 적습니다.

rate(http_requests_total[5m])

http_requests_total 이라는 이름을 가진 모든 시계열에 대해 초당 비율을 돌려줍니다. [5m] 이 되돌아보는 창의 크기입니다. 오류율의 분모가 되는 전체 요청 쪽이 이 모양으로 놓입니다.

서비스 수준 목표의 임계치

서비스 수준 목표(Service Level Objective, SLO)는 오류율에 선을 긋는 자리입니다. 사이트 신뢰성 엔지니어링 워크북은 어느 API(Application Programming Interface)의 목표를 이렇게 제안합니다. 가용성 97%, 요청의 90%가 450밀리초 미만, 요청의 99%가 900밀리초 미만입니다. 재는 구간으로는 4주 이동 창이 범용으로 쓸 만한 값이었다고 적습니다.

에러 버짓은 100%에서 목표를 뺀 값입니다. 성공률 목표가 99.9%이고 4주 동안 300만 건을 받았다면 그 기간의 예산은 오류 3,000건입니다. 하루 250만 건을 처리하는 시스템의 일일 가용성 목표가 99.99%라면 하루 250건까지 오류를 내고도 그날의 목표를 맞춥니다.

OpenTelemetry 계측 규약

무엇을 오류로 셀지는 계측 단계에서 이미 갈립니다. OpenTelemetry 시맨틱 규약의 HTTP 서버 메트릭은 error.type 속성을 둡니다. 연산이 어떤 종류의 오류로 끝났는지를 적는 자리입니다.

값은 셋 중 하나입니다. 예외 타입(해당하는 경우 그 전체 이름), 문자열로 적은 상태 코드 숫자, 구성 요소별로 정한 낮은 카디널리티 오류 식별자입니다. 응답 상태 코드가 오가기 전에 요청이 실패하면 예외 타입을 넣도록 권고합니다. 상태 코드가 오갔고 그것이 오류를 가리키면 그 숫자를 문자열로 넣도록 권고합니다. 요청이 성공으로 끝나면 이 속성을 넣지 않도록 권고합니다. 계측기가 자기 값을 따로 정하지 않았을 때 쓰는 대체 값이 _OTHER 입니다.

이 권고를 따른 계측이라면 성공한 요청에는 이 속성이 붙지 않습니다. 다만 세 조건 모두 권고이지 강제는 아닙니다.

경계

4xx 응답도 오류율에 드나. 서버가 약속을 못 지킨 정도를 재는 오류율이라면 안 듭니다.

RFC(Request for Comments) 9110 은 4xx 를 클라이언트가 잘못한 것으로 보이는 상태 코드 부류라고 적습니다. 400 Bad Request 는 잘못된 요청 문법이나 잘못된 메시지 프레이밍처럼 클라이언트 잘못으로 보이는 것 때문에 서버가 요청을 처리할 수 없거나 하지 않겠다고 판단한 경우입니다. 5xx 는 반대편입니다. 서버가 자기가 잘못했음을 알고 있거나 요청된 메서드를 수행할 수 없는 부류이고, 500 Internal Server Error 는 예상치 못한 조건 때문에 요청을 채우지 못한 경우입니다. 잘못의 소재를 명세가 이렇게 갈라 적어 두었습니다.

다만 이 선을 긋는 것은 정의가 아니라 정책입니다. 상세에서 본 세 갈래 중 정책상 실패가 이 자리입니다. 어떤 4xx 를 그 서비스의 실패로 세기로 약속하면 그때부터 그것은 오류입니다.

이 표제어에 안 드는 것도 하나 짚습니다. 변경 실패율은 배포 직후 즉시 개입이 필요했던 배포의 비율입니다. 분모가 요청이 아니라 배포입니다. 이름이 닮았지만 세는 대상이 다릅니다.

가용성은 경우가 다릅니다. 가용성을 요청 성공률로 정의하면 오류율과 같은 수의 앞뒷면입니다.

상세

배경

예시

Prometheus 질의

서비스 수준 목표의 임계치

OpenTelemetry 계측 규약

경계

관련 항목

함께 재는 골든 시그널

오류율 위에 얹히는 목표·예산

오류 여부를 가르는 상태 코드

세는 대상이나 이름이 헷갈리는 이웃 개념

오류가 오가는 통신·계측 규약

오류율을 실측하는 도구·체계