오류 예산

오류 예산은 서비스가 한 달 같은 기간에 얼마만큼 실패해도 되는지를 숫자로 허락해 줍니다. 그 숫자는 미리 세운 성공률 목표에서 셈해 나옵니다. 팀은 남은 예산을 보고 새 기능을 더 내보낼지 안정화부터 할지 정합니다.

쉽고 빠른 이해

오류 예산은 「이번 달에 이만큼까지는 실패해도 된다」는 한도입니다. 성공률 목표를 99.9퍼센트로 잡으면 요청 천 건 가운데 한 건은 실패해도 목표를 지킨 것입니다.

안정성만 따지면 아무것도 안 바꾸는 편이 제일 안전합니다. 기능 개발만 따지면 매일 배포하고 싶습니다. 두 쪽이 감으로 다투지 않도록 같은 숫자 하나를 놓고 정합니다.

어떻게 도는가:

1. 한 달 동안 지킬 성공률 목표를 정합니다
2. 100퍼센트에서 목표를 뺀 만큼이 이번 달 예산입니다
3. 실패한 요청이 생길 때마다 예산이 줄어듭니다
4. 예산이 남으면 배포를 이어 갑니다. 바닥나면 위험한 배포를 멈춥니다

대가가 있습니다. 목표를 잘못 잡으면 예산도 틀립니다. 바닥났을 때 무엇을 멈출지 미리 합의해 두지 않으면 숫자만 남고 아무것도 안 바뀝니다.

상세

이 절은 세 가지를 봅니다. 오류 예산이 어디서 나오는지, 어떻게 셈하는지, 팀이 그 숫자로 무엇을 정하는지입니다. 30일 동안 성공률 99.9퍼센트를 지키겠다는 웹 서비스 하나를 줄곧 예로 씁니다.

한 달 용돈을 떠올리면 가깝습니다. 용돈이 남아 있으면 사고 싶은 것을 사고, 바닥나면 다음 달까지 참습니다. 다만 용돈은 내가 언제 쓸지 고릅니다. 오류 예산은 장애가 내 뜻과 상관없이 꺼내 씁니다.

목표에서 셈해 나오는 값

오류 예산은 두 낱말 위에 섭니다. 먼저 서비스 수준 지표(SLI, Service Level Indicator)입니다. 서비스가 잘 돌고 있는지를 숫자로 잰 값입니다. 전체 요청 가운데 성공한 요청의 비율이 흔한 예입니다.

다음은 서비스 수준 목표(SLO, Service Level Objective)입니다. 지표가 넘어야 할 선을 기간과 함께 정한 것입니다. 「30일 동안 성공률 99.9퍼센트 이상」이 그 꼴입니다. 앞에서 성공률 목표라고 부른 것이 바로 이것입니다.

오류 예산은 100퍼센트에서 이 목표를 뺀 나머지입니다. 목표가 99.9퍼센트면 예산은 0.1퍼센트입니다. 목표를 어기지 않고 실패할 수 있는 몫이 이만큼이라는 뜻입니다.

flowchart TD
    A["서비스 수준 지표 · 성공한 요청의 비율"] --> B["서비스 수준 목표 · 30일 동안 99.9퍼센트 이상"]
    B --> C["오류 예산 · 100 - 99.9 = 0.1퍼센트"]
    C --> D["팀의 판단 · 배포를 이어 갈까 멈출까"]

그림의 맨 아래 칸이 이 값의 쓸모입니다. 예산은 숫자로 끝나지 않고 팀의 판단으로 이어집니다. 거꾸로 지표나 목표가 없는 서비스에는 오류 예산도 없습니다.

요청 수와 시간으로 바꾸기

0.1퍼센트라는 비율만으로는 감이 안 옵니다. 그래서 흔히 요청 수나 시간으로 바꿔 봅니다.

요청으로 세면 이렇습니다. 30일 동안 요청이 1,000만 건 들어오면 0.1퍼센트는 1만 건입니다. 실패한 요청이 1만 건을 넘기 전까지는 목표를 지킨 것입니다.

시간으로 세면 이렇습니다. 30일은 43,200분입니다. 그 0.1퍼센트는 43.2분입니다. 서비스가 전부 멈추는 장애라면 한 달에 43분 남짓까지 버틸 수 있다는 뜻입니다.

두 방법은 쓰임이 다릅니다. 시간으로 세는 방법은 서비스가 전부 멈추는 장애에 맞습니다. 요청의 일부만 실패하는 장애에는 요청으로 세는 방법이 실제 피해에 더 가깝습니다.

목표에 9를 하나 더 붙일 때마다 예산은 열 배로 줄어듭니다. 아래 표는 30일 기준으로 셈한 값입니다.

맨 아랫줄을 보면 4분 남짓입니다. 사람이 알림을 받고 노트북을 여는 사이에 예산이 바닥나기 쉽습니다. 그래서 목표를 한 단계 올리면 사람이 손대기 전에 자동으로 되돌리는 식의 대응이 필요해집니다.

기간을 자르는 두 방법

