SLO 에러 버짓 계산기
SLO & Error Budget Calculator
가용성 목표를 기간별 허용 다운타임과 에러 버짓으로 바꾸고, 소진 속도와 다중 윈도 경보 임계값까지 계산합니다. 의존성 가용성은 곱해진다는 점을 보여주어, 지금 구조로 그 SLO가 애초에 불가능한지 알려줍니다.
목표 SLO
3.00 나인
허용 다운타임
| 기간 | 허용 다운타임 |
|---|---|
| 하루 | 1m 26s |
| 일주일 | 10m 5s |
| 30일 | 43m 12s |
| 분기(90일) | 2h 9m 36s |
| 1년(365일) | 8h 45m 36s |
요청 기반 에러 버짓
허용 실패 요청 수9,999
소진 속도(Burn rate)
소진 속도
5.00×
1이면 기간 끝에 정확히 다 씁니다. 2면 절반 시점에 바닥납니다.
남은 버짓 소진까지
4d 19h 12m
다중 윈도 경보 임계값
| 관측 윈도 | 소진 속도 임계값 | 30일 버짓 소진량 |
|---|---|---|
| 1h즉시 호출 | 14.4× | 2.0% |
| 6h즉시 호출 | 6× | 5.0% |
| 24h티켓 | 3× | 10.0% |
| 72h티켓 | 1× | 10.0% |
경보 임계값(14.4 / 6 / 3 / 1)은 Google SRE 워크북의 30일 기준 권고값입니다. 서비스 특성에 따라 조정해야 하는 출발점이지 정답이 아닙니다.
의존성 구성
전부 살아 있어야 요청이 성공하는 의존성을 넣으세요. 가용성은 곱해집니다. 이 곱이 여러분이 약속할 수 있는 상한입니다.
달성 가능한 상한
99.750%
상한이 함의하는 30일 다운타임
1h 47m 55s
이 SLO는 지금 구조로 불가능합니다
99.9%를 약속했지만 필수 의존성만 곱해도 99.750%가 상한입니다. 코드를 한 줄도 쓰기 전에 이미 초과입니다. 목표를 낮추거나, 이중화를 넣거나, 의존성을 필수에서 빼야 합니다.
의존성별 30일 다운타임 기여
- PostgreSQL21m 36s
- Redis43m 12s
- Payment API43m 12s
이 계산에서 자주 틀리는 지점
- · 직렬 의존성은 곱합니다. 99.9%짜리 세 개 뒤에 있으면 여러분의 상한은 99.7%입니다. 평균이 아니라 곱입니다.
- · 이중화는 실패가 독립일 때만 도움이 됩니다. 같은 가용 영역, 같은 배포, 같은 설정 오류를 공유하는 복제본은 함께 죽습니다. 여기 계산은 낙관적 상한입니다.
- · "월 99.9%"와 "일 99.9%"는 다른 약속입니다. 월 기준이면 하루를 통째로 43분 넘게 날려도 월 예산 안일 수 있지만, 일 기준이면 그날은 이미 위반입니다.
- · 시간 기반 SLO와 요청 기반 SLO는 같은 사건을 다르게 셉니다. 트래픽이 적은 새벽 장애는 요청 기반에서 거의 안 보입니다.