SRE
SRE가 뭔데
Google이 2003년에 만든 직군이자 운영 방법론이다.
핵심은 이 한 문장이다.
"소프트웨어 엔지니어링 방식으로 운영 문제를 해결한다"
기존에는 개발팀이 코드를 만들면 운영팀이 서버를 관리하는 구조였는데,
서비스가 커질수록 수동 운영이 불가능해졌다.
Google이 "그냥 운영도 코드로 자동화하면 되지 않나?"라고 생각한 게 시작이다.
DevOps랑 자주 비교되는데 이렇게 이해하면 편하다.
-
DevOps : 개발과 운영이 협력해야 한다는 문화/철학
-
SRE : 그 철학을 어떻게 실행할지에 대한 구체적인 방법론
DevOps가 "뭘 해야 하는지"라면, SRE는 "어떻게 하는지"다.
SLI - 지금 서비스 상태를 수치로 측정하는 것
SLI(Service Level Indicator) 는 서비스 품질을 측정한 수치다.
중요한 건 "사용자가 체감하는 품질" 을 기준으로 잡아야 한다는 점이다.
좋은 SLI 예시
-
가용성 : 정상 응답 수 / 전체 요청 수 × 100 = 99.95%
-
오류율 : 5xx 오류 수 / 전체 요청 수 × 100 = 0.03%
-
응답시간 : 요청의 99%가 200ms 이내로 처리됨
나쁜 SLI 예시
-
CPU 사용률 80% → 사용자 입장에서 직접적인 영향이 아님
-
서버 대수 3대 → 서비스 품질을 나타내지 않음
SLI는 측정된 숫자 그 자체다. 여기에 아무 판단이나 행동이 들어오면 SLI가 아니다.
"현재 가용성이 99.7%이다" — 이게 SLI다.
SLO - 얼마나 유지해야 하는지 목표를 정하는 것
SLO(Service Level Objective) 는 SLI에 목표값을 붙인 것이다.
팀 내부에서 "이 수준은 지키자"고 정한 기준선이다.SLI : 현재 가용성이 99.7%이다 ← 측정값
SLO : 가용성은 99.9% 이상이어야 한다 ← 목표값SLO는 내부 기준이라서, 위반해도 고객한테 직접 책임지는 일은 없다.
다만 팀이 "뭔가 잘못됐다"는 신호로 받아들여야 한다.좋은 SLO를 정의하려면 세 가지 조건을 만족해야 한다.
-
사용자 관점 : 사용자가 느끼는 품질을 반영해야 한다
-
측정 가능 : 수치로 명확하게 측정할 수 있어야 한다
-
현실적 : 달성 가능한 수준이어야 한다 (100%는 현실적으로 불가능하다)
SLA - 고객한테 약속하는 것
SLA(Service Level Agreement) 는 SLO를 고객과 계약으로 맺은 것이다.
여기서부터 위반하면 패널티(환불, 크레딧 지급 등) 가 생긴다.SLO : 내부 목표 "우리 팀은 99.9% 유지하자"
SLA : 외부 계약 "고객에게 99.5% 보장, 위반 시 크레딧 지급"AWS S3 서비스 정책을 보면 이런 내용이 있다.
월간 가동률 99.9% 미만 시 서비스 크레딧 지급
이게 SLA다. AWS 내부에서 실제로 유지하는 SLO는 이것보다 훨씬 높게
설정되어 있을 것이다.
왜 SLA를 SLO보다 낮게 잡는지
처음에 이게 이해가 안 됐는데 이렇게 생각하면 된다.
SLO = 99.9% (내부 목표)
SLA = 99.5% (고객 보장)
↑
0.4% 차이 = 여유분SLO를 약간 못 지켜서 실제 가용성이 99.6%가 되더라도,
SLA(99.5%)는 지킬 수 있다. 고객 클레임이 발생하지 않는다.이 버퍼가 있어야 팀이 사고 없이 운영할 수 있다.
세 개념 정리
헷갈리지 않으려고 체온계로 비유해봤다.
SLI = 체온계 수치 (지금 38.2°C)
SLO = 의사의 목표 (37.5°C 이하로 유지)
SLA = 보험 계약 (40°C 이상이면 보험금 지급)표로 보면 이렇다.
용어 한 줄 요약 예시 SLI 측정된 수치 가용성 99.7% SLO 내부 팀의 목표값 가용성 99.9% 이상 유지 SLA 고객과의 계약 99.5% 보장, 위반 시 환불 외워야 할 것만 정리하면
-
SLA ≤ SLO (항상 SLA가 더 낮거나 같다)
-
SLI는 숫자만, SLO는 숫자 + 기준, SLA는 숫자 + 기준 + 패널티
-
SLO 위반은 팀 내부 문제, SLA 위반은 고객 클레임
