SLO는 깨졌는데 burn rate 알림은 안 울렸다

 

지난 화요일 오전, 한 사용자한테 문의가 들어왔다. "결제 콜백이 가끔 실패한다"고. PM이 슬랙에 던진 메시지였는데, 솔직히 그때까지 우리는 아무 알림도 못 받은 상태였다. SLO 대시보드를 켰다. 99.5% 목표인 가용성 SLI가 99.1%까지 떨어져 있었다. error budget이 이미 절반 가까이 타들어간 상태였다.

근데 burn rate 알림은 조용했다. 한 번도 안 울렸다.

우리가 깔아둔 알림 구성

Google SRE 워크북에 나오는 multi-window multi-burn-rate 패턴 그대로였다. 페이지(긴급) 알림은 1시간 윈도우 + 5분 윈도우 둘 다 14.4배 burn rate를 넘기면 발사. 티켓(완만) 알림은 6시간 + 30분 윈도우에 6배 burn rate. 표준 구성이다.

- alert: SLOBurnRateFast
  expr: |
    (
      sum(rate(http_requests_total{status=~"5.."}[1h]))
      /
      sum(rate(http_requests_total[1h]))
    ) > (14.4 * 0.005)
    and
    (
      sum(rate(http_requests_total{status=~"5.."}[5m]))
      /
      sum(rate(http_requests_total[5m]))
    ) > (14.4 * 0.005)

5분 윈도우에 burn rate 14.4배면 일반적인 시간대에는 못 봐줄 수치다. SLI 식대로면 5분 안에 에러율이 7.2%를 넘어야 한다는 얘긴데, 우리 서비스는 평소 0.05% 정도였으니까. 안 울릴 리가 없다고 생각했다.

트래픽 자체가 적었다

문제는 이 결제 콜백 엔드포인트의 트래픽이었다. 평일 낮에는 분당 200~300건씩 들어오는데, 새벽이랑 주말 새벽은 분당 5~10건까지 떨어진다. 5분 윈도우로 잘라보면 25~50건 정도. 이 중에 3건이 500 떨어지면 에러율이 6~12%까지 튀는데, 이게 30분~1시간 동안 단속적으로 발생했다.

긴 윈도우(1시간)는 5건 정도의 에러를 1500건 정도 트래픽에 희석시켜 봤더니 burn rate가 약 4배 정도밖에 안 됐다. 페이지 알림 임계인 14.4배 근처에도 안 갔다. 5분 윈도우는 한 번씩 튀어 올랐는데, 같은 시점에 1시간 윈도우는 안 튀니까 and 조건이 막아버렸다.

결국 알림은 안 울리고, error budget만 야금야금 잠식됐다. 30분 윈도우 + 6시간 윈도우의 티켓 알림도 마찬가지. 모든 윈도우가 동시에 임계를 넘지 못해서 둘 다 침묵했다.

디버깅하다가 멘탈이 좀 나갔다

처음에는 PromQL 식 자체를 의심했다. rate() vs increase(), status 라벨 매칭, 분모 0 처리 등등 하나씩 다 뜯어봤는데 식 자체는 멀쩡했다. 같은 식을 Grafana에 꽂아보니 burn rate 값이 정확하게 나왔다. 그래서 한참 동안 "왜 안 울리지"만 들여다봤다.

깨달은 건 한참 뒤였다. 우리가 보던 burn rate 그래프 자체가 임계를 안 넘고 있었다. 알림 식이 잘못된 게 아니라 알림 임계가 우리 상황에 맞지 않은 거였다. 14.4배라는 숫자는 "1시간 안에 30일치 error budget의 2%를 태우는 속도"라는 의미인데, 트래픽이 적으면 절대 에러 개수가 작아도 비율로 이몝에 춑분히 깨질 수 있다. 비율 기반 burn rate가 절대량을 못 장하는 겄을��다..

우리가 임시로 한 것

긑한 대로 두 가지를 했다.

좬에는 스베틴 앜래 당성 보리를 깁았다. 5분에 에렼가 3건 이상이면 일전 티켓이 뜨도록.

- alert: AbsoluteErrorBurst
  expr: |
    sum(increase(http_requests_total{status=~"5.."}[5m])) >= 3
  for: 5m

둘째, 저트래픽 시간대(0시~7시, 주말)에는 burn rate 임계를 낮�)�다. recording rule로 시간대 라벨을 붙이고, 알림 식에서 시간대별로 임계를 다륹���첸갸;���0잡았다. 이건 �지적분한 해뱕임멌 일이 는 폨윷지가 우리 는 거 우선이라니 깨를스.

더 나은 방법이 있음 수 도 있다

췫아보낰 세대로 Grafana 블로그나 oneuptime 글들에서는 저트래픽 서비스에 대해 비슷한 지적을 한다. 해법으로 제안되는 건 대체로 비슷하다. 윈도우를 늘리거나, request 단위가 아니라 시간 단위로 SLI를 재정의하거나, synthetic traffic을 주입해서 분모를 안정화시키거나.

우리 팀에서는 다음 분기에 SLI를 다시 손볼 예정이다. 결제 콜백은 사실 단순한 가용성보다 "5분 안에 처리 성공" 같은 시간 기반 SLI가 더 적합한 것 같다. 근데 그건 또 그것대로 윈도우 정의가 복잡해서, 도입 전에 좀 더 검증이 필요하다.

burn rate 알림은 좋은 도구다. 다만 좋은 도구가 모든 상황에 잘 맞는 건 아니라는 걸 이번에 다시 배웠다. SLO를 굴리시는 분들 중에 비슷한 경험 있으시면 어떻게 푸셨는지 댓글로 좀 알려주시면 감사하겠다.