Day 1 - CloudWatch: 지표 하나가 어떻게 알람과 자동화로 이어지는가

운영 중인 시스템에 문제가 생겼을 때 가장 먼저 던지는 질문은 늘 같다. "지금 뭐가 잘못됐는가, 그리고 그걸 우리는 어떻게 알았어야 하는가." 모니터링이라는 분야 전체가 이 두 문장을 자동화하려는 시도다. AWS CloudWatch는 그 자동화를 "모든 것은 결국 시계열 숫자(metric)다"라는 단 하나의 추상화 위에 올려놓은 서비스다. CPU 사용률도, Lambda 호출 횟수도, 로그에서 추출한 에러 개수도, 사용자 정의 비즈니스 지표도 CloudWatch 안에서는 전부 (timestamp, value, dimensions)라는 동일한 형태의 데이터 포인트가 된다. 이 단일 추상화를 이해하면 지표·로그·알람·대시보드가 따로 노는 기능이 아니라 하나의 파이프라인으로 보인다.

DVA-C02에서 CloudWatch는 모니터링 섹션의 중심축이다. 단독 문제보다 "EC2 메모리는 왜 기본 지표가 아닌가", "로그에서 알람을 만들려면 무엇을 거쳐야 하는가", "Lambda에서 비용 안 들이고 지표를 만드는 법" 같은 통합 시나리오로 묻기 쉽다. 이번 글은 CloudWatch가 어디서 출발한 서비스인지, 푸시(push) 기반 모델이 무엇을 가능하게 했는지, 메트릭 한 개가 어떻게 알람과 Auto Scaling 같은 자동 대응으로 이어지는지를 다룬다.

CloudWatch가 출발한 자리: 폴링에서 푸시로

CloudWatch는 2009년 EC2 모니터링 도구로 처음 등장했다. 당시 인프라 모니터링의 표준은 Nagios(1999)와 그 뒤를 이은 Zabbix·Munin 같은 폴링(poll) 기반 도구였다. 폴링 모델에서는 중앙 모니터링 서버가 주기적으로 각 호스트에 "지금 CPU 몇 %냐"고 물어보러 다닌다. 호스트가 수천 대로 늘면 중앙 서버가 그 수천 대를 다 순회해야 하고, 새 인스턴스가 뜨면 모니터링 서버 설정에 일일이 등록해야 한다. Auto Scaling으로 인스턴스가 분 단위로 생겼다 사라지는 클라우드 환경에서 이 모델은 근본적으로 맞지 않았다.

CloudWatch는 반대로 푸시(push) 기반을 택했다. 각 리소스(또는 에이전트)가 자기 지표를 CloudWatch로 밀어 올린다. 중앙 서버가 호스트를 찾아다니지 않으므로 인스턴스가 몇 대로 늘든 수평 확장이 자연스럽고, 새 인스턴스가 떠도 자기 지표를 알아서 보내면 그만이다. PutMetricData라는 단일 진입점으로 모든 지표가 들어오는 설계가 여기서 나온다.

폴링 대 푸시는 모니터링 설계의 오래된 분기점이다. Prometheus(2012, CNCF)는 클라우드 시대에 다시 폴링(scrape)으로 돌아갔다. 서비스 디스커버리(쿠버네티스 API 등)와 결합해 "무엇을 긁을지"를 동적으로 알아내는 방식으로 폴링의 확장성 문제를 풀었다. 이 대비는 시험에 직접 나오지 않지만 Container Insights 대 Managed Prometheus 선택(Day 4)의 배경이다. 푸시는 "보내는 쪽이 책임", 풀은 "수집하는 쪽이 책임"이라는 권한·신뢰 경계의 차이로도 읽힌다.

푸시 모델의 대가는 "지표를 안 보내면 CloudWatch는 그 존재조차 모른다"는 것이다.

• 폴링 모델에서는 호스트가 응답하지 않으면 그 자체가 "다운" 신호다.
• 푸시 모델에서는 침묵이 "정상인데 조용한 것"인지 "죽어서 못 보내는 것"인지 구분되지 않는다.
• 알람의 INSUFFICIENT_DATA 상태와 데이터 누락 처리 옵션(missing/notBreaching/breaching/ignore)은 이 모호함을 운영자가 명시적으로 해석하도록 강제하려고 존재한다.
• "데이터가 없을 때 이걸 정상으로 볼지 장애로 볼지"는 푸시 기반 시스템이 사람에게 맡길 수밖에 없는 결정이다.

