SLI/SLO/SLA 실전: 정의, 측정, 에러 버짓 소비

"99.9% 가용성"은 무엇을 의미하는가

SLO라는 단어 없이 "가용성 99.9% 유지"를 목표로 정하면 금방 문제가 생긴다. 99.9%를 어떻게 측정하는가? 어떤 요청을 기준으로 하는가? 측정 기간은 한 달인가, 일주일인가, 롤링 28일인가? 오류가 클라이언트 타임아웃인지 서버 5xx인지에 따라 숫자가 달라진다.

모호한 목표는 장애 때마다 논쟁을 낳는다. "그 장애가 SLO를 깼는가?"라는 질문에 팀마다 다른 답이 나오면 에러 버짓이 의미를 잃는다.

SLI, SLO, SLA는 이 모호함을 제거하는 세 겹의 정의다.

SLI: 서비스 품질을 수치로 표현하기

SLI(Service Level Indicator)는 서비스가 얼마나 잘 동작하고 있는지 나타내는 정량적 측정값이다. Google SRE 북은 "서비스 수준의 어떤 측면을 신중하게 정의한 정량적 측정"이라고 표현한다.

SLI의 핵심은 사용자가 실제로 경험하는 품질과 직결되어야 한다는 점이다. 서버 CPU 사용률은 시스템 지표이지 SLI가 아니다. 사용자 요청 중 200ms 이내에 응답한 비율은 SLI다.

SLI의 주요 유형

가용성(Availability)은 가장 기본이다. 성공 응답 수를 전체 요청 수로 나눈 비율이다.

가용성 SLI = 성공 요청 수 / 전체 요청 수

예: HTTP 2xx 응답 / (2xx + 4xx + 5xx) 응답
    단, 클라이언트 오류(4xx)를 포함할지 여부는 서비스마다 다르게 정한다.

지연(Latency)은 응답 속도다. 평균(mean)이 아닌 백분위수(percentile)로 표현해야 한다. 평균은 느린 요청의 고통을 숨긴다.

지연 SLI = "요청의 X%가 N ms 이내에 응답한 비율"

예: p99 < 500ms
    (단순히 평균이 500ms가 아니라, 상위 1% 느린 요청도 500ms 이내)

에러율(Error Rate)은 실패 비율이다. 가용성의 보완 지표로, 오류 유형을 구분해서 측정하면 더 유용하다.

에러율 SLI = 에러 응답 수 / 전체 요청 수

포화(Saturation)는 자원 압박의 척도다. CPU, 메모리, 큐 길이, 연결 수 등이 한계에 얼마나 가까운지를 나타낸다.

처리량(Throughput)은 단위 시간당 처리된 작업량이다. 초당 요청(RPS), 초당 레코드(records/s)로 표현한다.

데이터 플랫폼과 배치 파이프라인의 SLI

API 서버가 아닌 데이터 파이프라인에서는 SLI 유형이 달라진다.

데이터 플랫폼 SRE에서 "가용성 99.9%"보다 "매일 KST 06:00까지 T-1 일자 데이터 완료율 99.5%"가 실질적으로 더 의미 있는 SLI일 때가 많다.

SLO: 목표를 정밀하게 정의하기

SLO(Service Level Objective)는 SLI에 대한 내부 목표다. 다음 네 요소를 모두 포함해야 완전한 SLO다.

1. 측정 대상: 어떤 SLI인가?
2. 목표값: 몇 %를 달성해야 하는가?
3. 측정 윈도우: 어떤 기간을 보는가? (28일 롤링, 분기 등)
4. 측정 방식: 어디서, 어떻게 측정하는가?

좋은 SLO 예시는 다음과 같다.

[좋은 SLO]
"주문 API의 p99 지연이 500ms 이하인 요청 비율이 28일 롤링 윈도우 기준 99.5% 이상이다.
측정: 로드밸런서 액세스 로그에서 요청 완료 시간 기준."

[모호한 SLO]
"주문 API는 빠르게 응답해야 한다."

SLO 설정의 실용 원칙은 현재 측정값에서 출발하기다. 지난 90일 데이터에서 p99 지연이 430ms였다면 첫 SLO는 500ms 또는 현재값보다 소폭 엄격한 수치로 시작한다. 아직 측정한 적 없다면 SLO 설정 전에 먼저 측정한다.

SLO 윈도우

측정 기간은 에러 버짓을 어떻게 계산하느냐를 결정한다.

