CloudWatch 완전 정복: 클라우드 서비스의 '블랙박스'를 읽는 법

들어가며: "서버가 언제 죽었는지 모릅니다"

모니터링이 없는 인프라 운영은 계기판 없이 비행기를 모는 것과 같다.

실제로 벌어지는 시나리오:

1. 금요일 저녁, 팀원들이 퇴근한다
2. 토요일 새벽, EC2 인스턴스의 디스크가 꽉 찬다
3. 애플리케이션이 로그를 쓸 수 없어 에러가 발생한다
4. 사용자들이 서비스 장애를 경험한다
5. 월요일 아침, 출근해서야 알게 된다
6. 48시간 동안 서비스가 죽어 있었다

이것은 과장이 아니다. 모니터링이 제대로 설정되지 않은 소규모 서비스에서 실제로 반복되는 패턴이다.

모니터링의 목표는 단순하다: 문제가 발생하면 사람보다 기계가 먼저 알아채는 것. 그리고 AWS에서 이 역할을 하는 것이 CloudWatch다.

1. 모니터링과 관측성: 왜 필요한가

관측성(Observability)의 세 기둥

Google의 SRE(Site Reliability Engineering) 팀이 정립하고, Cindy Sridharan이 2018년 저서 "Distributed Systems Observability"에서 체계화한 관측성의 세 기둥(Three Pillars of Observability):

• 메트릭: "지금 상태가 어떤가?" — CPU 사용률, 메모리, 요청 수 같은 시계열 숫자 데이터. 대시보드의 그래프
• 로그: "무슨 일이 일어났는가?" — 이벤트의 텍스트 기록. 에러 메시지, 접근 로그, 감사 로그
• 트레이스: "요청이 어떤 경로로 흘렀는가?" — 마이크로서비스 환경에서 하나의 요청이 여러 서비스를 거치는 전체 경로 추적

CloudWatch는 이 세 기둥을 하나의 서비스로 통합한다.

Google SRE의 4대 황금 시그널

Google의 SRE 책 "Site Reliability Engineering"(2016)에서 정의한, 모든 서비스가 반드시 모니터링해야 할 4대 황금 시그널(Four Golden Signals):

2. CloudWatch란 무엇인가

정의

Amazon CloudWatch는 AWS 리소스와 애플리케이션의 모니터링·관측성 서비스다. 2009년 출시로, AWS에서 가장 오래된 서비스 중 하나다.

핵심 기능 5가지:

CloudWatch는 AWS의 "기본 장착" 모니터링

CloudWatch의 가장 큰 장점: AWS의 거의 모든 서비스가 자동으로 CloudWatch에 메트릭을 보낸다. 별도 설정 없이.

EC2를 시작하면 → CPU 사용률, 네트워크 I/O, 디스크 I/O가 자동으로 CloudWatch에 RDS를 만들면 → DB 커넥션 수, 쿼리 지연시간, 여유 메모리가 자동으로 Lambda를 배포하면 → 실행 횟수, 에러 수, 실행 시간이 자동으로 EBS를 연결하면 → IOPS, 처리량, 큐 길이가 자동으로

3. CloudWatch Metrics: 숫자로 보는 인프라 건강

기본 메트릭 vs 커스텀 메트릭

기본 메트릭(Basic Metrics): AWS 서비스가 자동으로 보내는 메트릭. 무료.

커스텀 메트릭(Custom Metrics): 애플리케이션에서 직접 보내는 메트릭. 유료.

import boto3

cloudwatch = boto3.client("cloudwatch")

# 주문 처리 시간을 커스텀 메트릭으로 전송
cloudwatch.put_metric_data(
    Namespace="MyApp/Orders",
    MetricData=[{
        "MetricName": "OrderProcessingTime",
        "Value": 1.23,
        "Unit": "Seconds",
        "Dimensions": [{"Name": "Environment", "Value": "production"}]
    }]
)

4. CloudWatch Alarms: 문제를 사람보다 먼저 아는 법

알람의 구조

CloudWatch Alarm은 세 가지 상태를 가진다:

• OK: 메트릭이 정상 범위
• ALARM: 임계값을 초과하여 경보 발생
• INSUFFICIENT_DATA: 데이터가 부족하여 판단 불가

실전: 반드시 설정해야 할 알람 5가지

1. EC2 CPU 과부하

aws cloudwatch put-metric-alarm \
  --alarm-name "High-CPU" \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 3 \
  --alarm-actions arn:aws:sns:ap-northeast-2:123:ops-team

"5분 평균 CPU가 80%를 3번 연속 초과하면 SNS로 알림."

2. EBS 디스크 꽉 참 (CloudWatch Agent 필요)

3. RDS 여유 메모리 부족

FreeableMemory < 500MB → 경고
FreeableMemory < 100MB → 긴급

4. Lambda 에러 급증

Errors > 10/분 → 알림

5. 예산 초과 (CloudWatch Billing Alarm)

EstimatedCharges > $500 → 알림

알람 → 자동 대응

알람은 알림만 보내는 게 아니다. 자동 조치(Auto Action) 를 트리거할 수 있다:

• Auto Scaling: CPU 80% 알람 → EC2 인스턴스 자동 추가
• Lambda 트리거: 알람 → SNS → Lambda → 자동 복구 스크립트 실행
• EC2 재시작: StatusCheck 실패 알람 → EC2 자동 재부팅
• ECS 스케일링: 타겟 응답시간 알람 → ECS 태스크 수 자동 증가

5. CloudWatch Logs: 모든 것은 로그에 기록된다

로그의 구조

CloudWatch Logs는 세 계층으로 구성된다:

