CloudWatch 알람 노이즈 줄이기 — SNS 토픽 필터링 실전

CloudWatch 알람을 SNS 토픽으로 이메일에 연결하면 장애를 빠르게 감지할 수 있다. 하지만 설정이 느슨하면 알람 폭풍이 발생해 정작 중요한 알림을 놓치게 된다.

Table of contents

문제: 알람 폭풍

이커머스 연동 서비스의 CloudWatch 알람이 한 달에 수십 건 발생했다:

ALARM: "Node _ _" in Asia Pacific (Seoul)
ALARM: "Node _ _" in Asia Pacific (Seoul)
ALARM: "Node _ _" in Asia Pacific (Seoul)
INSUFFICIENT_DATA: "Node _ _ _" in Asia Pacific (Seoul)
ALARM: "Node _ _" in Asia Pacific (Seoul)

같은 알람이 30분~1시간 간격으로 반복 발생하면서 이메일이 쌓였다. 상태가 ALARM → OK → ALARM을 빠르게 왕복하는 플래핑(flapping) 현상이다.

원인 분석

1. 알람 임계값이 너무 민감

기존 설정:
- 지표: CPUUtilization
- 임계값: > 70% for 1 datapoint within 1 minute
- 조치: SNS로 이메일 발송

1분 데이터포인트 1개만으로 알람이 발생하므로, 순간적인 스파이크에도 알림이 간다.

2. INSUFFICIENT_DATA 알림

인스턴스가 중지되거나 지표 수집이 일시 중단되면 INSUFFICIENT_DATA 상태로 전환된다. 이 상태 전환에도 SNS가 발동하면 불필요한 알림이 발생한다.

해결 방법

1. 평가 기간 늘리기

변경 후:
- 임계값: > 80% for 3 datapoints within 5 minutes
- 의미: 5분 중 3번 이상 80% 초과 시에만 알람

Datapoints to Alarm을 늘리면 순간 스파이크를 무시하고 지속적인 부하만 감지한다.

2. Missing Data 처리

알람 설정에서 Treat missing data as 옵션을 조정한다:

인스턴스 중지 시 INSUFFICIENT_DATA 알림을 피하려면 notBreaching으로 설정한다.

3. SNS 필터 정책

SNS 구독에 필터 정책을 적용해 특정 상태 전환만 전달한다:

{
  "NewStateValue": ["ALARM"],
  "OldStateValue": ["OK"]
}

이렇게 하면 OK → ALARM 전환만 이메일로 받고, ALARM → OK (복구), INSUFFICIENT_DATA 전환은 무시한다.

4. 복합 알람 (Composite Alarm)

여러 알람을 하나의 복합 알람으로 묶어 AND/OR 조건을 적용할 수 있다:

복합 알람: "서비스 전체 장애"
조건: CPU_ALARM AND Memory_ALARM
→ CPU와 메모리가 동시에 위반일 때만 알림

단일 지표 알람보다 정확도가 높아진다.

알람 설계 원칙

1. 수신자가 즉시 조치할 수 있는 알람만 — 정보성 알람은 대시보드로 대체
2. 평가 기간 충분히 — 최소 3 datapoints, 5분 이상
3. 알람 이름에 서비스명 포함 — “Node _ _” 같은 기본 이름 대신 의미 있는 이름
4. 심각도 분리 — Critical은 SMS/전화, Warning은 이메일, Info는 Slack
5. 주기적 리뷰 — 월 1회 알람 발생 빈도를 확인하고 임계값 조정

정리

CloudWatch 알람은 적절한 임계값, 충분한 평가 기간, SNS 필터 정책 조합으로 노이즈를 대폭 줄일 수 있다. “알람이 너무 많아서 무시하게 되는” 상황이야말로 모니터링의 가장 큰 실패다.