왜 EC2 메모리는 기본 지표가 아닌가: 하이퍼바이저 경계

"EC2 메모리·디스크 사용량은 기본 지표가 아니다"라는 사실은 CloudWatch 문제에서 함정으로 쓰이기 쉽다. 단순 암기보다 왜 그런지를 알아 두면 헷갈리지 않는다.

CloudWatch가 자동 수집하는 EC2 기본 지표(CPUUtilization, NetworkIn/Out, DiskReadOps, StatusCheckFailed 등)는 전부 하이퍼바이저(Xen/Nitro) 바깥에서 관측 가능한 것들이다. 하이퍼바이저는 게스트 VM에 CPU 시간을 얼마나 줬는지, 네트워크 패킷이 가상 NIC를 얼마나 통과했는지, EBS 볼륨에 블록 I/O가 몇 번 일어났는지를 안다. 이는 가상화 계층이 직접 중개하는 값이라 OS 안을 들여다보지 않아도 된다.

반면 메모리 사용률과 디스크 사용 공간은 게스트 OS 안에서만 의미가 있다. 하이퍼바이저는 VM에 4GB RAM을 할당했다는 것은 알지만, OS가 캐시로 얼마나 쓰는지, 애플리케이션이 얼마나 점유하는지는 OS 안에서 /proc/meminfo를 읽어야 안다. AWS가 게스트 OS 내부를 임의로 들여다보는 것은 보안·격리 원칙 위반이다.

그래서 메모리·디스크 사용량은 CloudWatch Agent를 OS 안에 설치해 내부에서 측정한 값을 푸시하게 만든 것이다. "OS 수준 지표 → Agent 필요"라는 규칙은 이 하이퍼바이저 경계의 직접적 귀결이다.

⚠️ 함정: 시험에서 DiskReadOps/DiskWriteOps(블록 I/O 횟수)는 기본 지표이고, disk_used_percent(디스크 사용 공간)는 Agent 필요다. 둘 다 "디스크"라는 단어가 들어가 헷갈리게 출제될 수 있다. 구분 기준은 같다. I/O 횟수는 하이퍼바이저가 EBS 경계에서 세지만, "공간이 얼마나 찼나"는 파일시스템(OS) 안을 봐야 안다. "메모리"도 마찬가지로 항상 Agent 쪽이다.

CloudWatch Agent 이전에는 AWS가 Perl로 짠 "CloudWatch Monitoring Scripts"(mon-put-instance-data.pl)를 제공했고, 많은 운영팀이 이를 cron에 걸어 메모리 지표를 푸시했다. 2017년 통합 CloudWatch Agent가 나오면서 이 Perl 스크립트는 사실상 폐기됐지만, 구버전 블로그·튜토리얼·일부 문제 은행에는 아직 남아 있다. 시험에서 "EC2 메모리 모니터링"의 정답은 CloudWatch Agent이지 Perl 스크립트가 아니다.

해상도와 보존: 시계열 데이터베이스의 트레이드오프

CloudWatch 지표에는 두 가지 해상도가 있다. 기본은 1분, 고해상도(high-resolution)는 1초다. EC2 모니터링에는 별도로 Basic(5분)과 Detailed(1분)라는 축이 또 있다. 이 숫자들이 헷갈리는 이유는 서로 다른 것을 가리키기 때문이다. 해상도는 "사용자 정의 지표를 얼마나 촘촘하게 보낼 수 있나"이고, Basic/Detailed는 "EC2가 자동 지표를 얼마나 자주 보내나"다.

보존(retention)도 단순하지 않다. CloudWatch는 오래된 데이터를 자동으로 롤업(aggregation) 한다. 1분 데이터는 15일만 원본으로 유지되고, 그 후 5분으로 합쳐져 63일, 다시 1시간으로 합쳐져 15개월까지 보존된다. 60초 미만 고해상도 데이터는 3시간만 살아남는다.

