CloudWatch 누락 데이터 알람: TreatMissingData 선택법

CloudWatch 알람을 정리하다가 실행 중인 작업 수를 보는 알람이 실제 실패가 없는데도 상태를 바꾸는 것을 발견했다.
그래프에는 임계치를 넘은 값 대신 지표가 잠시 들어오지 않은 구간이 있었다.

지표는 일정한 간격으로 수집하는 숫자이고, 임계치는 이 숫자를 정상과 이상으로 나누는 경계다.
값이 0으로 들어온 것과 값 자체가 오지 않은 것은 다른 사건이다.

예를 들어 “최근 1분의 결제 실패 건수”가 0이면 실패가 없었다는 관측값이다.
반면 같은 지표가 비어 있으면 결제가 없었던 것인지, 집계 작업이 멈춘 것인지 아직 알 수 없다.

또 “오류가 생길 때만 1을 보내는 지표”라면 데이터가 없는 구간이 정상일 수 있다.
같은 빈칸도 지표가 어떻게 발행되도록 설계됐는지에 따라 뜻이 달라진다.

알람 수보다 먼저 상태 이력을 봤다

로드 밸런서, 컨테이너, 데이터베이스, 캐시와 관련된 핵심 알람 9종을 정리했다.
이름과 알림 경로를 맞추면서 오래되었거나 중복된 알람 2개를 제거했다.
삭제 전에는 알람 정의를 보관하고, 다른 복합 알람이 삭제 대상을 부모나 자식으로 참조하는지 확인해야 한다.
delete-alarms는 요청에 잘못된 이름이 섞여도 유효한 이름은 삭제할 수 있어서 명령 결과만 믿지 않고 다시 조회하는 과정도 필요하다.

알람 상태 이력과 원본 지표 그래프를 나란히 보니 같은 ALARM 상태에도 서로 다른 원인이 있었다.
실제 값이 임계치를 넘은 경우가 있었고, 빈 구간을 위반으로 취급한 경우도 있었다.

CloudWatch의 TreatMissingData는 평가할 숫자가 모자랄 때 빈칸을 어떻게 다룰지 정한다.

• missing: 실제 데이터만으로 판단할 수 없고 평가 범위가 모두 비었다면 INSUFFICIENT_DATA로 둔다.
• ignore: 빈칸 때문에 상태를 바꾸지 않고 현재 상태를 유지한다.
• breaching: 빈칸을 임계치 위반으로 채운다.
• notBreaching: 빈칸을 위반이 아닌 값으로 채운다.

CloudWatch는 평가에 필요한 실제 데이터가 충분하면 이 설정을 사용하지 않는다.
부족할 때만 필요한 수만큼 빈칸을 채운다.

Period는 지표를 한 점으로 묶는 시간 간격이고, EvaluationPeriods는 최근 몇 구간을 평가할지 정한다.
DatapointsToAlarm은 그중 몇 구간이 임계치를 넘어야 ALARM으로 바꿀지 정하는 값이다.
Missing Data 한 필드만 보기 전에 세 값이 실제 장애의 지속 시간과 맞는지 함께 봐야 한다.

결측 정책을 고르기 전에는 알람마다 작은 계약을 하나 적어 두는 편이 안전했다.
지표가 어느 서비스에서 나오고, 몇 분마다 발행돼야 하며, 값이 없을 때 정상인지 수집 실패인지부터 정하는 것이다.
계속 들어와야 하는 지표에 notBreaching을 쓰려면 수집기 상태나 데이터 미수신을 감지하는 별도 알람이 있어야 한다.
그렇지 않으면 지표 수집이 끊긴 상황까지 정상으로 가릴 수 있다.

AWS 서비스에 따라 예외도 있다.
지표를 서비스별로 묶는 이름 공간인 AWS/DynamoDB 네임스페이스에서는 데이터가 누락되면 현재 알람 상태를 유지한다.
가상 서버인 EC2 인스턴스를 중지·종료·재부팅·복구하는 작업과 연결된 알람은 일시적인 지표 누락이 인스턴스 작업으로 이어지지 않도록 AWS 권고대로 missing을 사용하고, ALARM 전이에만 작업이 실행되게 구성해야 한다.
같은 결측 설정을 모든 서비스에 복사할 수 없는 이유다.

변경 명령보다 전체 정의를 먼저 읽었다

put-metric-alarm은 한 필드만 수정하는 패치 명령이 아니다.
기존 알람을 업데이트하면 이전 구성을 완전히 덮어쓴다.
지표를 더 구체적으로 구분하는 dimensions와 알림을 보낼 actions, 임계치와 평가 구간 중 하나라도 빠뜨리면 다른 알람이 된다.

