[DEVOPS-009][중급] 서비스 목표와 오류 허용량 계산하기
페이지 정보
본문
[이번 수업]
서버가 켜져 있다는 사실만으로 사용자가 서비스를 잘 이용한다고 말할 수는 없습니다. 이번에는 사용자 경험을 숫자로 나타내는 SLI, 달성할 목표인 SLO, 허용 가능한 실패량인 에러 버짓을 구분하고 로컬에서 직접 계산합니다.
[선수지식]
DEVOPS-008의 로그·메트릭·트레이스와 BACK-002의 HTTP 상태코드를 알면 좋습니다. Python 3로 파일 하나를 실행할 수 있으면 실습할 수 있습니다.
[학습목표]
1. SLI·SLO·에러 버짓의 관계를 설명합니다.
2. 요청 성공률로 현재 지표와 남은 오류 허용량을 계산합니다.
3. 사용자 중심 지표와 측정 기간을 명확히 정의합니다.
[핵심개념]
SLI(Service Level Indicator)는 서비스 수준 지표, 즉 실제로 측정한 사용자 경험의 수치입니다. 예를 들어 유효 요청 중 500ms 안에 성공한 요청의 비율을 사용할 수 있습니다. CPU 사용률처럼 시스템 내부 상태만 보지 말고 가용성, 응답 시간, 정확성, 데이터 신선도처럼 사용자가 느끼는 결과를 선택합니다. 무엇을 좋은 이벤트와 유효 이벤트로 셀지 먼저 문장으로 정의해야 합니다.
SLO(Service Level Objective)는 정해진 기간에 달성하려는 SLI 목표입니다. `최근 30일의 유효 요청 중 99.9%가 성공`처럼 지표, 목표값, 기간을 함께 적습니다. SLA는 서비스 제공자와 이용자 사이의 합의이며 미달 시 조치나 결과가 포함될 수 있어 내부 운영 목표인 SLO와 구분합니다.
에러 버짓은 SLO가 허용한 실패량입니다. 성공률 목표가 99.9%라면 같은 기간 유효 요청의 0.1%가 오류 허용량입니다. 예산이 충분할 때는 변경을 진행하고, 너무 빨리 소모되면 안정화와 원인 제거에 집중하는 공통 판단 기준으로 쓸 수 있습니다. 번 레이트는 오류 예산을 지속 가능한 속도보다 몇 배 빠르게 쓰는지 나타냅니다. 단, 보안 침해나 데이터 손상까지 허용한다는 뜻은 아닙니다.
[따라하기]
다음 코드는 요청 수로 SLI와 에러 버짓을 계산합니다. `slo_check.py`로 저장합니다.
```python
total_requests = 100_000
bad_requests = 45
slo_percent = 99.9
good_requests = total_requests - bad_requests
sli_percent = good_requests / total_requests * 100
error_budget = round(total_requests * (100 - slo_percent) / 100)
remaining_budget = error_budget - bad_requests
budget_used_percent = bad_requests / error_budget * 100
print(f"SLI: {sli_percent:.3f}%")
print("전체 에러 버짓:", error_budget, "건")
print("남은 에러 버짓:", remaining_budget, "건")
print(f"예산 사용률: {budget_used_percent:.1f}%")
```
macOS·Linux는 `python3 slo_check.py`, Windows PowerShell은 `py slo_check.py`로 실행합니다. 예상 결과는 `SLI: 99.955%`, 전체 에러 버짓 100건, 남은 에러 버짓 55건, 예산 사용률 45.0%입니다. 실제 시스템에서는 같은 기준으로 수집한 카운터를 같은 시간 창에서 집계하고, 누락된 측정값을 성공으로 처리하지 않습니다.
[흔한 실수]
분모에서 불리한 요청을 임의로 빼면 SLI가 실제보다 좋아집니다. 월간 목표와 최근 30일 목표를 섞거나 배포 때마다 계산을 초기화하는 것도 잘못입니다. 평균 응답 시간만 보면 일부 사용자의 매우 느린 요청이 가려질 수 있습니다. 모든 기능을 하나의 SLO로 합치기보다 로그인·결제처럼 중요한 사용자 흐름을 따로 관찰하고, 목표가 너무 느슨하거나 비현실적으로 엄격하지 않은지 주기적으로 검토합니다.
[보안 주의]
메트릭 속성에 인증 토큰, 전체 요청 본문, 이메일 같은 개인정보를 넣지 않습니다. 사용자 ID나 자유 형식 URL을 라벨로 사용하면 민감정보 노출과 시계열 폭증이 생길 수 있으므로 제한된 분류값을 씁니다. 관측 데이터에도 접근 권한과 보존 기간을 적용합니다. 에러 버짓이 남아 있어도 보안 통제와 데이터 무결성 기준은 낮추지 않습니다.
[직접 해볼 과제]
`bad_requests`를 120으로 바꿔 남은 예산과 사용률을 확인하세요. 결과를 바탕으로 신규 배포를 계속할지 안정화 작업을 우선할지 한 문장으로 정하고, 판단에 필요한 추가 지표 한 개를 적습니다.
[확인문제]
1. SLI와 SLO는 각각 측정값과 목표 중 어느 쪽인가요?
2. 10만 건에 성공률 SLO가 99.9%라면 전체 에러 버짓은 몇 건인가요?
3. CPU 사용률 하나만으로 사용자 중심 SLI를 대신하기 어려운 이유는 무엇인가요?
[다음 학습]
DEVOPS-010에서는 SLO와 오류 예산 소모 속도를 바탕으로 실제 조치가 필요한 알림과 온콜 운영을 설계합니다.
[공식 참고 자료]
- SRE 도서 서비스 수준 목표: https://sre.google/sre-book/service-level-objectives/
- SRE 워크북 SLO 구현: https://sre.google/workbook/implementing-slos/
- SRE 워크북 SLO 기반 알림: https://sre.google/workbook/alerting-on-slos/
- OpenSLO 공식 사양 안내: https://openslo.com/
- OpenTelemetry 메트릭 데이터 모델: https://opentelemetry.io/docs/specs/otel/metrics/data-model/
서버가 켜져 있다는 사실만으로 사용자가 서비스를 잘 이용한다고 말할 수는 없습니다. 이번에는 사용자 경험을 숫자로 나타내는 SLI, 달성할 목표인 SLO, 허용 가능한 실패량인 에러 버짓을 구분하고 로컬에서 직접 계산합니다.
[선수지식]
DEVOPS-008의 로그·메트릭·트레이스와 BACK-002의 HTTP 상태코드를 알면 좋습니다. Python 3로 파일 하나를 실행할 수 있으면 실습할 수 있습니다.
[학습목표]
1. SLI·SLO·에러 버짓의 관계를 설명합니다.
2. 요청 성공률로 현재 지표와 남은 오류 허용량을 계산합니다.
3. 사용자 중심 지표와 측정 기간을 명확히 정의합니다.
[핵심개념]
SLI(Service Level Indicator)는 서비스 수준 지표, 즉 실제로 측정한 사용자 경험의 수치입니다. 예를 들어 유효 요청 중 500ms 안에 성공한 요청의 비율을 사용할 수 있습니다. CPU 사용률처럼 시스템 내부 상태만 보지 말고 가용성, 응답 시간, 정확성, 데이터 신선도처럼 사용자가 느끼는 결과를 선택합니다. 무엇을 좋은 이벤트와 유효 이벤트로 셀지 먼저 문장으로 정의해야 합니다.
SLO(Service Level Objective)는 정해진 기간에 달성하려는 SLI 목표입니다. `최근 30일의 유효 요청 중 99.9%가 성공`처럼 지표, 목표값, 기간을 함께 적습니다. SLA는 서비스 제공자와 이용자 사이의 합의이며 미달 시 조치나 결과가 포함될 수 있어 내부 운영 목표인 SLO와 구분합니다.
에러 버짓은 SLO가 허용한 실패량입니다. 성공률 목표가 99.9%라면 같은 기간 유효 요청의 0.1%가 오류 허용량입니다. 예산이 충분할 때는 변경을 진행하고, 너무 빨리 소모되면 안정화와 원인 제거에 집중하는 공통 판단 기준으로 쓸 수 있습니다. 번 레이트는 오류 예산을 지속 가능한 속도보다 몇 배 빠르게 쓰는지 나타냅니다. 단, 보안 침해나 데이터 손상까지 허용한다는 뜻은 아닙니다.
[따라하기]
다음 코드는 요청 수로 SLI와 에러 버짓을 계산합니다. `slo_check.py`로 저장합니다.
```python
total_requests = 100_000
bad_requests = 45
slo_percent = 99.9
good_requests = total_requests - bad_requests
sli_percent = good_requests / total_requests * 100
error_budget = round(total_requests * (100 - slo_percent) / 100)
remaining_budget = error_budget - bad_requests
budget_used_percent = bad_requests / error_budget * 100
print(f"SLI: {sli_percent:.3f}%")
print("전체 에러 버짓:", error_budget, "건")
print("남은 에러 버짓:", remaining_budget, "건")
print(f"예산 사용률: {budget_used_percent:.1f}%")
```
macOS·Linux는 `python3 slo_check.py`, Windows PowerShell은 `py slo_check.py`로 실행합니다. 예상 결과는 `SLI: 99.955%`, 전체 에러 버짓 100건, 남은 에러 버짓 55건, 예산 사용률 45.0%입니다. 실제 시스템에서는 같은 기준으로 수집한 카운터를 같은 시간 창에서 집계하고, 누락된 측정값을 성공으로 처리하지 않습니다.
[흔한 실수]
분모에서 불리한 요청을 임의로 빼면 SLI가 실제보다 좋아집니다. 월간 목표와 최근 30일 목표를 섞거나 배포 때마다 계산을 초기화하는 것도 잘못입니다. 평균 응답 시간만 보면 일부 사용자의 매우 느린 요청이 가려질 수 있습니다. 모든 기능을 하나의 SLO로 합치기보다 로그인·결제처럼 중요한 사용자 흐름을 따로 관찰하고, 목표가 너무 느슨하거나 비현실적으로 엄격하지 않은지 주기적으로 검토합니다.
[보안 주의]
메트릭 속성에 인증 토큰, 전체 요청 본문, 이메일 같은 개인정보를 넣지 않습니다. 사용자 ID나 자유 형식 URL을 라벨로 사용하면 민감정보 노출과 시계열 폭증이 생길 수 있으므로 제한된 분류값을 씁니다. 관측 데이터에도 접근 권한과 보존 기간을 적용합니다. 에러 버짓이 남아 있어도 보안 통제와 데이터 무결성 기준은 낮추지 않습니다.
[직접 해볼 과제]
`bad_requests`를 120으로 바꿔 남은 예산과 사용률을 확인하세요. 결과를 바탕으로 신규 배포를 계속할지 안정화 작업을 우선할지 한 문장으로 정하고, 판단에 필요한 추가 지표 한 개를 적습니다.
[확인문제]
1. SLI와 SLO는 각각 측정값과 목표 중 어느 쪽인가요?
2. 10만 건에 성공률 SLO가 99.9%라면 전체 에러 버짓은 몇 건인가요?
3. CPU 사용률 하나만으로 사용자 중심 SLI를 대신하기 어려운 이유는 무엇인가요?
[다음 학습]
DEVOPS-010에서는 SLO와 오류 예산 소모 속도를 바탕으로 실제 조치가 필요한 알림과 온콜 운영을 설계합니다.
[공식 참고 자료]
- SRE 도서 서비스 수준 목표: https://sre.google/sre-book/service-level-objectives/
- SRE 워크북 SLO 구현: https://sre.google/workbook/implementing-slos/
- SRE 워크북 SLO 기반 알림: https://sre.google/workbook/alerting-on-slos/
- OpenSLO 공식 사양 안내: https://openslo.com/
- OpenTelemetry 메트릭 데이터 모델: https://opentelemetry.io/docs/specs/otel/metrics/data-model/
- 이전글[SEC-009][중급] 의존성과 SBOM으로 공급망 위험 줄이기 26.09.04
- 다음글[CLOUD-009][중급] 서비스 장애에 대비해 백업과 복구 설계하기 26.09.04
댓글목록
등록된 댓글이 없습니다.