이 "시간이 지날수록 해상도를 낮춰 보관"하는 전략은 시계열 데이터베이스(TSDB)의 전형적 패턴으로 다운샘플링(downsampling) 또는 롤업이라 부른다. RRDtool(1999)이 원형이며, 고정 크기 순환 버퍼에 최근 데이터는 고해상도로, 과거는 저해상도로 저장한다. Graphite의 Whisper, Prometheus의 recording rule, InfluxDB의 retention policy가 모두 같은 발상이다. 최근 데이터는 디버깅용으로 촘촘하게 필요하지만 6개월 전 데이터는 추세만 보면 되므로 1초 단위까지 보관할 이유가 없다. CloudWatch가 이를 자동으로 해 주기 때문에 사용자는 보관 비용을 의식하지 않아도 된다. 다만 "어제 1초짜리 스파이크를 한 달 뒤에 다시 보려 한다"면 이미 5분 단위로 뭉개진 뒤라는 점이 함정으로 나올 수 있다.

백분위수 통계(p99, p95, p50)가 평균보다 운영에서 중요한 이유도 이 맥락이다.

• API 지연 시간의 평균이 200ms라도 p99가 3초라면 100명 중 1명은 3초를 기다린다. 이것이 사용자 이탈의 실제 원인이다.
• 평균은 소수의 극단값을 희석해 숨기지만 p99는 그 꼬리를 드러낸다. 그래서 "95%의 요청이 1초 이내"라는 SLO는 p95 < 1000ms 알람으로 구현한다.
• 백분위수는 일반 통계와 달리 데이터 포인트를 합산·평균낼 수 없다(p99들의 평균은 전체 p99가 아니다). CloudWatch가 원시 분포를 보존해야 계산할 수 있으므로 고해상도·백분위수 조합은 비용이 더 든다.

메트릭 한 개가 자동 대응이 되기까지: 알람의 상태 기계

CloudWatch의 가치는 지표를 보여 주는 데 그치지 않고, 지표가 임계값을 넘었을 때 사람 없이 대응하게 만드는 데 있다. 그 중심에 알람(Alarm)이 있고, 알람은 세 상태를 오가는 상태 기계(state machine) 다.

cloudwatch.put_metric_alarm(
    AlarmName='HighCPU',
    MetricName='CPUUtilization',
    Namespace='AWS/EC2',
    Period=300,            # 5분 단위로 평가
    EvaluationPeriods=2,   # 연속 2개 데이터 포인트가
    Threshold=80.0,        # 80%를 넘으면
    ComparisonOperator='GreaterThanThreshold',
    AlarmActions=['arn:aws:sns:...'],  # ALARM 진입 시 SNS 발행
    Dimensions=[{'Name': 'InstanceId', 'Value': 'i-1234567890'}]
)

알람은 OK(정상), ALARM(임계값 위반), INSUFFICIENT_DATA(평가 불가) 세 상태를 가진다. EvaluationPeriods=2는 한 번 80%를 찍었다고 바로 알람이 울리지 않고 연속 2개 기간이 위반해야 상태가 전환된다는 뜻이다. 일시적 스파이크에 과민 반응하지 않게 하는 디바운싱(debouncing)이다. 더 정밀하게는 "M of N" 평가(DatapointsToAlarm)로 "최근 5개 중 3개가 위반하면" 같은 조건도 만들 수 있다.

알람이 ALARM 상태로 진입하는 순간(상태 전환 시점)에 액션이 발화된다. 액션은 SNS 발행, Auto Scaling 정책 트리거, EC2 인스턴스 중지/재시작/복구, Systems Manager 작업 생성 등이다. "알람이 Auto Scaling을 직접 한다"는 오해가 흔하지만, 정확히는 알람이 Auto Scaling 정책을 호출하고 그 정책이 용량을 조정한다.

⚠️ 함정: "CPU 80% 초과 시 자동 스케일 아웃"의 정답은 "CloudWatch 알람 → Auto Scaling 정책 연결"이다. EventBridge로 직접 연결하거나 Lambda로 직접 구현하는 선택지는 오답으로 출제된다. 기술적으로 가능은 하지만 AWS가 의도한 표준 경로가 아니고 불필요하게 복잡하다. 시험은 "가장 적합한 방법"을 묻는다.

단일 알람을 여러 개 묶는 복합 알람(Composite Alarm) 은 "알람 폭풍(alarm storm)"을 막기 위해 도입됐다. 데이터베이스 장애 하나로 그에 의존하는 50개 서비스 알람이 동시에 울리면, 운영자는 근본 원인을 50개 알림 더미 속에서 찾아야 한다. 복합 알람은 "DB 알람이 ALARM이면 하위 서비스 알람들은 억제"하는 식으로 AND/OR 논리를 걸어 근본 원인 하나만 통지하게 만든다. 상관관계 기반 알림 억제(alert suppression)라는 SRE 패턴을 CloudWatch에 내장한 것이다.

