"우리는 99.9% 가용성 약속" — 그게 무슨 의미? 한 달에 43분 down OK? downtime 만? slow latency 도? SLI · SLO · error budget — Google SRE 책의 핵심 프레임워크. 이 가이드는 SLI 정의 / SLO 작성 / error budget 활용 / multi-window burn rate alert 의 메커니즘을 정리한다.
SLI · SLO · SLA — 의미
SLI (Service Level Indicator) — 측정값
"지난 5분 의 successful request 비율"
"지난 1주 의 p99 latency"
SLO (Service Level Objective) — 목표
"99.9% requests successful over 30 days"
"p99 latency < 200ms over 7 days"
→ SLI 가 이 값을 만족해야 함
SLA (Service Level Agreement) — 계약 (외부 + penalty)
"월 가용성 99.9% 미만 시 30% credit"
→ SLO 보다 보수적 (SLO 0.1% 여유 가지고 SLA)좋은 SLI 의 조건
- user 경험 반영 — "CPU < 80%" 는 안 됨 (user 가 느낌 X). "request 가 200 으로 응답" 같은 user-visible 측정.
- 이진 분류 가능 — good vs bad. "request 가 5xx 면 bad". percentile 같은 분포도 OK ("p99 < 500ms" 이면 good).
- 비율로 표현 — "good event 수 / total event 수". 그래야 99.9% 같은 SLO 와 자연 매칭.
흔한 SLI 패턴
Availability:
SLI = (5xx 아닌 요청 수) / (총 요청 수)
Latency:
SLI = (p99 < 500ms 인 1분 bucket 수) / (총 1분 bucket 수)
Freshness (data pipeline):
SLI = (lag < 5min 의 시점 수) / (총 시점 수)
Throughput:
SLI = (queue depth < 100 의 시점 수) / (총 시점 수)SLO — 목표값의 의미
SLO: "99.9% successful over 30 days"
30 일 = 43,200 분
0.1% = 43.2 분 — 이게 error budget
→ 한 달에 43 분까지 down OK (또는 그에 상응하는 5xx)
→ 실제 down 이 43 분 미만이면 → 새 feature deploy OK
→ 43 분 초과 → freeze (안정화 우선)
이게 error budget 의 핵심:
"100% 가용성은 불가능하니, 약속한 1% 까지는 사용해라.
사용 안 한 budget = 새 기능 release 의 자유."가용성 % 의 실제 의미
| SLO | 월 허용 downtime | 일 허용 | 의미 |
|---|---|---|---|
| 99% | 7.2 시간 | 14.4 분 | "two nines" — 내부 도구 정도 |
| 99.9% | 43 분 | 1.4 분 | "three nines" — 일반 SaaS |
| 99.95% | 22 분 | 43 초 | 비즈니스 크리티컬 |
| 99.99% | 4.3 분 | 9 초 | "four nines" — 금융, 결제 핵심 |
| 99.999% | 26 초 | 0.9 초 | "five nines" — telecom, 극히 드뭄 |
nine 이 하나 더 늘면 비용 보통 10× — 99.99 → 99.999 가 가장 비쌈. 모든 service 에 5 nines 는 자원 낭비.
Error Budget — feature velocity 의 contract
기존 갈등:
Product: "빨리 release 해서 사용자 만족!"
SRE: "안정성이 우선! release 줄여!"
Error Budget 의 해결:
- SLO 협상 (예: 99.9% = 월 43 분 budget)
- budget 남아있으면 → release 자유
- budget 소진 → freeze (release pause, 안정화 우선)
→ "objective metric 으로 자동 결정". 정치적 갈등 ↓.
운영:
매주 budget 사용량 review
- 80%+ 소진 → 다음 주 release 줄이기 (caution)
- 100% 소진 → freeze
- 매 분기 burn 패턴 보면 SLO 자체 조정Multi-window multi-burn-rate alert
단순 alert 의 문제: SLI dropped below 99.9% → page. 그러나:
SLI = 99.0% 30 분 동안 → 1% budget 소진. 한 달 단위로 보면 작음 → page 불필요
SLI = 99.0% 6 시간 동안 → 22% budget 소진. critical → page
SLI = 50% 5 분 동안 → 같은 양 소진. 즉시 page
→ "얼마나 빨리 budget 을 burn 하는가" 가 alert 의 기준.
Multi-window, multi-burn-rate (Google SRE 권장):
severity | burn rate | 1h window | 6h window | 동작
-----------|-----------|-----------|-----------|------
Page | 14.4x | true | true | 즉시 page
Page | 6x | true | true | 즉시 page
Ticket | 3x | true | true | ticket open
Ticket | 1x | true | true | ticket open
→ 두 window 모두 만족 = false positive 줄임 (잠시 spike 무시).
다른 burn rate = severity 차등.SLO 작성 — 실용 step
- service 의 핵심 user journey 식별 — 결제, 로그인, 검색 등. 모든 endpoint SLO X.
- 각 journey 의 SLI 선택 — availability + latency (보통 둘 다).
- SLO 값 결정 — 너무 낮으면 의미 없음, 너무 높으면 항상 소진. 99.9% 가 자주 sweet spot. 측정 데이터 1-3 개월 참고.
- error budget policy 합의 — budget 소진 시 freeze 정책, review 주기.
- multi-window burn-rate alert 설정 — 1h/6h window 표준.
- 분기별 review — SLO 너무 낮거나 높은지, user 기대와 일치하는지.
흔한 함정
- SLI 가 internal metric — CPU / memory 등은 user 경험 반영 X. "request 성공률" 같은 user-visible 만.
- SLO 100% 약속 — 불가능. 99.9% 도 한 달 43 분 허용. 100% SLO 는 alert 너무 많고 freeze 영구.
- alert 가 SLO 미달 직후 page — false positive 많음. burn-rate 기반 + multi-window.
- "error budget 안 썼으니 deploy 마음대로" — deploy 하나가 큰 incident 가능. 점진적 rollout + 모니터링.
- 모든 endpoint 에 SLO — 운영 부담 ↑. 핵심 user journey 만.
마무리
SLI · SLO · error budget 은 단순 metric 아니라 stability vs velocity 의 자동화된 합의 메커니즘. Google SRE 의 핵심 인사이트.
실용 — 핵심 user journey 3-5 개에만 SLO 설정 (모든 endpoint X), budget 정책 명시 (freeze 조건), multi-window burn-rate alert (1h + 6h), 분기별 review. 시작은 99.9% — 측정 후 조정.