[멘토 질문] 99.9% SLO에서 멀티윈도우 Burn Rate 알럿을 저트래픽 환경에 현실적으로 적용/검증하는 기준(답변 희망 멘토: sean.wd)

[SuperSon7]

🙋질문자

판교 3기 / 5조(개발자지만 독서는 하고싶지?) - vani.kim(김정빈)/클라우드

🙋답변 희망 멘토

sean.wd(장수용)/ @waterdrag0n

✏️ 궁금한 내용

SLI/SLO를 정의하고 멀티윈도우 burn rate 모델까지 설계했는데, 99.9% 가용성 목표를 실제로 구현할 때(특히 저트래픽 환경에서) 현실적으로 어떤 기준으로 잡아야 하는지 궁금합니다. 또한 “트래픽이 있다고 가정”해서 설계하는 건 이해하지만, 지금 트래픽이 낮아서 알럿이 실제로 안 오거나 오탐이 나면 ‘제대로 동작하는지’ 검증이 어려운 문제가 있어 이 부분까지 조언을 받고 싶습니다.

[추가 이해를 위한 디테일한 질문]

1. 저트래픽에서 burn rate 알럿의 최소 유효 트래픽 기준이 있는지?
   99.9% 에러 버짓은 월 43분인데, 현재 서비스 트래픽이 분당 수십~수백 요청 수준이라 5m 윈도우에서 14.4x(P1)를 계산하면 분모가 작아 오탐이 심할 것 같습니다.

   • 실무에서 “이 수준 이하 트래픽이면 burn rate를 적용하지 않는다” 같은 최소 유효 트래픽/최소 이벤트 기준이 있는지
   • 또는 트래픽이 낮을 때는 burn rate 대신 다른 접근(예: 합성 트래픽, 임계치 기반, 오류 건수 기반 게이트 등)이 맞는지 궁금합니다.

2. Prometheus recording rule ↔ Grafana Unified Alerting 연결 방식

   • slo:api_error_rate:ratio_rate5m, ratio_rate1h 같은 recording rule을 Prometheus에 두고, Grafana 알럿 룰에서 해당 metric을 참조하는 방식이 맞는지
   • 아니면 Grafana 쪽에서 PromQL expression으로 burn rate 조건을 직접 구성하는 게 운영/디버깅 측면에서 더 나은지 확실하지 않습니다.

3. 임계치 알럿 13개 중 burn rate로 전환할 것 vs 임계치로 유지할 것 구분 기준

   • 예: disk > 95%는 burn rate가 의미 없을 것 같은데,
   • error_rate, p99 latency, hikari_pending 같은 것들은 어떤 기준으로 burn rate로 옮기고 어떤 건 임계치로 남겨야 하는지 궁금합니다.
     (특히 latency/p99나 커넥션/풀 관련 지표를 burn rate로 보는 게 적절한지 애매합니다.)

4. (어려움) “트래픽 가정 설계”와 “검증 가능성”의 갭
   프로젝트는 트래픽이 있다고 가정하고 99.9% 목표로 설계해야 한다고 생각하지만, 현실 트래픽이 낮으면 알럿이 안 와서 파이프라인이 정상인지/버짓 소진 감지가 되는지 검증이 어렵습니다.

   • 이런 상황에서 실무적으로는 알럿 파이프라인이 제대로 동작하는지(수집→룰→라우팅→Discord) 검증을 어떻게 하는지(예: watchdog/합성 트래픽/테스트 알럿 등) 조언을 받고 싶습니다.

👀 시도한 방식

• SLI/SLO 정의 완료: Wiki에 4개 SLI (로그인 가용성, 모임 진입, 가입 신뢰성, 글로벌 응답 지연) + CUJ 5개 (로그인, 채팅, 미팅, 독서기록, 회원관리)별 SLO 설정
• 목표 상향: MVP 99.0% → 99.9% 가용성 (월간 허용 장애 ~43분, 일간 ~1분 26초)
• burn rate 모델 설계 완료: P1(14.4x, 1h/5m), P2(6x, 6h/30m), P3(3x, 1d/2h), P4(1x, 3d/6h) 멀티윈도우
• recording rule PromQL 초안 작성: slo:api_error_rate:ratio_rate5m, ratio_rate1h 등
• 현재 알럿: 임계치 기반 13개 (error_rate > 50% CRITICAL, > 10% HIGH 등), burn rate 미전환
• PLG + Alloy, Grafana Unified Alerting, Discord 4채널 라우팅

⏭️ 이제 어떻게 하려고 하는지?

• 트래픽이 낮아도 알럿/라우팅이 정상 동작하는지 확인할 방법까지 함께 정리해 운영에 반영하려 합니다.

[waterdrag0n]

안녕하세요.

1. 절대적인 분모 자체가 적은 상황이니 모든 부분에서 burn rate을 보려고 하는것보다는 에러의 절대량을 같이 복합적으로 봐서 판단하도록 세팅하는게 나을 것 같습니다. 윈도우 내 에러 개수가 n개 이상일때만 burn rate을 통한 얼럿이 활성화되게 하면 어떨까요?

2. recording rule을 활용하는 방향을 추천드립니다. 프로메테우스가 항상 겪는 문제가 OOM 이슈인데요, 복잡한 쿼리 연산이 몰리면 이런 이슈가 있는데 recording rule 사용 시 미리 계산한 메트릭을 사용하기 때문에 부하 측면에서 도움이 됩니다.

3. 기준을 세우고 분리가 필요합니다.
   서버 에러 rate, latency 늘어지는 이슈 등은 burn rate을 적용하되 디스크, 노드 등의 리소스는 burn rate 보다는 현재 동작하는지 여부가 중요하기 때문에 가용성을 위주로 모니터링 하는게 유리합니다.

4. 처음 구축할 때 fault injection을 통해 검증을 하는건 필요합니다. 다만 그렇게 검증된 파이프라인에 대해 동작이 안하는건 아닐지 걱정할 필요는 없을거라고 생각합니다.

[SuperSon7]

답변 감사드립니다. 답변해주신 내용 바탕으로 현재 시스템에 적용해보겠습니다!