먼저 읽기 전용 명령으로 현재 정의 전체를 확인했다.

aws cloudwatch describe-alarms \
  --alarm-names "<alarm-name>" \
  --output json

조회 결과는 변경 전 파일로 남기고 새 정의와 비교해야 한다.
Period, EvaluationPeriods, DatapointsToAlarm, dimensions, 통계 방식, 임계치, 알림과 자동 작업을 뜻하는 actions가 모두 그대로인지 본 뒤 TreatMissingData 차이만 승인한다.
새 알람은 처음 INSUFFICIENT_DATA로 생성된 뒤 평가되므로 자동 복구나 스케일링 작업이 연결된 경우에는 복제 알람이나 통제된 점검 시간에 먼저 검증하는 편이 안전하다.

실제 변경은 현재 정의의 모든 필드를 보존한 상태에서 실행 작업 수 알람 하나의 TreatMissingData만 notBreaching으로 바꾸는 일이었다.
운영값을 제거한 개념 차이는 다음 한 줄이다.

- TreatMissingData: <기존 값>
+ TreatMissingData: notBreaching

그대로 실행할 수 있는 put-metric-alarm 예시는 남기지 않았다.
실제 알람의 dimensions와 actions를 모르는 상태에서 불완전한 명령을 복사하는 위험이 설명보다 컸기 때문이다.

모든 알람에 notBreaching을 넣지도 않았다.
오류가 있을 때만 발행되는 희소 지표에는 빈칸이 정상일 수 있다.
반대로 계속 들어와야 하는 상태 지표가 끊겼다면 공백 자체가 수집 장애다.

여섯 개는 OK였고 세 개는 기다렸다

변경 후 실행 작업 수 알람이 OK로 돌아온 것을 확인했다.
핵심 알람 9개 전체에서는 6개가 OK였고, 새 데이터베이스 알람 3개는 INSUFFICIENT_DATA였다.

새 알람 세 개를 초록색으로 만들기 위해 결측 정책을 바꾸지는 않았다.
아직 평가할 데이터가 부족한 상태를 정상으로 덮으면 지표 수집 문제를 놓칠 수 있다.
데이터가 들어온 뒤 의도한 상태 전이가 일어나는지 보는 대상으로 남겼다.

결측값은 지표가 약속한 방식으로 해석한다

이번 작업에서는 중복되거나 오래된 알람 2개를 제거했고, 실행 작업 수 알람 하나가 데이터 공백을 장애로 오해하던 문제를 고쳤다.
변경 직후 그 알람은 OK로 돌아왔고 핵심 알람 9개는 OK 6개, 아직 데이터가 부족한 INSUFFICIENT_DATA 3개로 구분됐다.
초록색 개수를 늘린 것이 아니라 실제 장애, 정상적인 무발행, 수집 공백을 서로 다른 상태로 남긴 것이 결과다.

결측 정책은 알람을 빨리 초록색으로 만드는 옵션이 아니라, 지표가 발행되지 않았을 때 그것을 어떤 사건으로 볼지 적는 계약이다.

정책을 바꾼 뒤에는 네 가지를 검증한다.

1. 정상 값을 넣었을 때 OK가 되는가
2. 임계치 초과 값을 넣었을 때 ALARM이 되고 실제 알림 채널이나 자동 작업까지 도착하는가
3. 발행을 멈췄을 때 지표가 약속한 결측 상태로 가는가
4. 판정 이유를 담은 StateReason과 상태가 바뀐 시각이 예상한 평가 구간과 맞는가

대부분의 알림 작업은 상태가 바뀔 때 실행되지만 서버 수를 자동 조절하는 Auto Scaling 작업은 알람 상태가 유지되는 동안에도 실행될 수 있다.
또 지표 발행이 멈춘 직후 CloudWatch가 마지막 평가 구간을 다시 계산하면서 상태와 작업이 다시 바뀌는 경우가 있다.
그래서 화면의 색만 한 번 확인하지 않고 알림 수신 기록과 자동 작업 이력까지 본다.
이 재평가가 문제가 된다면 탐지하려는 장애 지속 시간을 해치지 않는 범위에서 더 짧은 Period를 검토한다.

이번 실행 작업 수 지표는 정상적인 무발행을 장애로 해석하지 않도록 고쳤고, 새 데이터베이스 알람 세 개는 데이터가 들어오기 전까지 INSUFFICIENT_DATA로 남겼다.
두 상태를 억지로 같은 초록색으로 만들지 않은 것이 이 작업의 핵심이었다.

참고 자료

• CloudWatch 알람의 누락 데이터 처리
• AWS CLI describe-alarms
• AWS CLI put-metric-alarm
• AWS CLI delete-alarms
• CloudWatch 알람 작업