이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- SLI, SLO, Error Budget은 각각 무엇을 의미하는가?
- Spring 백엔드 API의 SLI를 어떻게 정의해야 운영 판단에 쓸 수 있는가?
- Error Budget이 배포 속도와 안정성 우선순위에 어떤 영향을 주는가?
개요
SLI는 Service Level Indicator, 즉 서비스 수준을 측정하는 지표다.
SLO는 Service Level Objective, 즉 그 지표가 달성해야 하는 목표다.
Error Budget은 SLO에서 허용하는 실패량이다.
SLO는 완벽한 서비스를 약속하는 문서가 아니다.
사용자가 기대하는 신뢰성과 팀이 감당할 개발 속도 사이의 균형을 정하는 운영 기준이다.
SLI
SLI는 측정 가능해야 한다.
백엔드 API에서는 성공률, latency, availability, freshness, durability 같은 지표가 SLI가 될 수 있다.
availability SLI:
good events = HTTP 2xx, 3xx, expected 4xx
total events = all HTTP requests excluding health checks
latency SLI:
good events = requests completed under 500ms
total events = all successful requestsHealth check 요청이나 내부 batch 요청을 사용자 API SLI에 섞으면 목표가 왜곡된다.
SLO
SLO는 SLI의 목표 수준이다.
주문 생성 API availability SLO:
99.9% of valid requests over 30 days succeed.
주문 조회 API latency SLO:
95% of successful requests over 30 days complete under 500ms.SLO는 기간과 대상이 있어야 한다.
“빠르게 응답한다”는 SLO가 아니다.
어떤 요청이 good event인지, 어떤 요청을 제외하는지 명확해야 한다.
Error Budget
Error Budget은 허용 가능한 실패량이다.
99.9% SLO라면 30일 동안 0.1%의 실패가 budget이다.
Budget이 빠르게 소진되면 새 기능 배포보다 안정화가 우선일 수 있다.
Budget이 충분하면 일정 수준의 변경 위험을 감수할 수 있다.
Error Budget은 개발팀과 운영팀의 감정 싸움을 줄이고 같은 기준으로 판단하게 한다.
Burn Rate
Burn rate는 error budget을 얼마나 빠르게 쓰고 있는지 보여 준다.
짧은 시간 burn rate가 높으면 빠른 장애 대응이 필요하다.
긴 시간 burn rate가 높으면 만성적인 품질 문제를 의미할 수 있다.
Alert는 단순 5xx 비율보다 SLO burn rate 기반으로 설계할 수 있다.
이 방식은 사용자 영향과 알림을 더 직접 연결한다.
운영 체크리스트
- SLI의 good event와 total event가 명확한가?
- Health check, bot, 내부 batch 요청이 SLI에서 분리되어 있는가?
- SLO에 대상 API, 목표 수치, 기간이 있는가?
- Latency SLO가 평균이 아니라 percentile 또는 good event 비율로 정의되어 있는가?
- Error budget 소진 기준에 따른 배포 정책이 있는가?
- Burn rate alert가 page 기준과 연결되어 있는가?
- SLO 예외 처리와 변경 절차가 문서화되어 있는가?
장애 신호
- SLO가 “서비스 안정성 99.9%”처럼 측정 대상이 모호하다.
- 5xx만 실패로 보고 timeout이나 너무 느린 응답을 놓친다.
- 내부 health check 트래픽이 availability를 좋게 보이게 만든다.
- 평균 latency는 정상인데 latency SLO는 계속 위반된다.
- Error budget이 이미 소진됐는데 대규모 배포를 계속한다.
- SLO dashboard와 alert rule이 서로 다른 query를 쓴다.
안전한 완화 조치
SLO 위반이 보이면 먼저 SLI query가 올바른지 확인한다.
잘못된 제외 조건이나 label 누락이 있으면 판단이 왜곡된다.
Budget 소진이 빠르면 신규 배포를 줄이고 장애 원인 제거에 집중한다.
Latency SLO 위반은 cache, DB query, 외부 API, thread pool을 endpoint별로 나눠 본다.
SLO를 낮추는 것은 마지막 수단이며 사용자 기대와 비즈니스 기준을 함께 봐야 한다.
인프라 담당자와 공유할 자료
SLO: order-create availability 99.9% over 30d
SLI query: valid POST /api/orders good events / total events
현재 상태: 30d 99.82%, error budget 180% 소진
주요 원인: payment timeout 5xx 증가
burn rate: 6h window 8x
요청: payment dependency timeout과 retry 정책 검토
배포 정책: 신규 기능 배포 보류 제안SLO 공유에는 목표, 현재 상태, budget 소진, 원인 후보, 운영 결정 제안을 함께 넣는다.
실전 팁
- SLI는 사용자 경험과 가까워야 한다.
- SLO는 숫자, 기간, 대상이 있어야 한다.
- Error budget은 배포 의사결정에 연결되어야 한다.
- Latency는 평균보다 percentile 또는 good event 비율로 정의한다.
- SLO query는 dashboard와 alert가 같은 기준을 쓰게 한다.
위험 신호!
- SLO가 있지만 어떤 query로 계산하는지 모른다.
- 모든 endpoint에 같은 SLO를 적용한다.
- Error budget을 보고도 운영 결정이 바뀌지 않는다.
- SLO 위반을 숨기려고 목표를 낮춘다.
- Health check 성공률을 사용자 availability로 착각한다.
확인 질문
확인 질문
- SLI와 SLO의 차이는 무엇인가?
- SLI는 측정 지표이고 SLO는 그 지표가 일정 기간 동안 달성해야 하는 목표다.
- Error budget이 운영 의사결정에 쓰이는 방식은 무엇인가?
- 허용 실패량이 소진될수록 신규 배포보다 안정화와 장애 원인 제거를 우선하게 만드는 기준이 된다.
- 좋은 availability SLI를 정의할 때 제외해야 할 요청은 무엇인가?
- health check, 내부 batch, bot 등 사용자 경험을 대표하지 않는 요청은 분리하거나 제외해야 한다.