SRE 실무 #1 SLI·SLO 설계: 무엇을 측정하고 몇 9를 약속할 것인가
SRE와 DevOps의 차이에서 SRE의 핵심이 “신뢰성을 숫자로 계약하는 것"이라고 정리했고, SLI·SLO·SLA 구분에서 세 용어를 정리했습니다. 이 시리즈는 그다음 질문에 답합니다. 그래서 실제로 어떻게 하는가? 첫 편은 모든 것의 출발점인 SLI와 SLO를 설계하는 과정입니다. 개념은 알아도 “우리 서비스의 SLO를 정하라"는 업무 앞에서 막히는 지점들을 순서대로 풀어 갑니다.
출발점은 대시보드가 아니라 사용자 여정입니다 #
가장 흔한 실수는 이미 수집 중인 메트릭 목록(CPU, 메모리, 스레드 수)에서 SLI를 고르는 것입니다. CPU 사용률 90%는 사용자에게 아무 의미가 없습니다. 사용자가 느끼는 것은 “체크아웃이 되는가”, “검색 결과가 빨리 나오는가"입니다.
그래서 설계는 핵심 사용자 여정(CUJ, Critical User Journey)을 나열하는 데서 시작합니다. 이커머스라면 이렇게 됩니다.
- 상품 검색 → 결과 표시
- 상품 페이지 열람
- 장바구니 담기 → 결제 완료
여정마다 “이것이 안 되면 사용자가 서비스가 고장 났다고 느끼는가?“를 물어서 우선순위를 정합니다. 결제는 무조건 상위이고, 최근 본 상품 위젯은 하위입니다. SLO는 상위 여정부터, 처음에는 2〜3개만 만듭니다. 처음부터 수십 개를 만들면 아무도 안 보는 문서가 됩니다.
좋은 SLI는 비율입니다: good events / total events #
여정을 골랐으면 그 여정의 상태를 나타낼 지표, SLI를 정의합니다. 실무에서 검증된 형태는 하나로 수렴합니다. 전체 이벤트 중 좋은 이벤트의 비율입니다.
| 유형 | SLI 정의 예 |
|---|---|
| 가용성 | 5xx가 아닌 응답 수 / 전체 요청 수 |
| 지연 시간 | 300ms 안에 완료된 요청 수 / 전체 요청 수 |
| 품질 | 완전한 응답(폴백 아님) 수 / 전체 응답 수 |
| 신선도 | 5분 이내 데이터로 응답한 수 / 전체 응답 수 |
비율 형태가 좋은 이유는 세 가지입니다. 0〜100%로 정규화되어 SLO와 바로 연결되고, 트래픽 규모와 무관하게 비교할 수 있고, 에러 버짓 계산이 자연스럽게 따라옵니다.
지연 시간에서 주의할 점 하나. “평균 응답 시간 300ms"는 SLI로 쓰지 않습니다. 평균은 소수의 매우 느린 요청을 가려 버립니다. “300ms 이내에 처리된 요청의 비율 99%“처럼 임계값 + 비율로 정의하면 느린 꼬리가 그대로 드러납니다. 백분위수(p99)로 관리하는 방법도 같은 문제의식의 다른 표현입니다.
어디서 측정하는가: 측정 지점의 트레이드오프 #
같은 SLI라도 측정 위치에 따라 값이 달라집니다.
- 서버(애플리케이션) 측정: 구현이 쉽지만, 서버까지 도달하지 못한 실패(DNS, 네트워크, 로드밸런서 장애)가 빠집니다. 실제보다 좋게 나옵니다.
- 로드밸런서 측정: 서버 다운까지 잡히고 구현 비용도 낮아서, 실무의 기본값으로 가장 균형이 좋습니다.
- 클라이언트(RUM) 측정: 사용자가 실제로 겪은 것과 가장 가깝지만, 사용자 기기와 네트워크 문제까지 섞여 들어와서 우리가 통제할 수 없는 노이즈가 커집니다.
원칙은 이렇습니다. 가능한 한 사용자에 가깝게 측정하되, 우리가 통제할 수 있는 범위 안에서. 대부분의 팀에게 답은 로드밸런서 로그이고, 여력이 생기면 클라이언트 측정을 보조 지표로 추가합니다.
SLO 수치: 열망이 아니라 현재 성능에서 출발합니다 #
“몇 9로 할까"를 회의실에서 정하는 것은 순서가 거꾸로입니다. 올바른 순서는 이렇습니다.
- 현재 성능을 측정합니다. 지난 4주의 실제 SLI가 99.94%라면, 그것이 출발점입니다.
- 사용자 기대와 대조합니다. 지금 성능에서 사용자 불만이 없다면, 현재 성능 근처(99.9%)가 합리적 SLO입니다. 불만이 있다면 목표를 올리고 개선 작업을 계획합니다.
- 비용을 확인합니다. 9 하나를 더 붙일 때마다 비용은 곱으로 늘어납니다. 99.99%는 월 4분의 장애 허용인데, 사람이 페이지를 받고 대응하는 데만 몇 분이 걸립니다. 이 수준부터는 자동 복구 설계가 전제되어야 하고, 그만한 투자가 그 서비스에 정당한지 물어야 합니다.
기억할 문장은 하나입니다. SLO는 마케팅 숫자가 아니라 운영 약속입니다. 지킬 수 없는 99.99%보다 지켜지는 99.9%가 팀과 사용자 모두에게 낫습니다. 그리고 100%는 어떤 서비스에도 올바른 목표가 아닙니다. 100%를 목표로 하는 순간 모든 변경이 적이 되고, 배포는 멈춥니다.
측정 창: 롤링 4주가 기본값입니다 #
SLO는 기간과 함께 정의됩니다. “28일 롤링 윈도우에서 99.9%“처럼 씁니다.
- 롤링(rolling) 창은 항상 최근 N일을 봅니다. 장애의 영향이 창에서 서서히 빠져나가므로 운영 감각과 잘 맞습니다. 4주(28일)가 사실상 표준입니다. 요일 패턴을 정확히 4번 포함하기 때문에 30일보다 안정적입니다.
- 달력(calendar) 창은 분기·월 단위로 리셋됩니다. 계약(SLA)과 보고에는 맞지만, 창이 리셋되는 순간 버짓이 갑자기 회복되는 어색함이 있습니다.
내부 운영은 롤링 28일, 대외 보고는 분기로 이원화하는 팀이 많습니다.
SLO 명세 문서에 적을 것들 #
설계 결과는 한 페이지 문서로 남깁니다. 최소 항목은 다음과 같습니다.
- SLI 정의: 좋은 이벤트와 전체 이벤트의 정확한 정의, 측정 위치(어느 로그, 어느 메트릭), 제외 조건(헬스체크 트래픽, 봇 등)
- SLO 목표와 창: 99.9% / 롤링 28일
- 소유자와 이해관계자: 이 SLO가 깨질 때 누가 움직이는가
- 에러 버짓 정책으로의 링크: 버짓이 소진되면 무엇을 하기로 합의했는가 (다음 편의 주제입니다)
- 재검토 주기: 최소 연 1회, 또는 서비스 특성이 바뀔 때
제외 조건을 명시하는 것이 특히 중요합니다. “계획된 점검은 포함인가”, “클라이언트 잘못(4xx)은 분모에 넣는가” 같은 질문을 장애 한가운데서 처음 논쟁하게 되면 이미 늦습니다.
정리 #
- SLI는 메트릭 목록이 아니라 핵심 사용자 여정(CUJ)에서 출발합니다. 처음에는 상위 여정 2〜3개만 SLO를 만듭니다.
- 좋은 SLI는 good/total 비율 형태입니다. 지연 시간은 평균이 아니라 “임계값 이내 비율"로 정의합니다.
- 측정은 사용자에 가깝게, 단 통제 가능한 범위에서. 실무 기본값은 로드밸런서입니다.
- SLO 수치는 현재 성능에서 출발해 사용자 기대·비용과 대조해 정합니다. 100%는 목표가 아닙니다.
- 창은 롤링 28일이 기본이고, 정의·제외 조건·소유자를 문서로 남깁니다.
- 다음 편은 이 SLO에서 나오는 에러 버짓을 실제로 운영하는 법, 정책과 번 레이트입니다.