Alert와 SLO
한 줄 정의
Alert는 운영자가 조치해야 할 사용자 영향이나 위험을 알려주는 신호이고, SLO는 서비스가 지켜야 할 신뢰성 목표다.
실무에서 왜 문제 되는가
- 단순 CPU 임계치 알림은 사용자 영향과 연결되지 않을 수 있다.
- 너무 많은 알림은 운영자가 중요한 장애를 놓치게 만든다.
- 알림이 늦으면 장애를 고객 문의로 알게 된다.
- SLO가 없으면 어떤 지표 악화가 장애인지 합의하기 어렵다.
- 경고만 울리고 대응 절차가 없으면 복구 시간이 줄지 않는다.
동작 원리
- 사용자 관점의 SLI를 정한다.
- 목표 수준인 SLO를 정한다.
- SLO 위반 가능성이 큰 상황에 알림 조건을 연결한다.
- 알림에는 영향 범위, 최근 변경, 대시보드, 대응 문서를 포함한다.
- 장애 후 알림 정확도와 노이즈를 조정한다.
실무 판단 기준
| 상황 | 알림 기준 | 이유 |
|---|---|---|
| API 장애 | 5xx rate, timeout rate | 사용자 실패와 직접 연결된다 |
| 지연 장애 | p95/p99 latency | 체감 지연을 반영한다 |
| 자원 고갈 | pool pending, queue depth | 장애 전조를 잡는다 |
| 배치 실패 | 처리 실패율, 지연 시간 | 사용자 API와 기준이 다르다 |
| 외부 API 장애 | dependency error/timeout | 의존성 문제를 분리한다 |
자주 나는 실수
- 모든 WARN 로그를 알림으로 연결한다.
- CPU 80% 같은 단일 임계치만 사용한다.
- 알림에 어떤 서비스를 어떻게 확인할지 정보가 없다.
- 업무 시간과 야간 알림의 긴급도를 구분하지 않는다.
- 알림이 울린 뒤 실제 조치가 있었는지 회고하지 않는다.
확인 방법
- 테스트: 장애 시나리오에서 알림이 적절한 시간 안에 울리는지 확인한다.
- 로그: 알림 시간대의 error log와 배포 이력을 확인한다.
- 메트릭: SLI, error budget, burn rate를 확인한다.
- 대시보드: 알림에서 바로 원인 후보를 볼 수 있는지 확인한다.
장점과 한계
| 장점 | 한계 |
|---|---|
| 장애 인지 시간을 줄인다 | 잘못 설계하면 알림 피로를 만든다 |
| 사용자 영향 기준으로 운영한다 | SLO 합의가 필요하다 |
| 장애 우선순위를 정하기 쉽다 | 모든 장애를 사전에 감지하지는 못한다 |
짧은 예제
알림 조건:
- checkout API 5xx rate > 2% for 5m
- checkout API p95 latency > 1s for 10m
- db_pool_pending > 0 for 3m알림은 “누군가 봐야 하는 정보”가 아니라 “누군가 행동해야 하는 신호”여야 한다.
핵심 요약
알림은 운영자가 조치해야 할 사용자 영향에 연결되어야 한다.
SLO는 서비스가 어느 수준의 신뢰성을 제공할지 정하는 기준이다.
CPU나 메모리 같은 자원 지표만으로는 사용자 영향을 판단하기 어렵다.
좋은 알림은 영향 범위, 원인 후보, 확인 링크, 대응 절차를 함께 제공한다.
장애 후에는 알림이 너무 늦거나 시끄럽지 않았는지 반드시 조정한다.
꼬리 질문
- SLI, SLO, SLA의 차이는 무엇인가?
- 좋은 알림과 나쁜 알림의 차이는 무엇인가?
- error budget burn rate는 왜 사용하는가?