• 롤링 윈도우(rolling window): 현재 시점에서 과거 N일을 계속 본다. 실시간성이 좋고 계절성 영향이 낮다. 일반적으로 28일 또는 30일.
• 캘린더 윈도우(calendar window): 월 초~말, 분기 초~말. 재무·계약 주기와 맞추기 쉽다.

두 방식을 함께 쓰는 팀도 있다. 운영 대시보드는 28일 롤링으로 보고, 계약(SLA)은 분기 기준으로 한다.

SLA: 외부 약속과 내부 목표의 차이

SLA(Service Level Agreement)는 서비스 제공자와 고객 사이의 계약이다. SLO를 위반했을 때 환불, 서비스 크레딧, 계약 해지 등 구체적인 결과(consequence)가 따른다.

SLO와 SLA의 가장 중요한 차이는 이것이다.

실무에서 SLA 목표는 SLO보다 낮게 설정한다. 내부 SLO 99.9%를 달성하지 못하는 경우가 있더라도, 외부 SLA 99.5%는 달성해야 계약 위반이 아니기 때문이다. 내부 SLO는 외부 SLA를 달성하기 위한 안전 여유를 포함한다.

에러 버짓 계산: 얼마나 실패할 수 있는가

에러 버짓은 SLO에서 자동으로 계산된다.

에러 버짓 = 1 - SLO

예: SLO 99.9% → 에러 버짓 0.1%

28일 기준 요청 수가 100만이라면:
  허용 실패 수 = 100만 × 0.001 = 1,000건

시간 기준:
  허용 다운타임 = 28일 × 24h × 60m × 0.001 ≈ 40.3분

에러 버짓이 남아 있는지 소진되었는지는 다음으로 추적한다.

에러 버짓 소비율 = (실제 에러 수 / 허용 에러 수) × 100%

실제 에러 수 1,200건, 허용 1,000건 → 소비율 120% (초과)
실제 에러 수 400건, 허용 1,000건 → 소비율 40% (여유 60%)

소비율 100%가 넘으면 에러 버짓이 소진된 상태다. 그 시점부터 배포 중단, 신뢰성 집중 작업으로 전환이 기본 정책이다.

번 레이트: 에러 버짓이 얼마나 빠르게 소비되는가

에러 버짓 현재 잔량만 보면 너무 늦게 알게 된다. 번 레이트(burn rate)는 현재 속도로 버짓이 소모된다면 얼마 후에 소진될지를 나타낸다.

번 레이트 = 현재 에러율 / (1 - SLO)

예: SLO 99.9% (에러 버짓 0.1%)
    현재 에러율 1.44% → 번 레이트 = 1.44% / 0.1% = 14.4
    → 현재 속도가 계속되면 30일 버짓이 약 2일 만에 소진

번 레이트 1은 정확히 윈도우 끝에 버짓 소진. 번 레이트 2는 절반 시간에 소진. 번 레이트 14.4는 30일 예산이 약 50시간 만에 소진된다.

Multi-window Multi-burn-rate 알림

단순히 에러율을 임계값으로 알림을 보내면 문제가 있다. 에러율 0.2%가 30분 동안 지속된 것과 에러율 0.2%가 3일 동안 지속된 것은 심각도가 다르다. 또한 단기 스파이크에 너무 자주 알림이 울리면 알림 피로(alert fatigue)가 생긴다.

Google SRE 워크북은 멀티 윈도우, 멀티 번 레이트(MWMBR) 알림을 권장한다.

멀티 윈도우 조건

각 등급은 짧은 윈도우(short window)와 긴 윈도우(long window) 두 조건을 동시에 충족해야 알림이 발동한다. 짧은 윈도우는 긴 윈도우의 약 1/12로 설정하는 것을 Google은 권장한다.

Tier 1 (14.4×):
  긴 윈도우 = 1시간, 짧은 윈도우 = 5분
  두 조건 모두 14.4× 이상이어야 알림 발동

Tier 2 (6×):
  긴 윈도우 = 6시간, 짧은 윈도우 = 30분
  두 조건 모두 6× 이상이어야 알림 발동

두 조건을 동시에 확인하는 이유는 단기 스파이크로 인한 오탐을 줄이면서도 회복된 스파이크를 놓치지 않기 위해서다. 짧은 윈도우 조건이 없으면 장기 저율 소비도 늦게 감지된다. 긴 윈도우 조건이 없으면 순간 스파이크에 너무 많은 알림이 발동된다.

SLI와 SLO를 어떻게 연결하는가

SLI를 정의했다고 SLO가 자동으로 완성되지는 않는다. 다음 순서가 일반적이다.

