CloudWatch 콘솔을 열면 끝없이 펼쳐지는 그래프 더미에 압도된다. EC2 CPU, ELB Request Count, Lambda Duration, RDS Connections, ECS CPU Reservation… 운영자는 이 더미 속에서 "지금 우리 서비스가 죽고 있는가"를 5초 안에 판단해야 한다. 그러려면 메트릭이 어떻게 저장되고 어떻게 인덱싱되며 어떻게 비용이 청구되는지를 알아야 한다. 콘솔 UI만 외우면 5분쯤 지나 다시 그래프를 못 찾고, 청구서를 받아 들고서야 cardinality 폭증을 만난다.
오늘은 CloudWatch Metrics의 데이터 모델, 시간 해상도, 보존 정책, cardinality 함정, 그리고 비용 구조를 운영자 관점에서 깊이 본다. 시험에서는 "이 시나리오에서 detailed monitoring을 켤까 1초 해상도까지 갈까", "사용자별 latency를 dimension으로 추적할까" 같은 의사결정 시나리오로 자주 등장한다.
한 메트릭 데이터 포인트는 다음 6개 요소의 튜플로 식별된다.
DataPoint = (Namespace, MetricName, Dimensions[], Timestamp, Value, Unit)