로그도 결국 지표가 된다: Metric Filter와 EMF

CloudWatch Logs는 로그 그룹(보존 단위) → 로그 스트림(리소스별 흐름) → 로그 이벤트(개별 라인)의 계층으로 비정형 텍스트를 저장한다. 그러나 CloudWatch의 통합 철학에서 로그는 종착점이 아니라 지표의 원료다. 로그가 지표로 변환되는 길은 두 가지다.

첫째, Metric Filter는 로그 텍스트에서 패턴(ERROR 등)을 감지해 그 발생 횟수를 지표로 만든다. 이렇게 만든 지표에 알람을 걸면 "로그에 ERROR가 분당 5건 넘으면 통지"가 구현된다. 로그 → 패턴 매칭 → 지표 → 알람이라는 파이프라인이다.

둘째, EMF(Embedded Metric Format) 는 방향이 거꾸로다. 애플리케이션이 약속된 JSON 구조로 로그를 출력하면, CloudWatch가 그 JSON을 파싱해 자동으로 지표를 추출한다. PutMetricData API를 따로 호출하지 않아도 된다.

import json
print(json.dumps({
    "_aws": {
        "Timestamp": 1721000000000,
        "CloudWatchMetrics": [{
            "Namespace": "MyApp",
            "Dimensions": [["Environment"]],
            "Metrics": [{"Name": "OrderCount", "Unit": "Count"}]
        }]
    },
    "Environment": "prod",
    "OrderCount": 5
}))

EMF가 Lambda에서 특히 중요한 이유는 Lambda의 실행 모델 때문이다.

• PutMetricData는 동기 API 호출이다. Lambda 핸들러 안에서 호출하면 네트워크 왕복 시간만큼 함수 실행이 길어지고, 실행 시간에 비례해 과금되는 Lambda에서는 그것이 곧 비용이다.
• EMF는 stdout에 JSON을 한 줄 출력할 뿐이다. 로그는 어차피 CloudWatch로 비동기 전송되므로 추가 지연이 없고, 지표 추출은 CloudWatch 쪽에서 일어난다.
• "동기 API 호출을 비동기 로그 출력으로 대체해 핫 패스에서 빼낸다"는 것은 분산 시스템에서 흔한 최적화 패턴이다. AWS Lambda Powertools 라이브러리가 이 EMF 출력을 자동으로 처리해 준다.

로그를 외부 시스템으로 흘려보내는 Subscription Filter는 실시간 로그 파이프라인의 표준 진입점이다. CloudWatch Logs를 1차 수집소로 쓰고, Subscription Filter로 OpenSearch(검색·대시보드)나 Kinesis Data Firehose를 거쳐 S3(장기 보관)·Splunk·Datadog으로 분기시키는 구성을 쓸 수 있다. CloudWatch Logs Insights가 자체 쿼리 문법으로 최근 로그를 빠르게 뒤지는 데 강하다면, 장기 아카이브 분석은 S3 + Athena(표준 SQL) 조합이 비용 효율적이다. 둘을 역할 분담시키는 것이 실무 패턴이다.

정리

CloudWatch를 관통하는 한 문장은 "모든 신호는 결국 시계열 지표로 환원되고, 그 지표는 알람을 거쳐 자동 대응이 된다"이다. 푸시 기반 설계가 클라우드의 동적 확장과 맞아떨어졌고, 그 대가로 "침묵의 모호함"(INSUFFICIENT_DATA)을 운영자가 해석하게 됐다. EC2 메모리가 기본 지표가 아닌 것은 하이퍼바이저 경계 때문이고, 해상도·보존의 단계적 롤업은 TSDB의 보편적 트레이드오프다. 로그조차 Metric Filter와 EMF로 지표가 되어 같은 알람 파이프라인에 합류한다. 이 통합이 CloudWatch의 핵심이며, 시험 함정은 대개 이 파이프라인 위 어느 한 지점의 디테일을 묻는다.

다음 글에서는 지표가 "무엇이 느린가"는 알려줘도 "어디서 느린가"는 못 알려주는 한계를 넘어, 요청 하나가 마이크로서비스들을 통과하는 전체 경로를 추적하는 X-Ray로 넘어간다.