SLI, SLO, SLA 정리: 측정하고, 목표를 세우고, 약속하기

온콜 정리의 끝에서 남겨 둔 질문이 있었죠. 오류율 알림의 임계값을 5%로 할지 1%로 할지를 놓고 팀 안에서 의견이 갈리는 상황이요. 개발 쪽은 “1%는 너무 빡빡해서 배포할 때마다 울린다”고 하고, 운영 쪽은 “5%면 사용자 스무 명 중 한 명이 실패하는 건데 그걸 그냥 둘 거냐”고 합니다. 둘 다 틀린 말은 아닌데 대화가 끝나지 않아요. 🤔

이 논쟁이 안 끝나는 이유는 “우리 서비스가 얼마나 실패해도 괜찮은가”를 먼저 정하지 않았기 때문입니다. 그 기준을 세우는 도구가 SLI, SLO, SLA인데요. 비슷하게 생긴 세 약어가 각각 무엇을 가리키는지, 왜 그 순서로 정해야 하는지, 그리고 이게 있으면 알림 임계값 논쟁이 어떻게 끝나는지를 정리해 보겠습니다.

세 글자가 가리키는 세 가지

셋 다 서비스 수준(Service Level)으로 시작합니다. 서비스가 얼마나 잘 동작하는지를 다루는 말이라는 뜻이죠. 마지막 글자가 역할을 가릅니다.

SLI(Service Level Indicator)는 지표입니다. 서비스가 지금 얼마나 잘 동작하는지를 숫자 하나로 나타낸 측정값이에요. “최근 30일 동안 요청의 99.95%가 성공했다”에서 99.95%가 SLI입니다.

SLO(Service Level Objective)는 목표입니다. SLI가 어느 값 이상이어야 하는지를 정한 내부 기준이에요. “30일 동안 가용성 99.9% 이상”이 SLO입니다. 앞의 SLI 99.95%는 이 목표를 넘기고 있는 상태고요.

SLA(Service Level Agreement)는 계약입니다. 고객에게 어떤 수준을 약속하고 못 지키면 무엇을 보상할지를 적은 문서예요. “월 가용성 99.5% 미만이면 요금의 10%를 크레딧으로 돌려준다”가 SLA입니다.

그러니까 SLI로 재고, SLO를 목표로 삼고, SLA로 약속합니다. 세 개념은 Google이 2016년에 낸 Site Reliability Engineering 책에서 정리한 정의가 그대로 업계 표준이 된 경우라 도구나 회사가 달라도 이름이 갈리지 않습니다. 앞선 글에서 다룬 알림 규칙이나 사일런스처럼 도구마다 다르게 부르는 일이 여기서는 거의 없어요.

SLI: 무엇을 잴 것인가

SLI를 정하는 가장 실용적인 방법은 비율로 만드는 겁니다. 좋은 이벤트를 전체 이벤트로 나누는 거죠.

가용성 SLI  = 성공한 요청 수 / 전체 요청 수
지연 시간 SLI = 300ms 안에 응답한 요청 수 / 전체 요청 수

가용성(availability) SLI는 알림 규칙 정리에서 다룬 오류율을 뒤집은 것입니다. 오류율이 0.05%면 가용성은 99.95%죠. 지연 시간(latency) SLI가 조금 더 흥미로운데 “p99 응답 시간이 300ms 이하”라는 백분위 표현을 “요청의 99%가 300ms 안에 응답”이라는 비율로 바꿔 적은 겁니다. 이렇게 비율로 통일해 두면 가용성과 지연 시간을 같은 잣대(0에서 100% 사이)로 놓고 볼 수 있고 에러 예산을 계산할 때도 같은 식을 쓸 수 있습니다.

무엇을 잴지 고를 때 기준은 하나입니다. 사용자가 실제로 겪는 것을 재야 한다는 거예요. CPU 사용률이나 큐 길이는 SLI가 아닙니다. 사용자는 CPU를 보지 않으니까요. 사용자가 보는 건 요청이 성공했는지, 얼마나 기다렸는지 같은 것들입니다. 알림 규칙 글에서 증상 기반 알림을 이야기했는데 SLI는 그 증상을 숫자로 정의한 것이라고 봐도 됩니다.

개수도 중요합니다. 서비스 하나에 SLI를 열 개 두면 아무도 안 봅니다. 사용자 여정에서 가장 중요한 두세 개만 고르는 게 좋아요. 결제 서비스라면 결제 요청 성공률과 결제 완료까지의 지연 시간 정도로 시작하고, 나머지는 일반 지표로 남겨 둡니다.

