도입
서비스 운영에서 “안정적이다”는 표현은 모호하다. 기준이 없으면 장애 판단도 달라진다.
그래서 실무에서는 숫자로 목표를 정의한다. 대표 개념이 SLA, SLO, SLI다.
세 개는 항상 같이 등장한다. 하지만 역할은 완전히 다르다.
핵심 개념 설명
SLI는 측정값, SLO는 목표, SLA는 계약이다.
- SLI: 실제 측정 지표
- SLO: 내부 운영 목표
- SLA: 고객과의 약속
즉 측정 → 목표 → 계약 순서다. 이 구조로 이해하면 쉽다.
동작 원리 또는 구조
서비스 상태를 먼저 측정한다. 그 값을 기준으로 목표를 만든다.
SLI가 기반 데이터다. SLO와 SLA는 그 위에 올라간다.
그래서 SLI가 부정확하면 나머지도 의미가 없어진다.
SLI (Service Level Indicator)
SLI는 서비스 상태를 측정하는 실제 수치다. 가장 기본 개념이다.
즉 “현재 얼마나 잘 동작하는가”를 나타낸다.
- 응답 성공률
- 응답 시간
- 에러율
- 가용성
성공 요청 수 / 전체 요청 수
= Availability SLI
예를 들어 성공률 99.95%는 SLI 값이다.
SLO (Service Level Objective)
SLO는 내부 목표 수치다. 운영팀이 관리하는 기준이다.
즉 “어느 수준까지 유지할 것인가”를 정의한다.
SLO:
한 달 기준 API 성공률 99.9% 유지
실무에서는 SLO가 핵심이다. 운영 품질 기준이 되기 때문이다.
장애 대응 우선순위도 SLO 기준으로 결정하는 경우가 많다.
SLA (Service Level Agreement)
SLA는 고객과의 계약이다. 법적 또는 금전적 책임이 포함된다.
즉 목표가 아니라 약속이다. 그래서 가장 보수적으로 설정한다.
SLA:
월 가용성 99.5% 미만 시
요금 10% 환불
실무에서는 보통 SLO가 SLA보다 높다.
예: SLO 99.9% SLA 99.5%
실무 운영 기준
1. SLI는 사용자 관점으로 측정
CPU 사용량만 보면 안 된다. 실제 사용자 경험 기준이어야 한다.
예를 들어 API 성공률, 응답 속도가 더 중요하다.
좋은 SLI:
- API 성공률
- 페이지 로딩 시간
- 결제 성공률
좋지 않은 SLI:
- 서버 CPU 사용률만 측정
2. SLO는 현실적으로 설정
무조건 99.999%가 좋은 것은 아니다. 운영 비용이 급격히 증가한다.
서비스 특성에 맞게 정해야 한다. 내부 관리자 페이지와 결제 API는 기준이 다르다.
3. Error Budget 개념
SLO는 장애 허용 범위를 의미하기도 한다. 이걸 Error Budget이라고 부른다.
즉 100% 무장애가 아니라 허용 가능한 실패 범위를 정의하는 개념이다.
4. Metrics 기반 자동 측정
SLI는 수동 계산하면 의미가 없다. Prometheus 같은 시스템으로 자동 수집해야 한다.
http_request_success_rate
api_response_time_p95
실무에서는 Grafana 대시보드와 연결한다. SLO 상태를 실시간으로 본다.
자주 발생하는 문제
1. SLA와 SLO 혼동
SLO는 내부 목표다. SLA는 고객 계약이다.
둘을 같게 잡으면 운영 리스크가 커진다.
2. 의미 없는 SLI 사용
CPU만 측정하면 사용자 경험을 알 수 없다.
반드시 사용자 관점이어야 한다.
3. 비현실적 목표 설정
99.999%는 매우 비싸다. 운영 구조 자체가 달라진다.
서비스 중요도 기준으로 정해야 한다.
4. 측정 자동화 없음
수동 계산은 운영 불가능하다. Metrics 기반 자동화가 필수다.
실무에서의 관계 정리
SLI는 데이터, SLO는 운영 기준, SLA는 외부 약속이다.
실무에서는 SLO 관리가 핵심이다. SLA는 그 결과물에 가깝다.
한 줄 요약
SLI는 실제 측정값, SLO는 내부 운영 목표, SLA는 고객과의 계약이며 실무에서는 사용자 기준의 SLI와 현실적인 SLO 설계가 핵심이다.
댓글 0