[품질관리 체계] SLA / SLO / SLI란?

참고: https://wikidocs.net/341086

6-3. SLA / SLO / SLI: 서비스 품질 지표

https://peterica.tistory.com/937

[SRE] SRE가 지켜야 할 SLA, SLI, SLO란?

개발하면서 SLA라는 표현을 접하게 되었다. 이를 찾아보면서 SLO와 SLI를 함께 정리한다.

 

1. SLA(Service Level Agreement)

SLA는 서비스 품질 수준에 대한, 서비스 제공자와 고객 간의 공식 계약이다. 고객에게 보장할 최소 서비스 수준을 약속한다. 이를 위반하면 보상이 발생하므로, 달성 가능한 수준으로 신중하게 설정해야 한다.

 

Voost 프로젝트에서는 고객과의 공식 계약은 없었기에, 이를 제외했다.

 

1-1.  SLA 구성요소

- 서비스 범위: SLA 적용 대상과 제외범위 명시

- 가용성 목표: 월간/연간 가용성 수치

- 성능 기준: 응답 시간, 처리량 등 구체적 성능 요구사항

- 측정 방법: 가용성 및 성능을 측정하는 구체적 산식이나 도구

- 보상 조건: SLA 미달 시 크레딧 환불 비율이나 위약금 규정

- 제외 조건: 정기 점검, 불가항력, 고객 귀책 등 예외 상황

- 보고 주기: SLA 달성 실적과 위반 여부, 에러 버짓 소진 현황 등의 공유 주기, 포맷 정의

 

2. SLO(Service Level Objective)

SLO는 SLA 계약을 안정적으로 충족하기 위해 설정하는 내부 품질 목표이다. SLO를 SLA보다 항상 더 엄격하게 설정하여, SLO를 위반해도 SLA 위반 전에 대응할 수 있는 여유(Buffer)를 만들어야 한다. 이를 에러 버짓(Error Budget)이라 한다.

 

2-1. SLO 설정 가이드라인

- 측정 가능한 지표로 정의 ex. "빠르게 응답" --> "P95 응답시간 300ms 이내"

- SLA보다 10~50% 엄격하게 설정

- 내부 서버 메트릭(cpu 사용률 등 서버 정상 작동 보이는 지표)보다 사용자가 체감하는 지표 우선(API 응답 시간, 에러율 등 사용자가 실제로 서비스 이용 시 겪는 불편 보이는 지표)

- 분기마다 SLO 달성 현황을 검토하고, 필요 시 조정

- 개발팀, 운영팀, 비즈니스팀이 함께 합의하여 설정

 

2-2. 에러 버짓

SLO 목표를 초과하여 허용되는 장애의 총량이다. 에러 버짓이 충분하면 새 기능을 배포하고, 에러 버짓이 부족하면 안정성 개선에 집중하는 방식으로 개발 속도와 서비스 안정성 사이의 균형을 잡을 수 있다.

 

Voost 프로젝트에서는 '낙상 알림 발송'의 P95 지연시간을 일반 saas 서비스의 기준인 5000ms 이내로 설정하였다.
'배회/오프라인'의 P95 지연시간도 같은 기준을 적용하여 65000ms(1분 + 5초) 이내로 설정하였다.

 

3. SLI(Service Level Indicator)

SLI는 서비스 품질을 나타내는 실제 측정 지표이다. 모니터링 시스템에서 수집되는 메트릭으로, SLO 목표를 달성하는지 지속적으로 추적해야 한다.

 

3-1. 주요 SLI 유형과 측정 방법

- 가용성(Availability): 정상 응답 비율. `성공 요청 수 / 전체 요청 수 x 100`으로 측정

- 지연시간(Latency): 요청 처리 시간. `p50, p95, p99 백분위`로 측정

- 에러율(Error Rate): 오류 응답 비율. `5xx 응답 수 / 전체 응답 수 x 100`으로 측정

- 처리량(Throughput): 단위시간당 처리건수. `초당 요청 수(RPS)`로 측정

- 정확성(Correctness): 올바른 결과 비율. `정확한 응답 수 / 전체 응답 수 x 100`으로 측정

 

3-2. 백분위(Percentile)

평균값은 극단적 값에 왜곡될 수 있기 때문에, SLI에서는 백분위를 사용한다.

- p50(중앙값): 전체 요청의 50%가 이 시간 이내에 응답 --> 일반적인 사용자 경험

- p95: 전체 요청의 95%가 이 시간 이내에 응답 --> 대부분의 사용자 경험을 대표(5%는 예외로 제쳐둠)

- p99: 전체 요청의 99%가 이 시간 이내에 응답 --> 거의 모든 사용자의 최악 경험을 반영(1%는 예외로 제쳐둠)

 

4. 실무 설정 가이드

1) SLI 선정

비즈니스에 가장 중요한 사용자 여정을 식별하고, 이에 대한 핵심 SLI를 선정한다.

사용자 여정(User Journey)은 서비스 이용 전체 과정을 사용자 중심으로 바라보는 것이다.

예를 들면, 쇼핑몰 유입 -> 상품 검색-> 결제 완료 -> 배송 받기 -> 리뷰 남김 정도가 사용자 여정이 되겠다.

이 중 결제 완료를 예로 들면, 결제 API 가용성, 결제 처리 지연시간, 결제 정확성 등이 SLI가 되겠다.

 

2) SLO 설정: 과거 성능 데이터를 기준으로 설정한다.

 

3) 모니터링 및 알림 설정

SLI를 실시간으로 수집하고, SLO 위반 위험 시 알림을 발송하는 체계를 구축한다.

- 수집 도구: Prometheus(시각화: Grafana), Datadog, CloudWatch

- 알림 기준: 에러 버짓 소진율이 예상 속도를 초과할 때

- 대시보드: SLI 현재값, SLO 달성률, 에러 버짓 잔량을 한눈에 확인

 

4) 정기 리뷰

주기적(월간/분기별)으로 SLA/SLO/SLI를 리뷰하고, 비즈니스 요구사항 변화에 맞게 조정한다.