The Error Budget Is a Negotiating Tool

한 줄 요약

기간 예산은 지금까지 쓴 몫이고 번 레이트는 최근 쓰는 속도다. 둘을 구별해야 배포를 허용할 때와 멈출 때를 설명할 수 있다.

왜 이게 필요했나

가상의 온라인 상점에서 새 기능을 배포하려 한다. 최근 한 시간은 조용하지만 지난주 장애로 30일 예산을 이미 초과했다. 반대로 월간 예산은 충분한데 지금 결제 요청이 빠르게 실패하는 날도 있다. 최근 오류율 하나만 보면 앞의 사고를 놓치고, 월간 숫자 하나만 보면 뒤의 사고에 대응하지 못한다. 사람이 보고서를 읽는 데서 끝내지 않고, 두 근거를 구분하는 작은 판단 프로그램을 만들어 보자. Python의 딕셔너리·조건문·JSON 입출력을 알고 있다고 가정한다.

어떻게 동작하나

먼저 누구의 어떤 실패를 셀지 정한다. 이 실습의 합성 HTTP 자료에서는 5xx를 실패, 나머지 관측 요청을 성공으로 정한다. 이것은 교육용 서비스의 정의이지 모든 4xx가 늘 고객 잘못이라는 뜻이 아니다. 서비스가 만든 잘못된 인증 응답이나 과부하 429가 사용자 실패라면 별도 SLI 정의가 필요하다. 봇·내부 점검 요청을 포함할지도 문서화하고 분자와 분모에 같은 범위를 적용한다.

요청 기반 99.9% SLO의 허용 오류 비율은 0.001이다. 같은 30일 동안 전체 요청이 백만 건이면 허용 오류 예산은 천 건이다. 실패가 200건이면 사용 비율은 200/1000=0.2, 즉 20%이고, 1200건이면 1.2로 예산을 초과했다. 이 계산에는 해당 30일 전체의 실패 건수와 요청 건수가 필요하다.

번 레이트는 짧은 창의 오류 비율을 허용 오류 비율로 나눈다. 1시간에 만 건 중 200건이 실패했다면 0.02/0.001=20배다. 12시간 창으로 계산해도 12시간 번 레이트일 뿐, 자동으로 월간 예산 사용량이 되지는 않는다. 창 길이는 단위를 바꾸지 않는다. 최근 속도가 20배여도 월간 사용 비율은 0.2일 수 있고, 지금 속도가 0이어도 지난 장애로 사용 비율이 1.2일 수 있다.

시간 기반 가용성 예산은 별도 개념이다. 30일은 43,200분이므로 99.9% 시간 SLO의 허용 불가용 시간은 43.2분이다. 99.99%면 4.32분, 즉 4분 19.2초다. 이 숫자를 요청 실패 건수와 바꾸어 쓰면 안 된다. 조용한 시간대의 1분과 주문이 몰리는 1분은 요청 기반 SLO에 다른 영향을 줄 수 있다. 실습 2단계는 시간 예산의 자릿수 연습이며 마지막 프로그램은 요청 예산을 사용한다.

14.4라는 알림 기준도 단위로 이해하자. 30일을 720시간으로 잡고 한 시간에 전체 예산의 2%를 쓰는 일정한 속도를 생각하면 0.02×720=14.4다. 남은 예산이 온전하고 요청량과 오류율이 일정하다고 가정하면 약 50시간의 소진 전망이 나온다. 이미 사용한 예산, 트래픽 변화, 롤링 창에서 빠져나갈 오래된 실패가 있으면 이 전망은 달라진다. 미래를 확정한 숫자로 말하지 않는다.

두 창은 왜 함께 보나

장애가 끝나도 1시간 평균에는 실패가 남는다. 1시간 번 레이트가 20이고 최근 5분이 0이면, 긴 창만 보고 계속 호출할 수 있다. 1시간과 5분이 모두 14.4를 초과해야 호출하는 조건은 최근에도 문제가 이어지는지 확인한다. and를 or로 바꾸면 이 해소 조건이 사라진다. 정확히 14.4는 초과가 아니다.

적은 요청도 주의한다. 5분 요청 세 건 중 한 건이 실패하면 비율은 크지만, 그 한 건이 중요한 주문인지 무해한 재시도인지 숫자만으로 알 수 없다. 최소 트래픽 조건을 무조건 붙여 모든 저트래픽 실패를 숨기지 않는다. 이 합성 실험은 요청 0건을 정상으로 추정하지 않고 보류한다. 실제 서비스는 업무 영향에 맞는 별도 정책과 트래픽 중단 감시가 필요하다.

현장에서 만나는 모습

자료를 가져오지 못했는데 빈 결과를 0으로 바꾸면 “장애 없음”으로 오인한다. 같은 서비스·종료 시각인지, 필요한 창 전체를 모았는지 먼저 확인한다. 실습 Prometheus에는 약 12시간의 합성 이력이 있다. 여기에 30일 쿼리를 썼다는 사실만으로 30일이 관측된 것은 아니다. 마지막 과제에서는 별도로 제공하는 합성 기간 집계를 사용하며 실제 Prometheus에서 추출한 월간 기록으로 위장하지 않는다.

이 가상 팀의 기능 배포 정책은 세 단계다. 자료가 불명확하면 hold, 기간 예산 사용 비율이 1 이상이면 freeze, 그 밖에도 1시간과 5분 번 레이트가 모두 14.4를 초과하면 freeze다. 나머지만 allow다. 사용 비율 경계는 이상, 속도 경계는 초과라는 차이에 주의한다. 보류와 동결은 모두 배포를 진행하지 않지만 이유가 다르다. 보류는 관측부터 복구하고, 예산 동결은 신뢰성 작업을 우선한다. 실제 조직의 긴급 보안 변경이나 롤백은 별도 승인 정책이 필요하며 이 프로그램이 승인하지 않는다.

다음 실습에서 할 것

실제 Prometheus에 성공 비율과 두 창의 번 레이트를 질의하고 알림 규칙을 검사한다. 마지막에는 합성 집계를 stdin으로 읽는 Python 프로그램을 작성한다. 월간 예산 초과, 진행 중 장애, 회복, 자료 누락을 서로 구분하며 보고서와 종료 코드를 남긴다. 새벽에 배포 버튼 앞에서 필요한 것은 자신감 있는 문장보다 확인 가능한 근거다.

참고: SRE의 SLO 알림 설계, 예산 정책 예시. 위의 30일·판정 경계·보류 규칙은 이 실습에서 명시한 교육용 정책이다.