CloudWatch로 보는 AWS 모니터링의 기본 구조
CloudWatch의 Metrics, Logs, Alarms가 어떻게 연결되어 장애 대응의 출발점이 되는지 설명한다. 비용 함정, 알람 상태, ECS Fargate 관측, 트러블슈팅 포인트까지 원문 범위에서 정리한다.
Script Companion
오디오와 함께 스크립트 보기
- 01
CloudWatch는 AWS에서 서비스가 정상인지, 느려지고 있는지, 장애가 발생했는지를 확인하는 기본 모니터링 도구다. 대부분의 AWS 서비스가 자동으로 CloudWatch에 지표를 보내기 때문에, 장애 대응을 시작할 때 가장 먼저 보게 되는 출발점이 된다. 프론트엔드 개발자에게 익숙한 브라우저 DevTools의 Performance 탭이나 Network 탭을 떠올리면 이해가 쉽다. 클라이언트에서 FCP, LCP, 요청 응답 시간, 에러 코드를 보듯이, 서버 쪽에서는 CloudWatch Metrics와 Logs로 같은 관심사를 관찰한다.
- 02
CloudWatch의 전체 흐름은 병원 차트 시스템처럼 볼 수 있다. EC2, ECS, Lambda 같은 AWS 서비스가 환자라면, CPU 사용률이나 요청 수 같은 Metrics는 혈압과 체온처럼 지속적으로 기록되는 수치다. 운영자는 이 수치를 보다가 이상이 생기면 Alarm을 받고, 특이한 증상은 Logs에 남겨 나중에 검색한다. 내부적으로 CloudWatch는 시계열 데이터베이스 구조를 가지며, AWS 서비스나 애플리케이션이 CloudWatch API의 PutMetricData로 지표를 푸시할 수 있다.
- 03
CloudWatch 데이터는 리전별로 분리 저장되고, 지표는 최대 15개월 보관된다. 고해상도 1초 단위부터 1분, 5분 단위까지 집계 저장되는 방식도 중요하다. 최신 데이터는 세밀하게 보고, 오래된 데이터는 효율적으로 보관하려는 비용 최적화 구조다. 리전별 분리는 AWS의 장애 격리 원칙과 연결된다. 한 리전이 장애를 겪어도 다른 리전의 모니터링 데이터가 함께 영향을 받지 않도록 경계를 나누는 것이다.
- 04
시계열 데이터베이스라는 관점은 CloudWatch에만 머물지 않는다. CloudWatch, Prometheus, Datadog은 구현은 달라도 모니터링 데이터를 시간의 흐름에 따라 저장하고 질의한다는 기반을 공유한다. 새 모니터링 도구를 볼 때는 세 가지 질문을 먼저 던질 수 있다. 데이터를 어떻게 격리하는가, 카디널리티 비용 구조는 무엇인가, 오래된 데이터를 어떻게 집계하는가. CloudWatch는 리전별 데이터 분리, Prometheus는 페더레이션, Datadog은 멀티리전 Site 분리라는 방식으로 비슷한 문제를 다룬다.
- 05
Metrics는 CPU 사용률, 메모리 사용량, 요청 수, 에러 수처럼 수치화된 데이터다. 각 지표는 네임스페이스 Namespace와 차원 Dimension의 조합으로 식별된다. 예를 들어 AWS/EC2 네임스페이스의 CPUUtilization 지표를 InstanceId 차원으로 조회하는 식이다. 여기서 가장 흔한 비용 실수는 고카디널리티 차원이다. userId를 Dimension으로 쓰면 사용자 10만 명이 커스텀 지표 10만 개가 되고, 원문 예시 기준으로 월 30,000달러 청구가 된다. 차원이 다르면 CloudWatch는 별도 지표로 처리하기 때문이다.
- 06
Logs는 애플리케이션이나 서비스가 출력하는 텍스트 로그이며, Log Group과 Log Stream 계층으로 저장된다. Log Group은 서비스나 애플리케이션 단위이고, Log Stream은 개별 컨테이너 인스턴스나 태스크 단위에 가깝다. 브라우저 콘솔에서 에러를 찾던 습관은 서버에서는 CloudWatch Log Insights 쿼리로 이어진다. 또한 Metric Filter를 쓰면 로그에서 특정 패턴을 숫자 지표로 추출할 수 있다. 예를 들어 ERROR 키워드가 나타날 때마다 카운트를 증가시키고, 그 지표에 알람을 연결할 수 있다.
- 07
Alarms는 지표가 특정 조건을 넘었을 때 알림을 보내는 기능이다. 알람은 지정된 평가 주기마다 Average나 Max 같은 통계값을 임계값과 비교하고, OK, ALARM, INSUFFICIENT_DATA 같은 상태로 전환된다. 중요한 점은 알람이 상태가 전환될 때만 발동한다는 것이다. 이미 ALARM 상태라면 임계값을 계속 넘고 있어도 다시 발동하지 않는다. INSUFFICIENT_DATA도 문제없음이 아니라 지표 데이터가 부족해서 평가할 수 없다는 뜻이다. 지표 수집이 끊겼거나 ECS 태스크가 중단된 상황이라면 Treat missing data as breaching 설정이 필요할 수 있다.
- 08
Dashboard는 여러 지표를 한 화면에 모아 팀별, 서비스별 상태를 한눈에 보는 도구다. ECS Fargate를 운영한다면 Container Insights도 중요하다. 기본 CloudWatch 지표만으로는 컨테이너 수준의 세부 정보를 보기 어렵지만, Container Insights를 활성화하면 클러스터, 서비스, 태스크, 컨테이너 레벨별 지표를 수집할 수 있다. CpuUtilized, MemoryUtilized, NetworkRxBytes, NetworkTxBytes, EphemeralStorageUtilized, RunningTaskCount 같은 지표가 추가된다. Fargate는 별도 에이전트 설치 없이 클러스터 설정 변경만으로 동작한다.
- 09
운영 패턴으로는 로그 보존 정책, 통합 알람 대시보드, Detailed Monitoring을 함께 본다. 비즈니스 중요도에 따라 Log Group의 Retention을 나누면 비용과 운영 효율을 함께 조절할 수 있고, 원문에서는 이 전략으로 CloudWatch 로깅 비용을 최대 30% 절감할 수 있다고 설명한다. 통합 알람 대시보드는 여러 리전과 여러 서비스 지표를 한 화면에 배치하는 방식이다. 기본 EC2와 ECS 지표는 5분 간격으로 수집되지만, 프로덕션 서비스에서는 Detailed Monitoring으로 1분 간격 전환을 검토할 수 있다. 다만 소폭 추가 비용이 발생한다.
- 10
트러블슈팅에서는 증상과 상태의 의미를 정확히 구분해야 한다. Alarm이 ALARM인데 Slack이나 이메일 알림이 오지 않으면 SNS Topic 구독이 Pending confirmation 상태일 수 있고, 이메일 확인 링크를 눌러 Confirmed로 바뀌었는지 봐야 한다. CPU가 90%인데도 알람이 OK라면 Evaluation periods와 Datapoints to alarm 설정 때문에 연속 초과 조건을 아직 만족하지 못했을 수 있다. Unit이 Percent와 None처럼 맞지 않는 경우도 확인 대상이다. Log Insights 결과가 비어 있으면 시간 범위, Log Group 선택, ECS Task의 logConfiguration, IAM 권한을 차례로 의심한다.
- 11
비용 문제도 CloudWatch에서 자주 만나는 실패 포인트다. Log Group의 Retention이 없어 로그가 무기한 보관되거나, 고해상도 커스텀 지표를 대량 전송하거나, Log Insights 쿼리를 자동화 스크립트로 자주 실행하면 청구가 커질 수 있다. 삭제된 EC2, ECS, RDS 리소스와 연결된 Zombie Alarm도 비용을 남긴다. High-Resolution Alarm은 10초 단위라 Standard Alarm보다 3배 비싸므로 실제로 10초 이하 감지가 필요한지 재검토해야 한다. 정리하면 CloudWatch는 Metrics, Logs, Alarms를 연결해 AWS 모니터링의 기본 흐름을 만들고, Datadog과 Grafana로 확장하기 전의 출발점이 된다.
같은 레이어