SLO — 얼마까지 망가져도 되는지 정한다 · 예산과 번 레이트 · 이론

번 레이트로 알림을 건다

LabHub 에서 이어서 보기

한 줄 요약

번 레이트로 알림을 걸면, 울려야 할 때 울고 조용해야 할 때 조용해진다.

99.9% 는 한 달에 43분이다

| SLO | 한 달(30일) 허용 |
|---|---|
| 99% | 7.2시간 |
| 99.9% | 43.2분 |
| 99.95% | 21.6분 |
| 99.99% | 4.32분 |

99.9 와 99.99 는 표기가 한 자리 차이인데 열 배다. 계약서에 99.99% 를 적기 전에 이 표를 봐야 한다 — 한 달에 4분이면 배포 한 번 잘못해도 끝이다.

에러 예산은 쓰라고 있는 것이다

99.9% 를 목표로 했다면 0.1% 는 써도 되는 몫이다. 안 쓰고 남기는 것이 잘한 게 아니다 — 예산이 계속 남는다면 목표가 너무 낮거나, 배포를 너무 안 하고 있는 것이다.

이 관점이 SLO 의 핵심이다. 완벽을 목표로 하지 않고 얼마까지 망가져도 되는지 합의한다.

번 레이트

오류율이 허용치의 몇 배인가를 번 레이트라고 한다.

1배 → 기간이 끝날 때 예산을 딱 다 쓴다(설계대로)
14.4배 → 2.08일 만에 다 쓴다

14.4 라는 숫자는 이렇게 나온다 — 1시간에 한 달 예산의 2%를 태우는 속도다.

0.02 × 30일 × 24시간 = 14.4

이 속도면 지금 깨워야 한다. 반대로 2배쯤이면 티켓으로 충분하다.

지금 알림은 왜 쓸모없나

흔한 규칙 하나를 보자.

5분 오류율 > 1%

SLO 가 99.9%(0.1% 허용)인데 이 규칙은 거기서 나온 게 아니다. 그래서 둘 다 일어난다.

조용해야 하는데 운다 — 새벽에 1.2%가 5분 튀었다. 예산은 거의 안 줄었는데 사람이 깼다
울어야 하는데 조용하다 — 0.5%가 한 달 내내다. 예산의 5배를 썼는데 임계값 아래라 아무 일도 없었다

> 알림 피로는 알림이 많아서 생기는 게 아니라 쓸모없는 알림이 많아서 생긴다.

번 레이트로 다시 쓰면

오류율 > 14.4 × (1 - SLO)

SLO 가 99.9% 면 임계값은 0.0144(1.44%)다. 숫자만 보면 비슷해 보이지만 의미가 다르다 — 이건 "1시간에 예산의 2%를 태우는 중" 이라는 뜻이고, 그래서 무엇을 해야 하는지가 따라온다.

알림 이름도 바꾼다. HighErrorRate 가 아니라 ErrorBudgetBurnFast 다. 이름이 대응 방법을 정한다.

창이 하나면 부족하다

짧은 창(5분)만 → 잠깐 튀는 것에 깨어난다
긴 창(1시간)만 → 빠르게 타는 것을 늦게 안다

그래서 둘을 and 로 묶는다. 짧은 창과 긴 창이 둘 다 넘을 때만 운다. 순간적인 튐은 걸러지고 진짜 소진은 빨리 잡힌다.

그리고 심각도를 나눈다.

| 번 레이트 | 창 | 대응 |
|---|---|---|
| 14.4 | 5분 + 1시간 | 즉시 호출 |
| 6 | 30분 + 6시간 | 즉시 호출 |
| 3 | 2시간 + 1일 | 티켓 |
| 1 | 6시간 + 3일 | 티켓 |

알림도 시험해야 한다

가장 자주 빠지는 부분이다. promtool 은 알림 규칙의 단위 시험을 지원한다.

promtool test rules test.yml

가짜 시계열을 넣고 "이때 이 알림이 울어야 한다" 를 단언한다. 이게 없으면 장애가 났을 때 정작 안 우는 알림을 배포하게 된다 — 그리고 그건 장애 중에야 알게 된다.

그리고 울리면 안 될 때 조용한지도 시험한다(exp_alerts: []). 울릴 때만 시험하면 절반이다.

예산이 바닥나면

여기에 답이 없으면 SLO 는 장식이다.

미리 합의해 둘 것 —

새 기능 배포를 멈추고 안정화에 쓴다
위험한 변경은 예산이 회복될 때까지 미룬다
반복 원인을 다음 스프린트의 최우선으로 올린다

숫자를 정하는 것보다 이 합의가 어렵고, 이게 없으면 숫자는 아무 일도 하지 않는다.

현장에서

이 방식을 도입할 때 가장 먼저 부딪히는 것은 기술이 아니라 합의입니다. 99.9% 를 적어 두는 것은 쉽지만, 예산이 절반 남았을 때 무엇을 멈출지를 미리 정하는 일은 제품 쪽과 이야기해야 하고 그 대화가 늘 편하지는 않습니다.

그래서 처음에는 알림을 걸지 않고 관측만 하는 기간을 두는 편이 낫습니다. 한두 달치 실제 소진 곡선을 보고 나면 99.9% 가 우리 서비스에 맞는 숫자인지, 아니면 99.5% 로도 아무도 불평하지 않는지가 드러납니다. 지킬 수 없는 숫자를 걸어 두면 예산은 매달 첫 주에 바닥나고, 그러면 아무도 그 숫자를 보지 않게 됩니다.

그리고 SLI 를 무엇으로 잴지가 생각보다 큰 결정입니다. 로드밸런서에서 재면 애플리케이션이 죽어도 5xx 로 잡히지만 클라이언트 쪽 실패는 안 보이고, 애플리케이션에서 재면 반대가 됩니다. 어디서 재고 있는지를 문서에 한 줄 적어 두면 나중에 숫자를 두고 벌어지는 논쟁이 크게 줄어듭니다.