예산을 셈하는 기간을 준수 기간이라고 부릅니다. 이 기간을 어떻게 자르느냐에 따라 예산이 다시 차는 모양이 달라집니다.

하나는 달력 단위입니다. 매달 1일에 기간이 새로 시작합니다. 월말에 예산을 다 써도 다음 달 1일이면 한꺼번에 다시 찹니다.

다른 하나는 이동 구간입니다. 언제나 「지금부터 거슬러 30일」을 봅니다. 오래된 실패가 하루씩 구간 밖으로 빠지면서 예산이 조금씩 돌아옵니다. 대신 달력 단위처럼 1일에 한꺼번에 털고 가지 못합니다. 큰 장애 하나가 30일 동안 예산을 누릅니다.

100퍼센트를 목표로 잡지 않는 까닭

목표가 100퍼센트면 예산은 0입니다. 실패가 한 건만 나도 목표를 어긴 것이 됩니다.

어떤 변경이든 실패를 낼 수 있습니다. 그러니 이 목표를 지키는 확실한 길은 아무것도 안 바꾸는 것입니다. 배포도, 설정 변경도, 장비 교체도 멈추게 됩니다.

사용자 쪽에서 봐도 100퍼센트는 닿지 않습니다. 사용자와 서비스 사이에는 사용자의 와이파이, 통신망, 기기가 끼어 있습니다. 그것들도 실패합니다. 서비스가 조금 더 안정해져도 사용자가 겪는 차이는 그 실패에 묻히기 쉽습니다.

그래서 오류 예산은 「실패를 0으로 만들자」는 약속이 아닙니다. 「이만큼의 실패는 받아들이고, 그 대신 변경을 계속하자」는 약속입니다.

배포 속도와 안정성 사이의 판정

기능을 만드는 쪽은 자주 배포하고 싶습니다. 서비스를 운영하는 쪽은 조심하고 싶습니다. 배포가 장애의 흔한 원인이기 때문입니다. 둘이 감으로 다투면 목소리 큰 쪽이 이깁니다.

오류 예산은 이 다툼을 숫자 하나로 옮깁니다. 예산이 넉넉하면 위험을 좀 져도 됩니다. 새 기능을 내보내거나 실험을 하거나 배포 주기를 당깁니다.

예산이 바닥나면 순서가 바뀝니다. 위험한 배포를 멈춥니다. 장애 원인을 고쳐 신뢰도를 올리는 일을 먼저 합니다. 예산이 다시 찰 때까지 이어 갑니다.

이 규칙은 장애가 나기 전에 글로 적어 둡니다. 이것을 오류 예산 정책이라고 부릅니다. 예산을 다 쓰면 무엇을 멈추는지, 누가 결정하는지, 무엇을 예외로 두는지를 평소에 합의해 둡니다. 보안 수정이나 장애를 고치는 배포는 흔히 예외로 둡니다.

예산이 줄어드는 속도

남은 예산만 보면 늦게 알아챕니다. 한 달 예산이 절반 남았어도 지금 속도라면 내일 바닥날 수 있습니다.

그래서 예산을 쓰는 속도도 봅니다. 이 속도를 번 레이트라고 부릅니다. 소진율이라고도 합니다. 기간 내내 고르게 써서 기간이 끝나는 순간 딱 바닥나는 속도를 1로 잡습니다.

번 레이트가 2면 30일 예산이 15일 만에 바닥납니다. 10이면 3일 만입니다. 값이 클수록 급한 상황입니다.

이 속도를 보고 알림을 겁니다. 빠르게 줄어들면 담당자를 바로 부릅니다. 느리게 새면 업무 시간에 살펴볼 일감으로 남기는 식입니다. 알림이 늦게 울릴수록 그사이에 예산이 더 빠져나갑니다.

무엇을 실패로 세나

예산은 사용자가 겪은 실패로 줄어듭니다. 원인이 우리 코드의 버그든, 우리가 부르는 외부 서비스의 장애든 사용자 눈에는 같은 실패입니다. 그래서 보통 원인을 가리지 않고 셉니다.

무엇을 실패로 칠지는 지표를 정할 때 함께 정합니다. 응답이 오래 걸린 요청을 실패로 칠지, 미리 알린 점검 시간을 셈에 넣을지가 그런 결정입니다. 이 결정이 바뀌면 같은 장애도 예산을 다르게 깎습니다.

관련 항목

오류 예산을 셈하는 바탕이 되는 지표와 목표

서비스 수준 지표 · 서비스 수준 목표 · 서비스 수준 계약 · 가용성 · 요청 성공률 · 오류율 · 지연 · 준수 기간

오류 예산을 지켜보는 수단

번 레이트 · 알림 · 모니터링 · 대시보드 · 관측성

오류 예산을 깎아 먹는 변경 작업

배포 · 카나리 배포 · 지속적 배포 · 배포 빈도 · 롤백 · 기능 플래그

예산이 바닥났을 때 따르는 규칙과 절차

오류 예산 정책 · 배포 동결 · 포스트모템 · 장애 대응

오류 예산이 속하는 상위 분류

사이트 신뢰성 엔지니어링 · 신뢰성 · 데브옵스