어디서 재느냐도 값을 바꿉니다. 같은 “성공률”이라도 서버 로그로 재면 서버까지 도달한 요청만 세고, 로드 밸런서에서 재면 서버가 죽어서 응답 못 한 요청까지 셉니다. 사용자 브라우저에서 재면 네트워크 문제까지 잡히고요. 사용자에게 가까운 곳에서 잴수록 정직한 SLI가 되지만 측정이 어려워지니 처음엔 로드 밸런서나 게이트웨이처럼 서버 앞단에서 재는 게 현실적인 타협입니다.

SLO: 얼마나 좋아야 하는가

SLI가 정해지면 SLO는 세 가지를 붙이는 일입니다. 어느 SLI를, 어느 값 이상으로, 어느 기간 동안. “가용성 SLI를 30일 동안 99.9% 이상으로”가 완성된 SLO예요.

기간이 빠지면 SLO가 아닙니다. “99.9%“만 있으면 지난 1분 이야기인지 지난 1년 이야기인지 알 수 없거든요. 보통 최근 30일처럼 굴러가는 창(rolling window)을 쓰는데 달력 기준 한 달을 쓰기도 합니다. 굴러가는 창은 언제 봐도 최근 한 달을 평가하니 감이 일정하고, 달력 월은 청구서 주기와 맞아서 SLA와 연결하기 좋습니다.

그러면 99.9%라는 숫자는 어디서 올까요? 이 표를 보면 감이 옵니다. 30일을 기준으로 각 목표가 허용하는 장애 시간이에요.

9가 하나 늘 때마다 허용 시간이 10분의 1로 줄어듭니다. 99.9%면 한 달에 43분인데 배포 한 번 잘못하면 쓸 수 있는 시간이에요. 99.99%의 4.3분은 사람이 알림을 받고 노트북을 여는 시간보다 짧습니다. 그 수준은 사람이 대응해서 지키는 게 아니라 자동 복구가 있어야 지켜지는 숫자죠.

그래서 100%는 목표가 아닙니다. 두 가지 이유가 있어요. 우선 9를 하나 더 붙이는 비용이 선형이 아니라 지수적으로 늘어납니다. 99.9%에서 99.99%로 가려면 이중화에 자동 장애 조치, 무중단 배포까지 다 필요하죠. 또한 사용자는 어느 지점부터 차이를 못 느낍니다. 사용자의 휴대폰과 통신사 네트워크가 이미 99.99%보다 자주 실패하고 있어서 우리 서비스가 그보다 좋아져도 사용자 경험은 그대로예요. 100%를 목표로 잡는 순간 배포도 실험도 할 수 없게 되는데 그 대가로 얻는 게 없습니다.

적당한 SLO는 “지금 이 정도면 사용자가 불평하지 않는다”는 지점보다 살짝 높은 곳입니다. 현재 SLI가 99.95%인데 아무도 불평하지 않는다면 99.9%를 SLO로 잡고 시작해도 됩니다. 처음부터 높게 잡을 이유가 없어요. 안 지켜지는 SLO는 있으나 마나입니다.

SLA: 약속을 어기면 무슨 일이 생기는가

SLA는 SLO에 결과가 붙은 겁니다. 외부 고객과 맺는 계약이고 못 지키면 크레딧이나 환불 같은 보상이 따릅니다. 그래서 SLA에는 SLO에 없는 사람들이 등장해요. 법무, 영업, 고객사 담당자. 숫자도 엔지니어 혼자가 아니라 그 사람들과 함께 정합니다.

여기서 헷갈리는 게 하나 있습니다. SLA의 숫자는 SLO보다 느슨해야 한다는 거예요. 내부 목표가 99.9%면 외부 약속은 99.5% 정도로 잡습니다. 처음 들으면 이상하죠. 고객에게는 더 좋은 걸 약속해야 하는 거 아닌가 싶으니까요.

이유는 여유입니다. SLO는 내부 경보선이라 넘겨도 아직 계약 위반은 아닙니다. 99.9%를 놓쳤을 때 “위험하다, 안정화에 집중하자”고 방향을 틀 시간이 생기고 그렇게 대응하면 99.5%에는 도달하지 않아요. SLO와 SLA를 같은 숫자로 잡으면 내부 목표를 놓치는 순간이 곧 보상 지급 순간이 되어서 조치할 여유가 없습니다.

또 하나, 대부분의 팀은 SLA가 필요 없습니다. 외부 고객에게 서비스를 파는 게 아니라면 계약도 보상도 없죠. 사내 서비스나 내부 API라면 SLO만 있으면 됩니다. SLA라는 말이 더 유명하다 보니 SLO를 말하면서 SLA라고 부르는 경우가 많은데 보상이 안 붙어 있으면 그건 SLO입니다.

SLO 문서에는 무엇을 적을까