1. 사용자 여정 파악: 어떤 인터랙션이 사용자에게 가장 중요한가?
2. SLI 후보 선정: 그 여정과 직결된 측정값은 무엇인가?
3. 현재 측정값 확인: 지난 90일 데이터를 보고 현실적인 기준을 잡는다.
4. SLO 초안 작성: "SLI X가 윈도우 Y 기간 동안 Z% 이상이어야 한다"는 형식으로.
5. 에러 버짓 계산: 허용 장애량이 실제로 감당 가능한지 확인한다.
6. 팀 합의: 개발팀, SRE팀, 제품팀이 같은 숫자에 동의하는가?
7. 모니터링 구현: Prometheus, Datadog, Cloud Monitoring 등에 번 레이트 알림 설정.
8. 분기 검토: SLO가 현재 서비스 수준과 맞는지 재검토.

흔한 실수와 함정

SLI를 너무 많이 만든다. 5개 이하 핵심 SLI에 집중한다. 10개 이상이 되면 어느 것을 봐야 할지 모르게 되고, 대시보드가 노이즈로 가득 찬다.

평균으로 SLI를 측정한다. p99 또는 p99.9를 기준으로 한다. 평균 응답시간 200ms라도 상위 1% 사용자가 5초를 기다리고 있을 수 있다.

SLO를 너무 높게 설정한다. 99.99%를 달성하려면 1년에 허용 다운타임이 약 52분이다. 대부분의 내부 서비스와 데이터 파이프라인에는 99.9%나 99.5%로 시작하는 것이 현실적이다.

에러 버짓 정책이 없다. SLO와 에러 버짓 계산만 있고, "소진 시 어떻게 하는가"가 명문화되어 있지 않으면 팀마다 다른 행동을 한다.

알림을 에러율로만 건다. 에러율 임계값 알림은 번 레이트 기반 알림보다 오탐이 많고 실제 SLO 위반 감지가 느리다.

데이터 플랫폼 SLO 예시

DBA와 데이터 플랫폼 엔지니어가 실제로 쓸 수 있는 SLO 형태를 보면 다음과 같다.

실무 체크리스트

SLI/SLO/SLA를 운영하는 팀이 주기적으로 확인해야 할 항목이다.

1. 각 SLI가 사용자 경험과 직접 연결된 지표인가?
2. SLO 달성 여부를 자동으로 계산하는 모니터링이 있는가?
3. 번 레이트 기반 알림(MWMBR)을 사용하고 있는가?
4. 에러 버짓 소비량을 팀 전체가 볼 수 있는 대시보드가 있는가?
5. 에러 버짓 소진 시 동작할 정책이 문서화되어 있는가?
6. SLO가 마지막으로 검토된 것이 6개월 이내인가?
7. 데이터 파이프라인의 freshness와 completeness SLI를 측정하고 있는가?
8. 온콜 알림 중 "사람이 지금 당장 행동해야 한다"가 아닌 것이 얼마나 되는가?

SLI/SLO는 처음부터 완벽할 수 없다. 측정을 시작하고, 장애를 경험하고, 팀이 합의를 수정하면서 점진적으로 정교해진다. 완벽한 SLO 한 개보다 운영에서 실제로 사용되는 불완전한 SLO 세 개가 낫다.

References

• Google SRE Book, "Service Level Objectives," https://sre.google/sre-book/service-level-objectives/
• Google SRE Workbook, "Implementing SLOs," https://sre.google/workbook/implementing-slos/
• Google SRE Workbook, "Alerting on SLOs," https://sre.google/workbook/alerting-on-slos/
• Atlassian, "SLA vs SLO vs SLI: Understanding Service Levels," https://www.atlassian.com/incident-management/kpis/sla-vs-slo-vs-sli
• Splunk, "SLA vs SLI vs SLO: Understanding Service Levels," https://www.splunk.com/en_us/blog/learn/sla-vs-sli-vs-slo.html
• Rootly, "SLA vs SLO vs SLI: Differences, Examples, Best Practices," https://rootly.com/blog/sla-vs-slo-vs-sli-the-full-breakdown-for-reliable-systems
• Datadog, "Burn rate is a better error rate," https://www.datadoghq.com/blog/burn-rate-is-better-error-rate/
• Nobl9, "SLO Metrics: A Best Practices Guide," https://www.nobl9.com/service-level-objectives/slo-metrics
• Baeldung, "Understanding SRE Fundamentals: SLI vs SLOs vs SLAs," https://www.baeldung.com/ops/site-reliability-engineering-sli-slo-sla-differences