새벽 2시 43분, 온콜 엔지니어의 폰이 세 번 연속 울린다. PagerDuty 알림 15개. EC2 CPU High, RDS Connections High, ALB 5xx High, ElastiCache CPU High, SQS Queue Depth High... 전부 같은 사고에서 파생됐다. 실제 근본 원인은 하나였는데, 엔지니어는 15개 알림에 압도돼 어디부터 봐야 할지 모른다. 이 상황이 alert fatigue의 교과서적 형태다.
CloudWatch Alarm은 AWS 운영의 가장 기본적인 자동화 트리거다. 그러나 "임계값 넘으면 알림"이라는 단순한 이해로 설계하면 새벽 온콜 엔지니어를 지치게 만드는 시스템이 된다. 오늘은 알람의 상태 머신, M of N 평가 알고리즘, Treat Missing Data, Composite Alarm, 그리고 Anomaly Detection 알람이 어떻게 설계됐는지 내부까지 들어간다.
CloudWatch Alarm은 정확히 세 가지 상태만 가진다. OK: 메트릭이 임계값 안에 있다. ALARM: 임계값을 위반했다. INSUFFICIENT_DATA: 데이터가 부족해 판단을 내릴 수 없다. 이 세 상태 사이의 전이는 컴퓨터 과학의 유한 상태 머신(FSM, Finite State Machine) 개념의 직접 구현이다.