콘텐츠로 이동

SLO 입문 — 99.9%가 의미하는 것, SLI·SLO·SLA 차이

“우리 서비스 가용성 99.9%입니다”라는 말을 들어본 적 있나요? 이게 실제로 얼마나 다운돼도 되는 건지, 어떻게 측정하는 건지 알아봅니다.

SLI → "지금 얼마나 안정적인가?" (측정값)
SLO → "얼마나 안정적이어야 하는가?" (내부 목표)
SLA → "못 지키면 어떻게 되는가?" (고객과의 계약)

서비스 신뢰성을 숫자로 측정하는 지표입니다.

가장 흔한 SLI: 성공 요청 비율
= 성공한 요청 수 / 전체 요청 수 × 100
예시: 10,000건 중 9,990건 성공 → SLI = 99.9%

팀이 달성해야 할 내부 목표입니다.

SLO 예시:
- 결제 API 가용성 > 99.9%
- 로그인 P95 응답시간 < 300ms
- 검색 API 에러율 < 0.1%

고객과 맺은 약속입니다. 위반 시 환불·크레딧 등 패널티가 발생합니다.

SLA는 항상 SLO보다 느슨하게 설정:
SLO: 99.95% (내부 목표)
SLA: 99.9% (고객 약속) ← SLO 달성해야 SLA를 지킬 수 있음

“99.9%“라는 숫자가 얼마나 다운돼도 되는지 계산해보면:

가용성월간 허용 다운타임연간 허용 다운타임
99%7시간 18분3일 15시간
99.9%43분 12초8시간 46분
99.95%21분 36초4시간 23분
99.99%4분 19초52분 36초

Error Budget — 허용된 실패 여유분

섹션 제목: “Error Budget — 허용된 실패 여유분”

SLO에서 허용하는 실패량을 **Error Budget(에러 예산)**이라고 합니다.

99.9% SLO = 0.1% 실패 허용
월간 Error Budget = 30일 × 24시간 × 60분 × 0.1% = 43.2분
→ 이번 달에 43분 이상 다운되면 SLO 위반
Error Budget이 많이 남아있을 때:
→ 새 기능 빠르게 배포 OK, 실험 가능
Error Budget이 거의 소진됐을 때:
→ 신규 배포 중단, 안정성 개선에 집중

이 원칙을 팀에 적용하면 “빨리 개발하자 vs 안정적으로 하자” 논쟁이 데이터로 해결됩니다.

지난 30일 실제 가용성이 얼마인지 먼저 확인
→ 예: 실제 99.72%
현재값보다 약간 높게 설정 (현재 + 0.1~0.2%)
→ 초기 SLO: 99.9%
Prometheus + Grafana로 실시간 SLI 측정
주간 리포트로 팀과 공유
visitor count

이 가이드를 내 서비스에 직접 적용해 보세요.

TestForge 무료 스캔 시작 →