Error Budget
Error Budget
지난 글에서 SLI / SLO / SLA를 정리했다.
이번엔 SLO를 배우고 나면 자연스럽게 나오는 질문,
"그래서 얼마나 실패해도 되는 거야?" 에 대한 답인
Error Budget을 정리해본다.
왜 필요한가
SLO를 정하고 나면 팀 안에서 이런 상황이 생긴다.
상황
개발팀: "새 기능 배포하고 싶은데요"
SRE팀: "배포하면 장애 날 수도 있어요. 위험합니다"
개발팀: "그럼 언제 배포할 수 있어요?"
SRE팀: "..."
SRE팀이 배포를 막는 역할이 되면 개발팀과 계속 충돌한다.
이걸 없애려면 "얼마나 실패해도 되는가"를 미리 숫자로 정해야 한다.
그게 Error Budget이다.
공식
Error Budget = 100% - SLO
SLO가 99.9%라면
Error Budget = 100% - 99.9% = 0.1%
0.1%가 체감이 잘 안 돼서 한 달(30일) 기준 분 단위로 바꾸면
한 달 총 분 = 30 × 24 × 60 = 43,200분
허용 다운타임 = 43,200 × 0.001 = 43.2분
SLO 99.9% = 한 달에 43분까지는 서버가 죽어도 괜찮다는 뜻이다.
SLO별로 얼마나 차이나는지
직접 비교해보면 차이가 크게 느껴진다.
| SLO | 한 달 허용 다운타임 |
|---|---|
| 99% | 7시간 18분 |
| 99.9% | 43분 |
| 99.99% | 4분 19초 |
| 99.999% | 26초 |
배포 결정에 어떻게 쓰이는가
버짓이 얼마나 남았냐에 따라 배포 여부를 결정한다.
버짓 50% 이상 남음 → 대규모 배포 가능
버짓 20~50% 남음 → 소규모 배포만 허용
버짓 20% 미만 남음 → 배포 중단, 안정성 개선 집중
버짓 소진 → 모든 배포 금지
이렇게 하면 "배포해도 돼요?" 가 주관적인 판단이 아니라
데이터 기반 대화가 된다.
가장 중요한 관점
처음 배울 때 이렇게 오해하기 쉽다.
❌ 버짓이 있으니까 그냥 실패해도 된다
❌ 버짓을 최대한 아껴야 한다
✅ 버짓은 혁신(배포)을 위한 연료다
버짓이 남아있을 때 배포를 망설이는 것 자체가 낭비다.
버짓은 다음 달로 이월되지 않는다.
다 쓰지 않고 달이 끝나면 그냥 사라진다.
반대로 버짓이 소진됐을 때 배포를 강행하는 것도 문제다.
버짓 소진은 "이번 달 시스템이 많이 불안정했다"는 신호인데,
원인도 모르는 상태에서 변경을 추가하면 위험이 겹친다.
버짓이 소진되는 원인
한 가지 더 알게 된 것이 있다.
버짓 소진이 꼭 개발팀 배포 때문만은 아니라는 점이다.
-
개발팀 신규 배포 중 장애
-
인프라 문제로 서버 다운
-
외부 의존성 장애 (DB, 결제 API 등)
-
예측 불가한 자연 발생 장애
외부 API가 다운돼서 내 서비스가 영향을 받아도 버짓이 소진된다.
그래서 버짓이 소진됐을 때 개발팀만 탓할 수 없고,
SRE팀이 같이 원인을 찾아야 한다.
정리
개념 한 줄 요약 Error Budget 실패해도 되는 허용 범위 (100% - SLO) 버짓 남음 적극적으로 배포하고 실험 버짓 소진 배포 중단, 원인 분석 먼저 버짓 리셋 다음 달 돼도 원인 모르면 또 소진됨
