SRE & SLO·Error Budget 운영 — 서비스 신뢰성 목표 설정

“우리 서비스는 얼마나 안정적이어야 하는가?” 이 질문에 숫자로 답하는 것이 SLO(Service Level Objective)의 출발점입니다.

SLI / SLO / SLA 개념 정리

세 가지는 같아 보이지만 역할이 다릅니다.

용어	뜻	예시
SLI (Indicator)	신뢰성을 측정하는 지표	”성공 요청 / 전체 요청 비율”
SLO (Objective)	팀이 달성해야 할 목표	”결제 API 가용성 99.9%“
SLA (Agreement)	고객과의 계약 (위반 시 패널티)	“99.9% 미달 시 크레딧 환급”

SLI → "현재 값이 얼마인가?" (측정)
SLO → "얼마여야 하는가?"   (목표)
SLA → "못 지키면 어떻게 되는가?" (계약)

SLO는 SLA보다 더 엄격하게 설정합니다. SLA가 99.9%라면 SLO는 99.95%로 — 내부 목표를 먼저 달성해야 고객과의 계약을 지킬 수 있습니다.

좋은 SLI 설계

모든 지표가 SLI가 되는 건 아닙니다. 사용자 경험을 직접 반영하는 지표를 선택해야 합니다.

# 가용성 SLI 계산 예시
def calculate_availability_sli(window_minutes=60):
    total_requests = metrics.count('http_requests_total', window=f'{window_minutes}m')
    error_requests  = metrics.count(
        'http_requests_total',
        filters={'status': '5xx'},
        window=f'{window_minutes}m'
    )
    good_requests = total_requests - error_requests
    return good_requests / total_requests  # 0.0 ~ 1.0

SLI 유형	측정 대상	적합한 서비스
가용성	성공 요청 비율	모든 HTTP API
지연시간	p95/p99 응답 시간	실시간 서비스
처리량	초당 처리 건수	배치, 스트리밍
정확성	올바른 결과 비율	데이터 파이프라인
신선도	데이터 최신성	대시보드, 캐시

Error Budget: 장애 허용량 관리

Error Budget은 SLO에서 허용되는 “실패 여유분”입니다.

99.9% SLO = 0.1% 실패 허용

월간 Error Budget:
= 30일 × 24시간 × 60분 × 0.1%
= 43.2분 / 월

즉, 한 달에 43분 이상 다운타임이 발생하면 SLO 위반

Error Budget 기반 의사결정

Error Budget 소진율이 낮으면 (예산이 남으면):
→ 빠른 배포, 새 기능 실험, 리스크 감수 OK

Error Budget 소진율이 높으면 (예산 부족):
→ 신규 기능 배포 중단
→ 신뢰성 개선 작업에 집중
→ 배포 프리즈(Freeze) 검토

이 원칙을 팀에 공식화하면 “빠른 배포 vs 안정성” 논쟁이 데이터 기반으로 해소됩니다.

Error Budget 대시보드 구성

# Grafana 패널 예시 (Prometheus)
panels:
  - title: "Error Budget 소진율 (이번 달)"
    expr: |
      1 - (
        sum(rate(http_requests_total{status!~"5.."}[30d]))
        / sum(rate(http_requests_total[30d]))
      ) / 0.001   # 0.1% = SLO 허용 실패율
    thresholds:
      - color: green   # 0~50%: 정상
        value: 0
      - color: yellow  # 50~80%: 주의
        value: 50
      - color: red     # 80~100%: 위험
        value: 80

SLO 목표값 설정 방법

처음부터 99.99%를 목표로 잡으면 운영이 불가능합니다.

단계적 설정 권장:

1단계: 현재 측정값 파악
   → 지난 30일 실제 가용성: 99.72%

2단계: 현실적 목표 설정 (현재 + 0.1~0.2%)
   → 초기 SLO: 99.9%

3단계: 달성 후 점진적 상향
   → 6개월 후: 99.95%
   → 12개월 후: 99.99% (필요 시)

99.99% SLO는 운영 비용이 극적으로 증가합니다

SLO	월 허용 다운타임	요구 수준
99.9%	43분	일반 SaaS 수준
99.95%	22분	중요 서비스
99.99%	4.4분	결제·금융 서비스
99.999%	26초	통신·의료 시스템

99.99% 이상은 멀티 리전 액티브-액티브, 무중단 배포 등 막대한 투자가 필요합니다. 비즈니스 요구에 맞는 적정 목표를 설정하세요.

SRE 팀 없이 SLO 문화 시작하기

SRE 팀이 없는 스타트업도 SLO 문화를 도입할 수 있습니다.

최소 실행 로드맵:

Week 1: SLI 선택
→ 가장 중요한 서비스 1개 선택
→ 가용성 SLI 하나만 측정 시작

Week 2: SLO 선언
→ 현재 측정값 기반으로 현실적 목표 설정
→ Slack 채널에 주간 리포트 자동화

Week 3: Error Budget 운영
→ Error Budget 소진율 대시보드 생성
→ 소진율 80% 초과 시 배포 프리즈 원칙 합의

Month 2+: SLO 범위 확대
→ 서비스 추가, SLI 다양화
→ Post-mortem과 연결 (장애 발생 시 Error Budget 영향 기록)

다음 단계

• 장애 탐지 & 알림 설계 →
• Post-mortem 작성 가이드 →
• 클라우드 비용 최적화 →

TestForge로 SLO 검증을 위한 부하테스트 시작하기 →