에러 버짓은 협상 도구다

한 줄 요약

SLI 는 좋은 이벤트 수를 전체 이벤트 수로 나눈 값이고, SLO 는 그 목표치이며, 100% 에서 SLO 를 뺀 나머지가 실수해도 되는 예산이다.

왜 이게 필요했나

"안정성을 높이자"는 문장으로는 아무것도 결정되지 않는다. 얼마나 높일지, 그 대가로 무엇을 포기할지가 없기 때문이다. 에러 버짓은 이 논쟁을 숫자로 바꾼다. 이번 달 예산이 43.2분인데 이미 22분을 썼다면, 남은 21.2분을 어디에 쓸지가 회의 주제가 된다.

세 용어의 관계는 분명하다. SLI 는 측정값, SLO 는 목표치, SLA 는 SLO 에 계약적 결과가 붙은 것이다. 그래서 SLO 는 항상 SLA 보다 엄격해야 한다. SLA 가 99.9% 라면 SLO 는 99.95% 이상으로 잡는다. 계약을 어기기 전에 내부에서 먼저 경보가 울려야 하기 때문이다. 그리고 100% SLO 는 현실적으로 불가능하며 추구해서도 안 된다. 예산이 0이면 배포를 멈추는 것 말고 할 수 있는 일이 없다.

어떻게 동작하나

30일을 분으로 바꾸면 43,200분이다(30 × 24 × 60). 여기에 (100 − SLO)% 를 곱하면 월간 허용 시간이 나온다.

| SLO | 월간 예산 |
| --- | --- |
| 99% | 432분 |
| 99.5% | 216분 |
| 99.9% | 43.2분 |
| 99.95% | 21.6분 |
| 99.99% | 4.32분 |

번 레이트는 실제 오류율을 예산 비율로 나눈 값이다. 목표가 99.9% 일 때 예산 비율은 0.1% 이므로, 오류율 1.44% 는 번 레이트 14.4 다. 소진까지 걸리는 시간은 720시간을 번 레이트로 나눈 값이다. 14.4 면 50시간, 6 이면 120시간, 3 이면 240시간, 1 이면 720시간(30일)이다.

단일 윈도우 알림은 오탐을 만든다. 10:00~10:05 에만 오류율이 50% 였는데 1시간 평균이 4.2% 라 임계를 넘으면, 장애가 55분 전에 끝났는데도 온콜이 호출된다. 다중 윈도우는 짧은 창이 0% 라 발화하지 않는다. 짧은 창은 긴 창의 12분의 1 로 잡는 것이 관례이고, 짧은 창의 역할은 민감도가 아니라 해소 속도다.

현장에서 만나는 모습

내부 서비스에 99.99% SLO 를 걸었던 팀이 있었다. 월 예산이 4분 23초라 정상 배포조차 불가능해졌다. 99.9% 로 낮추고 카나리를 도입한 뒤에야 정책이 작동하기 시작했다.

최소 트래픽 게이트도 반드시 필요하다. 5분에 요청이 3건 들어오는 시간대에 1건이 실패하면 오류율은 33% 가 되고 모든 번 레이트 임계값을 한 번에 넘는다. 반대로 트래픽이 0이면 0/0 = NaN 이라 알림이 조용히 사라지므로, 처리량 급감 알림이 따로 필요하다.

지연 SLO 는 백분위가 아니라 비율로 정의해야 한다. 백분위는 집계할 수 없고 시간 축으로도 합칠 수 없다. 5분 창의 p99 를 30일치 모아 놓아도 30일의 p99 가 되지 않는다. "300ms 이내 응답 비율"로 정의하면 보간 오차가 없고, 어떤 시간 창으로도 재계산되며, 번 레이트 알림에 그대로 꽂힌다.

다음 실습에서 할 것

예산 표를 분 단위로 계산하고, 소진율과 번 레이트를 손으로 구하고, 다중 윈도우 알림을 YAML 로 정의한 뒤, 마지막에는 소진율을 인자로 받아 배포를 허용하거나 막는 게이트 스크립트를 직접 만듭니다.