프로그래밍공부(Programming Study)/DevOps-Cloud Native

DevOps 신뢰성 설계의 모든 것: SLO부터 MTTR까지 (via Datadog)

Chann._.y 2025. 11. 9.

728x90

완벽한 시스템은 존재하지 않는다.
좋은 DevOps는 장애를 피하려 하지 않고, 장애를 예측하고 학습하는 구조를 만든다.
그래서 SLO, RTO 같은 지표는 단순한 숫자가 아니라,
‘신뢰할 수 있는 시스템을 설계하는 철학’의 표현이다.

1. SLO / SLA / SLI 개념과 설계 방법

1) 기본 개념

SLI (Service Level Indicator)
서비스 품질을 수치로 표현하는 측정 지표다.
예: 성공한 요청 수 / 전체 요청 수, 평균 응답 시간, 가용 시간 비율.
SLO (Service Level Objective)
SLI에 기반해 조직이 달성하고자 하는 목표치를 명시한다.
예: “한 달 동안 API 성공률 99.9% 유지”.
SLA (Service Level Agreement)
서비스 제공자와 고객 간의 계약 수준의 약속이다.
예: “99.9% 가용성 미달 시 한 달 요금의 10%를 보상”.

셋의 관계는 다음과 같다:
SLA ⊃ SLO ⊃ SLI
즉, 상위 계약 → 내부 목표 → 구체적 측정치 순서로 연결된다.

2) SLI/SLO 설계 프로세스

핵심 사용자 여정 정의
사용자가 기대하는 “정상 서비스 경험”을 구체화한다.
예: 로그인, 결제, 파일 업로드.
지표 선정
- 가용성: uptime 비율
- 지연시간: P95/P99 응답 시간
- 오류율: 5xx/전체 요청 비율
- 품질: 비즈니스 로직 성공률 (예: 결제 성공률)
목표치 산정 (SLO)
비즈니스 영향도를 고려해 목표를 설정한다.
예: “99.95% 가용성”은 월간 21.6분 다운타임 허용.
측정 자동화
Datadog, Prometheus, New Relic 등을 활용해 SLI를 자동 수집하고, 알림 정책을 설정한다.
에러 버짓 관리
(1 - SLO%)를 에러 버짓으로 정의해 초과 시 배포를 제한한다.
예: SLO 99.9%면 한 달간 0.1%의 장애 허용 범위.

3) 가용성 수치의 실제 의미

SLO를 설정할 때 “99.9% 가용성” 같은 표현을 흔히 사용한다.
하지만 이 수치가 실제로 얼마나 자주, 얼마나 길게 다운될 수 있는가를 계산해보면 감이 잡힌다.
다음은 가용성 목표치별 허용 가능한 다운타임이다.

SLO 가용성	월간 허용 다운타임	연간 허용 다운타임	실제 의미
99% (“two nines”)	약 7시간 18분	약 3일 15시간	하루 단위 장애가 발생해도 목표 충족
99.9% (“three nines”)	약 43분	약 8시간 45분	간헐적 단기 장애는 허용, 대부분 SaaS 기본 수준
99.95%	약 21분	약 4시간 22분	금융/결제 시스템 등 민감 서비스에 적용
99.99% (“four nines”)	약 4분 23초	약 52분	미션 크리티컬 서비스 수준
99.999% (“five nines”)	약 26초	약 5분	통신망·금융 인프라 등 초고신뢰 환경에서만 가능

이 표를 보면,

99.9%와 99.99%의 차이는 한 달에 40분의 다운타임 차이에 불과하지만,
이를 달성하기 위해선 운영 복잡도와 비용이 기하급수적으로 상승한다는 점이 핵심이다.

따라서 SLO는 단순히 “높을수록 좋다”가 아니라,
비즈니스 리스크와 비용 사이의 균형점으로 설정해야 한다.

4) 조직 내 SLO 정의 주도권

SLO는 기술적 지표이지만 비즈니스 가치에 기반해야 한다.
따라서 비즈니스, 개발, 운영(DevOps) 세 영역이 협업해야 한다.

