기준: DVA-C02 시험 가이드오류 제보
기본 지표와 알람은 "이미 일어난 문제"를 알려준다. CPU가 90%를 찍었을 때 알람이 울리지만, 그때는 사용자가 이미 느려진 서비스를 경험한 뒤다. 모니터링의 다음 단계는 두 방향으로 진화한다. 하나는 더 깊게, 곧 가상 머신 단위가 아니라 컨테이너 하나하나와 애플리케이션 SLO 수준까지 내려가는 것이다. 다른 하나는 더 앞서, 곧 문제가 사용자에게 닿기 전에 합성 트래픽으로 먼저 감지하고, 정적 임계값 대신 ML이 학습한 정상 범위로 미묘한 이상을 잡아내는 것이다. CloudWatch의 고급 기능인 Container Insights, Synthetics, Anomaly Detection, Dashboards는 이 "더 깊게, 더 앞서"라는 두 축 위에 있다.
DVA-C02에서 이 영역은 "기본 CloudWatch로는 부족한 상황"의 답으로 나온다. ECS/EKS 컨테이너 모니터링, 엔드포인트 가용성의 능동적 확인, ML 기반 자동 임계값, 다중 계정 통합 뷰가 출제 포인트다. 이번 글은 컨테이너 모니터링이 왜 EC2 모니터링과 다른지, 합성 모니터링이 어떤 모니터링 철학의 전환인지, Anomaly Detection이 통계적으로 무엇을 하는지를 다룬다.
EC2 한 대를 모니터링하는 것은 비교적 단순하다. 인스턴스 하나에 지표가 붙는다. 그런데 ECS/EKS에서는 한 EC2 인스턴스(또는 Fargate 캐파시티) 위에 여러 컨테이너가 돌고, 그 컨테이너들은 태스크(task)로, 태스크는 서비스(service)로 묶이며, 서비스는 클러스터(cluster)에 속한다. "CPU가 높다"는 사실만으로는 부족하다. 어느 컨테이너의 CPU인지, 같은 호스트의 다른 컨테이너는 멀쩡한지를 알아야 한다. 이 계층 구조를 무시하고 호스트 수준 지표만 보면 "전체는 30%인데 특정 컨테이너가 100%를 치고 죽는" 상황을 놓친다.
Container Insights는 이 컨테이너 계층 구조에 맞춰 지표를 수집·집계한다. 클러스터 → 서비스 → 태스크 → 컨테이너 각 레벨에서 CPU·메모리·네트워크·디스크를 보고, 태스크가 몇 개 떠 있는지(desired vs running) 같은 오케스트레이션 지표까지 포함한다.
aws ecs update-cluster-settings \
--cluster my-cluster \
--settings name=containerInsights,value=enabled컨테이너 모니터링이 어려운 근본 이유는 컨테이너가 수명이 짧고(ephemeral) 동적이기 때문이다.
Container Insights와 Managed Prometheus(AMP)의 선택은 Day 1에서 본 푸시 대 풀의 연장이다.
/metrics 엔드포인트를 스크랩(풀) 하고 Grafana(AMG)로 시각화하는, CNCF 생태계 표준을 그대로 따르는 방식이다.전통적 모니터링은 수동적(passive) 이다. 실제 트래픽이 들어와야 지표가 생기고, 그 지표로 문제를 안다. 그런데 새벽 3시에 트래픽이 없으면 엔드포인트가 죽어 있어도 아무도 모른다. 첫 사용자가 아침에 접속해 에러를 만나야 비로소 알람이 울린다. CloudWatch Synthetics는 이 수동성을 뒤집어, 실제 사용자가 없어도 가짜 사용자(canary)가 주기적으로 엔드포인트를 두드려 가용성을 능동적(active) 으로 확인한다.
const synthetics = require('Synthetics');
const apiCanaryBlueprint = async function () {
const response = await synthetics.executeHttpStep('Health Check', {
hostname: 'api.myapp.com', method: 'GET',
path: '/health', port: 443, protocol: 'https:'
});
if (response.statusCode !== 200) {
throw new Error(`상태 확인 실패: ${response.statusCode}`);
}
};
exports.handler = async () => await apiCanaryBlueprint();"카나리(canary)"라는 이름은 탄광의 카나리아에서 왔다. 광부들은 유독가스에 민감한 카나리아를 갱도에 데려가, 새가 쓰러지면 자기들이 당하기 전에 대피했다. 사람보다 먼저 위험을 감지하는 조기 경보다. 합성 모니터링의 카나리도 같아서, 실제 사용자가 장애를 겪기 전에 합성 카나리가 먼저 그 장애를 만나 알람을 울린다.
이 "능동적 합성 트랜잭션"은 black-box monitoring(시스템 내부가 아니라 외부에서 본 동작을 검증)으로 분류되며, 내부 지표만 보는 white-box monitoring과 상보적이다. 내부 지표는 "왜 고장났나"에, 합성 모니터링은 "사용자 관점에서 고장났나"에 강하다.
⚠️ 함정: Synthetics와 Route 53 Health Check를 혼동하기 쉽다. Route 53 Health Check는 단순 핑/HTTP 상태 코드 확인(엔드포인트가 살아 있나)에 가깝고 주로 DNS 페일오버 트리거에 쓰인다. Synthetics는 Lambda 기반으로 스크립트를 실행해 다단계 사용자 흐름(로그인 → 검색 → 구매)까지 검증하고 스크린샷·끊어진 링크까지 잡는다. "단순 가용성 ping"이면 R53, "사용자 트랜잭션·다단계 흐름 검증"이면 Synthetics다. Synthetics 카나리 자체가 Lambda(Node.js/Python) 위에서 돈다는 점도 출제될 수 있다.
Synthetics의 Blueprint는 실무 시나리오를 그대로 반영한다.
특히 Visual monitoring은 "API는 200을 반환하는데 CSS가 깨져 화면이 망가진" 상황, 곧 지표상으로는 정상인데 사용자 눈에는 고장인 경우를 잡는다. "기술적으로 작동 ≠ 사용자에게 정상"이라는 합성 모니터링의 존재 이유를 보여 준다.
"CPU 80% 초과 시 알람"이라는 정적 임계값은 단순하지만 약점이 두 가지 있다. 첫째, 트래픽이 시간대·요일에 따라 변하면 단일 임계값이 맞지 않는다. 낮에는 70%가 정상이지만 새벽에는 30%만 돼도 비정상일 수 있다. 둘째, "80%는 안 넘었지만 평소보다 비정상적으로 높은" 미묘한 이상을 못 잡는다. CloudWatch Anomaly Detection은 ML로 지표의 정상 패턴을 학습해, 고정된 선이 아니라 "예상 범위 밴드"를 만들고 그것을 벗어날 때 알람을 울린다.
aws cloudwatch put-anomaly-detector \
--namespace AWS/Lambda --metric-name Duration \
--dimensions Name=FunctionName,Value=my-function --stat AverageAnomaly Detection이 학습하는 것은 지표의 계절성(seasonality) 과 추세(trend) 다. 시계열 분석에서 데이터는 보통 세 성분으로 분해된다.
Anomaly Detection은 과거 데이터에서 일별·주별 반복 패턴을 학습해 "지금 이 시각·이 요일이라면 값이 대략 이 범위일 것"이라는 예측 밴드를 만든다. 그래서 새벽의 낮은 트래픽과 점심의 높은 트래픽을 각각 정상으로 인식하고, 같은 50%라도 새벽에는 이상으로 낮에는 정상으로 다르게 판단한다. Holt-Winters 지수 평활이나 SARIMA 같은 고전 시계열 예측 기법과 같은 계열의 아이디어다. 패턴이 일정한 지표(주기적 트래픽)에는 효과적이지만, 무작위로 튀는 지표에는 밴드가 넓어져 쓸모가 줄어든다.
원시 지표만으로는 답이 안 나오는 질문이 있다. "성공률은 몇 %인가?"는 단일 지표가 아니라 성공 수 / 전체 수 × 100이라는 계산이 필요하다. Metric Math는 여러 지표를 수식으로 조합해 새 지표를 만든다.
m1 = SuccessCount
m2 = TotalRequests
expression: m1 / m2 * 100 # 성공률(%)
Metric Math가 알람에서 중요한 이유는 "비율 기반 알람"이 절대값 알람보다 견고하기 때문이다. "에러 100건 초과"라는 절대 임계값은 트래픽이 10배 늘면 정상 상태에서도 쉽게 넘지만, "에러율 1% 초과"는 트래픽 규모와 무관하게 의미가 일정하다. 그래서 SRE 실무에서는 SLO를 절대 카운트가 아니라 비율(가용성 99.9%, 에러율 0.1% 미만)로 정의하고, 이를 Metric Math로 계산해 알람에 건다. "정규화된 지표가 절대 지표보다 안정적"이라는 것은 모니터링 설계의 일반 원칙이다.
반대로 CloudWatch에 모인 지표를 외부로 흘려보내야 할 때도 있다. Metric Stream은 지표를 거의 실시간으로 Kinesis Data Firehose를 거쳐 S3·Datadog·Splunk 등 외부 도구로 스트리밍한다.
📚 사례: Metric Stream은 "AWS 안에서 다 보지 말고 조직 표준 모니터링 도구(Datadog 등)로 통합하라"는 요구에서 나왔다. 예전에는 CloudWatch 지표를 외부로 가져가려면
GetMetricDataAPI를 주기적으로 폴링해야 했고, 지연·비용·API 한도 문제가 있었다. Metric Stream은 푸시 방식으로 지표가 생기는 대로 Firehose로 흘려보내 외부 도구에 거의 실시간으로 도달하게 한다. 시험에서 "CloudWatch 지표를 외부 모니터링 도구로 거의 실시간 통합"이 보이면 Metric Stream이 정답이다. 로그를 외부로 보내는 Subscription Filter(Day 1)와는 대상이 구분된다. 전자는 지표, 후자는 로그다.
마지막 축은 통합이다. CloudWatch Dashboards는 여러 서비스·여러 지표·알람 상태를 위젯으로 한 화면에 모은다. 교차 계정·교차 리전 대시보드는 여러 AWS 계정과 리전의 지표를 단일 뷰로 합친다. 조직이 계정을 환경별(prod/staging)·팀별로 쪼개 운영할 때 필수다.
모니터링 신호를 한 화면에 통합하는 흐름의 정점이 CloudWatch ServiceLens(X-Ray 추적 + 지표 + 로그를 서비스 맵 위에 결합)와 Application Signals(2024, 애플리케이션 SLO와 황금 신호 모니터링)다. "황금 신호(Golden Signals)"는 Google SRE 책이 정의한 네 가지 지표, 곧 지연(latency), 트래픽(traffic), 에러(errors), 포화도(saturation)를 말한다. 이 넷만 잘 보면 대부분의 서비스 건강을 파악할 수 있다는 것이 SRE의 경험칙이다. Application Signals는 OpenTelemetry 기반으로 이 황금 신호를 자동 수집해 "지표·추적·로그가 따로 노는" 파편화를 SLO 중심으로 통합한다. 모니터링의 진화 방향이 "개별 지표 나열"에서 "서비스 수준 목표(SLO) 중심"으로 옮겨 가는 흐름을 보여 준다.
CloudWatch 고급 기능은 "더 깊게, 더 앞서"라는 두 축으로 정리된다. Container Insights는 동적이고 수명이 짧은 컨테이너 계층에 맞춰 깊이를 더하고, Synthetics는 사용자를 기다리지 않고 합성 카나리로 먼저 장애를 감지해 앞서간다. Anomaly Detection은 정적 임계값의 한계(시간대 변동, 미묘한 이상)를 ML이 학습한 계절성 밴드로 넘어서고, Metric Math는 절대값보다 견고한 비율 기반 알람을 가능하게 한다. Metric Stream은 지표를 외부로, Dashboards와 ServiceLens·Application Signals는 흩어진 신호를 SLO 중심으로 통합한다. 이 모두가 "사용자가 문제를 겪기 전에, 더 정확하게 안다"는 한 목표를 향한다.
다음 글에서는 Week 10 전체인 CloudWatch, X-Ray, CloudTrail, EventBridge를 시나리오 문제로 종합 점검한다.
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
ECS 클러스터에서 "전체 호스트 CPU는 30%인데 특정 컨테이너가 100%를 치고 재시작을 반복"하는 상황을 감지하려 한다. 적절한 것은?
문제 2
새벽에 트래픽이 없을 때 결제 API 엔드포인트가 죽어도 아무도 모른다. 실제 사용자가 없어도 가용성을 능동적으로 확인하려면?
문제 3
트래픽이 시간대·요일별로 크게 변동하는 지표에 대해, 단일 정적 임계값 없이 "그 시각의 정상 범위"를 벗어날 때만 알람을 울리려 한다. 적절한 것은?
문제 4
"성공률 99% 미만이면 알람"을 구현하려 한다. SuccessCount와 TotalRequests 두 지표가 있다. 적절한 방법은?
문제 5
조직이 prod·staging·dev를 별도 AWS 계정으로 운영한다. 세 계정의 핵심 지표를 단일 화면에서 보려면?
문제 6
CloudWatch 지표를 회사 표준 모니터링 도구(Datadog)로 거의 실시간 통합하려 한다. 가장 적절한 것은?
문제 7
기존 쿠버네티스(EKS) 환경에 이미 Prometheus/Grafana 운영 경험과 자산이 있는 팀이 컨테이너 모니터링 표준을 정하려 한다. Container Insights 대신 고려할 옵션과 그 이유는?