CloudWatch 알람, 데이터가 없을 때 무엇으로 볼 것인가

화재경보기가 울리지 않는 밤에는 두 가지 가능성이 있어요. 불이 나지 않았거나, 배터리가 빠져 있거나. 두 상태는 겉으로 완전히 같고, 구분하려면 경보기 자체를 따로 확인하는 수밖에 없어요.

CloudWatch는 AWS의 지표와 로그를 모으고 경보를 만드는 서비스예요. 알람을 만들 때는 임계값뿐 아니라 값이 오지 않을 때의 해석도 정해요. 오류가 없다는 0과 아무것도 측정하지 못한 빈칸은 다르거든요. 이 둘을 구별하는 방법을 알아두면 조용한 그래프를 더 정확하게 읽을 수 있어요.

상태가 셋이라는 사실

알람은 정상과 경보 두 상태만 오간다고 생각하기 쉽지만 실제로는 하나가 더 있어요. 판단할 데이터가 충분하지 않은 상태예요. AWS 문서는 이 상태를 별도로 두고, 데이터가 없을 때 알람이 그것을 어떻게 다룰지 고를 수 있게 해요. 없는 값을 위반으로 볼지, 정상으로 볼지, 무시하고 이전 상태를 유지할지, 아니면 데이터 부족으로 남겨 둘지를 정하는 설정이에요.

기본 설정은 missing, 곧 누락으로 다루는 방식이에요. 이를 정상으로 처리하도록 바꾸면 수집기가 멈췄을 때도 조용할 수 있어요. 반대로 누락을 경보로 처리하면 원래 드물게 발생하는 오류 지표에도 경보가 생길 수 있죠. 필요한 데이터가 충분히 있는 평가 구간에는 누락 설정이 쓰이지 않을 수도 있어요. 값이 하나 빠질 때마다 즉시 같은 동작을 하는 스위치는 아니에요.

반대로 없는 값을 전부 위반으로 보면 배포 중이나 트래픽이 없는 새벽마다 알람이 울려요. 그렇게 며칠 지나면 사람은 그 알람을 무시하기 시작하고, 그때부터는 켜 두지 않은 것과 다르지 않아요. 어느 쪽으로 정하든 대가가 있어서, 이 설정은 지표마다 따로 판단해야 해요.

값이 없는 것과 0인 것

관련해서 실무에서 자주 어긋나는 구분이 하나 더 있어요. 오류가 0건인 것과 오류 지표가 아예 오지 않는 것은 달라요. 앞은 세어 봤더니 없었다는 뜻이고, 뒤는 세지 못했다는 뜻이에요. 그래프에서는 둘 다 바닥에 붙어 있어 비슷해 보여요.

오류가 생겼을 때만 값을 보내는 지표는 특히 구별이 필요해요. 조용한 것이 정상일 수도 있으니까요. 요청 수를 함께 보면 도움이 되지만 한가한 서비스는 정상이어도 요청이 없을 수 있어요. 수집이 살아 있는지 보려면 일정 간격으로 보내는 생존 신호, 곧 하트비트처럼 트래픽과 별개로 기대할 수 있는 값이 더 직접적이에요.

직전 상태가 ALARM인 같은 출발점에서, 측정값과 빈칸 처리 방식을 비교해 보세요.

평가 범위의 측정값

모두 0

알람 기준: 값이 0보다 큼

빈칸 처리

빈칸으로 남김

OK

평가 범위가 전부 비면 정책에 따라 판단 불가·경보·정상·이전 상태 유지로 갈려요. 실제 값 0은 빈칸이 아니에요.

0은 실제로 측정한 값이에요. 이 예시에서는 정상이며 빈칸 처리 정책은 쓰지 않아요.

0은 실제로 측정한 값이에요. 이 예시에서는 정상이며 빈칸 처리 정책은 쓰지 않아요.

0은 실제로 측정한 값이에요. 이 예시에서는 정상이며 빈칸 처리 정책은 쓰지 않아요.

0은 실제로 측정한 값이에요. 이 예시에서는 정상이며 빈칸 처리 정책은 쓰지 않아요.

판단할 측정값이 없어요.

측정하지 못한 구간을 위험으로 처리해요.

측정하지 못한 구간을 정상으로 처리해요.

수집이 끊기기 전의 ALARM을 그대로 유지해요.

각 경우를 직전 ALARM에서 따로 비교해요. 관련 평가 범위가 전부 비거나 모두 0인 가정이며, 일부만 빈 경우에는 추가 측정값과 평가 조건도 영향을 줘요.

보관 기간이 곧 질문의 유효 기간

로그를 모으는 쪽에도 정해 둘 것이 있어요. 로그 묶음마다 보관 기간을 바꿀 수 있는데, 정하지 않으면 계속 쌓여요. 앞 시리즈의 비용 편에서 다룬 대로 이것은 저장 요금이 조용히 늘어나는 대표적인 자리이면서, 동시에 나중에 던질 수 있는 질문의 범위를 정하는 자리이기도 해요.

여기서 앞 글들과 이어지는 대목이 있어요. 배포가 실패했는지 판단하는 방법 가운데 하나가 지표 알람이었어요. 배포를 자동으로 되돌릴 근거로 알람을 쓰겠다면, 그 알람이 데이터 부족 상태에서 어떻게 행동하는지가 곧 되돌리기의 신뢰도가 돼요. 새 태스크가 아예 뜨지 못해 지표를 보내지 못하는 상황이 정확히 그 경우예요.

설정	이렇게 두면	놓치는 것
없는 값을 정상으로	조용하고 오탐이 없다	수집이 끊긴 순간을 놓친다
없는 값을 위반으로	끊김을 바로 잡아낸다	한가한 시간마다 울려 무시하게 된다
이전 상태를 유지	흔들림에 강하다	끊기기 직전 상태에 갇힌다

세 줄 모두 안전한 선택이 아니에요. 그래서 지표의 성격을 먼저 정해야 해요. 살아 있으면 반드시 값이 생기는 지표는 두 번째로, 이따금만 발생하는 지표는 첫 번째나 세 번째로 두는 식이에요.

저는 무엇을 알람으로 만들었나

제가 만드는 앱에서 가장 먼저 알람으로 만든 것은 오류율이 아니라 대체 경로로 넘어간 횟수였어요. 앞 시리즈에서 이야기한 대로 폴백이 조용히 잘 동작하면 1차 경로가 죽어도 사용자는 아무것도 느끼지 못해요. 그 상태를 잡으려면 실패를 세는 것이 아니라 우회를 세야 했어요.

여기에 한 겹을 더 뒀어요. 제가 일부러 1차 경로를 꺼 두는 경우가 있는데, 그때도 우회는 늘어나요. 정상적인 전환과 경보가 필요한 전환이 같은 숫자로 합쳐지면 그 알람은 며칠 만에 아무도 보지 않게 돼요. 그래서 지금 1차 경로를 쓰기로 되어 있는 상태인지 자체를 별도의 값으로 남기고, 그 값이 켜져 있을 때만 알람이 울리게 했어요. 작업하는 동안 알람이 조용한 것은 정상이고, 그 사실이 설정으로 표현돼 있는 편이 나아요.