역할 주도 범위 주요 책임

역할	주도 범위	주요 책임
비즈니스팀	서비스 가치 정의	사용자 관점의 품질 기대치 정의
개발팀	SLI 측정 정의	코드 수준에서 측정 가능성 확보
운영(DevOps/SRE)	SLO 설계 및 모니터링	SLO 목표 수립, 에러 버짓 관리, Datadog 경보 설정

가장 효율적인 구조는 운영팀 주도 + 비즈니스 승인 + 개발 협력 형태다.
Datadog의 Service Level Objectives 기능을 사용하면 메트릭부터 SLO, 알람까지 일원화된 파이프라인으로 관리할 수 있다.
예:

SLO: 99.9% API 성공률  
SLI: request.success_rate{service:web}  
Alert: 에러 버짓 70% 소진 시 Slack 경보 발송

5) 실무 설계 예시

항목	SLI	SLO	모니터링 툴
API 가용성	성공 요청 비율	99.9%	Datadog
응답 속도	P95 < 500ms	99%	Datadog APM
결제 성공률	결제 성공 건수 / 시도 건수	99.5%	Datadog Metrics

6) 요약

SLI는 “측정값”, SLO는 “목표”, SLA는 “계약”.
SLO 설계는 DevOps 주도로, 비즈니스의 승인과 개발의 협력 아래 추진.
Datadog의 SLO 대시보드를 활용하면 에러 버짓 기반 운영이 수월하다.

2. 장애 대응과 신뢰성 지표 (RPO, RTO, MTTx 시리즈)

1) 핵심 개념 정리

용어	정의	목적
RPO (Recovery Point Objective)	데이터 손실 허용 범위 (예: 백업 주기)	데이터 보전
RTO (Recovery Time Objective)	복구 완료까지 걸릴 목표 시간	서비스 연속성
MTTD (Mean Time To Detect)	장애 감지까지 평균 소요 시간	관측성
MTTA (Mean Time To Acknowledge)	대응 시작까지 걸린 평균 시간	경보 반응성
MTTR (Mean Time To Resolve/Repair)	장애 해결까지 평균 시간	복구 효율성

2) 장애 발생 시 대응 절차

탐지 (Detection)
Datadog의 Alert + PagerDuty 연동으로 이상 탐지
MTTD 단축을 위해 로그, 메트릭, 트레이싱을 통합 관측
인식 및 대응 개시 (Acknowledgement)
자동 on-call 호출, Slack 통합 알림
MTTA 단축을 위해 담당자 교대 체계 자동화
조치 및 복구 (Mitigation & Recovery)
Runbook 기반 자동화된 대응 (예: Lambda로 재시작, 롤백)
RTO 내 복구를 목표로 함
사후 분석 (Postmortem)
장애 원인, RPO/RTO 충족 여부, 대응 속도 분석
재발 방지 대책과 Runbook 업데이트

3) RTO 단축을 위한 비용 효율적 접근

즉시효과: Runbook 자동화
Datadog Incident Management + Lambda 스크립트로 복구 자동화
운영자 개입 최소화로 MTTA/MTTR 동시 단축
비용: 낮음 / 효과: 높음
중기적 개선: 블루-그린 또는 카나리 배포
장애 시 빠른 롤백으로 RTO를 수분 단위로 단축
비용: 중간 / 효과: 안정성 향상
장기적 안정화: 멀티 AZ 또는 리전 복제
장애 시 자동 Failover
Datadog으로 리전별 헬스 체크 및 latency 모니터링
비용: 높음 / 효과: 최고 수준의 복구 성능

4) 요약

RPO/RTO는 복구 목표 지표, MTTD~MTTR은 운영 효율성 지표.
RTO를 단축하려면 “Runbook 자동화 → 블루-그린 배포 → 리전 복제” 순으로 투자.

장애는 피할 수 없지만, 얼마나 빨리 복구하느냐가 DevOps 성숙도를 결정한다.