• 로그 그룹 (Log Group): 로그의 최상위 컨테이너. 보통 서비스/앱 단위. /ecs/my-api, /aws/lambda/my-function
• 로그 스트림 (Log Stream): 로그 그룹 내의 개별 소스. 컨테이너 인스턴스, Lambda 실행 환경 등
• 로그 이벤트 (Log Event): 실제 로그 메시지 한 줄 + 타임스탬프

로그 수집 방법

Logs Insights: 로그에서 인사이트를 캐내기

CloudWatch Logs Insights는 SQL과 유사한 쿼리 언어로 로그를 분석한다.

# 지난 1시간 동안 가장 많이 발생한 에러 TOP 10
fields @timestamp, @message
| filter @message like /ERROR/
| stats count(*) as error_count by @message
| sort error_count desc
| limit 10

# 특정 사용자의 요청 추적
fields @timestamp, @message
| filter @message like /user_id=u123/
| sort @timestamp desc
| limit 50

# Lambda 실행시간 P99 추이
filter @type = "REPORT"
| stats percentile(@duration, 99) as p99_duration by bin(5m)

6. 모니터링 부재의 대가: 실제 사고 사례

AWS 자체 장애에서 배우기

2017년 2월 — S3 us-east-1 장애 (인터넷의 30%가 다운)

AWS 엔지니어가 S3 빌링 시스템 디버깅 중 실수로 대규모 서버를 제거하는 명령을 실행했다. S3 us-east-1이 4시간 동안 장애를 일으켰고, S3에 의존하는 수많은 서비스(Slack, Trello, IFTTT, 심지어 AWS 자체 대시보드)가 마비됐다.

교훈: AWS의 상태 대시보드 자체가 S3에 의존하고 있어서, 장애 상황을 대시보드에서 확인할 수 없었다. 이후 AWS는 상태 페이지를 S3에서 분리했다.

2020년 11월 — Kinesis 장애 → CloudWatch 모니터링 마비

Kinesis Data Streams 장애가 발생했는데, CloudWatch가 Kinesis에 의존하는 부분이 있어 모니터링 자체가 먹통이 됐다. 알람이 발동하지 않아 고객들이 장애를 인지하는 데 더 오래 걸렸다.

교훈: 모니터링 시스템 자체의 가용성도 모니터링 대상이다.

기업의 모니터링 부재 사고

7. CloudWatch 비용: 무료로 쓰는 법과 함정

무료 티어

CloudWatch에는 **항상 무료(Free Tier)**인 부분이 있다:

비용 함정

비용 최적화 전략

8. CloudWatch 대안들: 언제 다른 도구를 써야 하나

CloudWatch만으로 충분한가?

소규모~중간 규모에서는 CloudWatch만으로 충분하다. 하지만 대규모 서비스나 특수한 요구사항에서는 전문 도구가 필요할 수 있다.

9. 실전 대시보드 구성

서비스별 대시보드 템플릿

웹 서비스 대시보드 (필수 위젯):

Infrastructure as Code로 대시보드 관리

CloudFormation이나 Terraform으로 대시보드를 코드로 관리하면, 환경마다 동일한 대시보드를 자동 생성할 수 있다.

10. 실제 사례

Netflix: 관측성의 교과서

Netflix는 자체 모니터링 도구 Atlas를 운영하지만, 기반 인프라에는 CloudWatch를 활용한다. 하루에 수십억 개의 메트릭 데이터 포인트를 수집하며, 이상 감지 알고리즘으로 장애를 자동 탐지한다.

Netflix의 Chaos Monkey는 프로덕션에서 임의로 인스턴스를 죽여 시스템의 복원력을 테스트하는 도구다. CloudWatch 알람이 이 "의도적 장애"를 즉시 감지하고 자동 복구가 작동하는지 검증한다.

Airbnb: 커스텀 메트릭으로 비즈니스 모니터링

Airbnb는 인프라 메트릭뿐 아니라 비즈니스 메트릭(예약 수, 검색 전환율, 결제 성공률)도 CloudWatch 커스텀 메트릭으로 추적한다. "예약 수가 평소 대비 30% 감소"하면 기술 장애가 아니더라도 알람이 발동한다.

한국 기업 사례

• 쿠팡: CloudWatch + Datadog 조합. 로켓배송 시스템의 주문 처리 지연시간을 실시간 모니터링
• 토스: CloudWatch + Grafana. 금융 거래의 성공/실패율, 지연시간을 초 단위로 추적
• 배달의민족: CloudWatch 알람으로 주문 폭주 시 자동 스케일링 트리거

마치며: "모니터링은 나중에"의 함정

많은 팀이 이렇게 말한다: "일단 서비스부터 만들고, 모니터링은 나중에." 하지만 "나중"은 보통 장애가 터진 후가 된다.

모니터링은 서비스 론칭과 동시에 설정해야 한다. 아니, 론칭 전에 설정해야 한다. 모니터링 없는 서비스는 계기판 없는 비행기다 — 이륙은 할 수 있지만, 안전하게 착륙할 수 있을지는 운에 달려 있다.

이 시리즈 전체에서 다룬 서비스들을 CloudWatch 관점에서 모으면:

코어닷투데이의 AI 서비스에서도 CloudWatch는 "언제나 켜져 있는 감시자"다. AI 추론 서버의 응답 시간, 모델 서빙의 에러율, 데이터 파이프라인의 처리량 — 이 모든 지표가 CloudWatch 대시보드에서 실시간으로 확인되고, 이상이 감지되면 즉시 알람이 울린다. 서비스가 죽기 전에 우리가 먼저 안다 — 그것이 모니터링의 가치다.