SLO를 정했으면 한 페이지짜리 문서로 남겨 둡니다. 숫자 하나만 적어 두면 석 달 뒤에 “이거 어디서 잰 거였지?”가 되거든요. 들어가야 할 건 네 가지입니다.

우선 SLI의 정의와 측정 위치입니다. “성공률”이 아니라 “로드 밸런서에서 센 요청 중 5xx가 아닌 응답의 비율”처럼 어디서 무엇을 세는지까지 적습니다. 앞에서 봤듯 측정 위치가 바뀌면 같은 이름의 SLI도 값이 달라지니까요. 또한 목표와 기간입니다. “99.9%, 최근 30일 굴러가는 창”처럼 둘을 한 쌍으로 둡니다. 그리고 예외입니다. 미리 공지한 점검 시간을 제외할 것인지, 특정 클라이언트의 요청은 뺄 것인지 같은 것들이에요. 예외를 문서에 적지 않으면 장애가 났을 때 “그건 점검이었다”는 말이 사후에 나오고 그러면 SLO는 신뢰를 잃습니다. 마지막으로 이 SLO를 놓쳤을 때 무엇을 할지입니다. 이건 에러 예산과 이어지는 부분이라 여기서는 항목만 짚어 둘게요.

문서는 엔지니어만 보는 게 아닙니다. 제품 담당자가 “이 기능은 왜 아직 안 나오나”라고 물을 때 “이번 달 SLO를 놓쳐서 안정화 중”이라고 답할 근거가 되고, 영업이 고객에게 숫자를 말하기 전에 확인할 출처가 됩니다.

왜 이 순서로 정하는가

SLI 없이 SLO를 세울 수 없고, SLO 없이 SLA를 맺을 수 없습니다. 재지 않는 것을 목표로 삼을 수 없고, 목표도 없는 것을 약속할 수 없으니까요. 당연한 순서인데 현장에서는 거꾸로 가는 일이 잦습니다.

영업이 고객사에 99.99%를 약속하고 돌아옵니다. 엔지니어링 팀은 그 숫자를 계약서에서 처음 봅니다. 그런데 가용성을 재는 SLI가 아직 없어요. 급하게 만들어 보니 지난달 실제 가용성은 99.8%였습니다. 이런 상황은 SLA가 SLI보다 먼저 생겨서 벌어집니다. 순서를 지킨다는 건 “우리가 지금 어디 있는지”를 먼저 알고 “어디까지 갈지”를 정한 다음에야 “어디까지 약속할지”를 말한다는 뜻이에요.

SLO가 알림을 바꾼다

이제 도입부의 논쟁으로 돌아가 볼게요. 오류율 임계값을 5%로 할지 1%로 할지. SLO가 있으면 질문의 형태가 바뀝니다.

가용성 SLO가 30일 동안 99.9%라면 30일 평균 오류율은 0.1%를 넘으면 안 됩니다. 이게 기준선이에요. 5%든 1%든 SLO 기준선보다 훨씬 위에 있는 숫자라 그 오류율이 잠깐 이어지는 것만으로도 30일 치 허용량을 빠르게 갉아먹습니다. 그러니까 질문은 “몇 %에서 알릴까”가 아니라 “이 속도로 실패하면 30일 허용량이 언제 바닥나는가”로 바뀝니다. 그 속도가 빠르면 사람을 깨우고, 느리면 ticket으로 남기는 거죠.

알림 규칙 글에서 임계값은 정답이 아니라 가설이라고 했는데 SLO는 그 가설을 세울 근거를 줍니다. 5%가 맞는지 1%가 맞는지를 놓고 감으로 다투는 대신 “SLO를 얼마나 빨리 위협하는가”라는 계산 문제로 바꾸는 거예요. 그 계산에 쓰는 도구가 에러 예산인데, 그건 다음 글에서 다루겠습니다.

마치며

SLI는 사용자가 겪는 것을 좋은 이벤트를 전체 이벤트로 나눈 비율로 잰 값이고, SLO는 그 값이 어느 기간 동안 어느 수준 이상이어야 하는지 정한 내부 목표이며, SLA는 목표를 외부에 약속하고 못 지키면 보상하는 계약입니다. 순서는 늘 SLI, SLO, SLA이고, SLA의 숫자는 SLO보다 느슨하게 잡아 대응할 여유를 둡니다. 100%는 목표가 아니며, 적당한 SLO는 사용자가 불평하지 않는 지점보다 살짝 높은 곳입니다.

SLO를 정하면 “30일 동안 0.1%까지 실패해도 된다”는 허용량이 생깁니다. 그 허용량을 예산처럼 쓰고 관리하는 방법은 에러 예산 정리에서 이어집니다.

세 개념의 원래 정의는 Google의 Site Reliability Engineering 책 Service Level Objectives 챕터를 참고하세요.