AWS Certified CloudOps Engineer - Associate (SOA-C03) #2 Domain 1-1 모니터링: CloudWatch 지표,알람,대시보드
#1 시험 소개에서 SOA-C03의 다섯 도메인 중 모니터링,로깅,복구,성능이 22%로 가장 크다고 했습니다. 그 도메인의 출발점이 CloudWatch입니다. CloudWatch는 단순한 그래프 도구가 아니라, AWS 환경에서 일어나는 모든 일을 숫자(지표)와 기록(로그)으로 받아 두는 관측 계층입니다. 운영의 거의 모든 조치가 “CloudWatch가 무언가를 감지한다"에서 시작합니다.
이 글은 그 관측 계층의 첫 절반인 지표,알람,대시보드를 다룹니다. 로그와 Logs Insights는 #3에서, 감지 이후의 자동 복구는 #4에서 이어가겠습니다.
지표(Metric)란 무엇인가 #
지표는 시간에 따라 찍히는 숫자 데이터 포인트의 시계열입니다. EC2 인스턴스의 CPUUtilization, ELB의 RequestCount, SQS 큐의 ApproximateNumberOfMessagesVisible이 모두 지표입니다. CloudWatch는 이 지표들을 다음 구조로 정리합니다.
| 개념 | 설명 | 예시 |
|---|---|---|
| Namespace | 지표의 묶음. 서비스 단위로 격리 | AWS/EC2, AWS/RDS, 사용자 지정은 MyApp |
| Metric name | 측정 항목의 이름 | CPUUtilization, RequestCount |
| Dimension | 지표를 식별하는 키,값 쌍 | InstanceId=i-0abc..., AutoScalingGroupName=web-asg |
| Resolution | 데이터 포인트 간격 | 표준 60초, 고해상도 1초 |
핵심은 차원(dimension)입니다. 같은 CPUUtilization이라도 InstanceId별로 따로 찍히고, ASG 이름으로 묶어 볼 수도 있습니다. 시험에서 “특정 인스턴스만 알람을 걸고 싶다"는 시나리오는 결국 차원으로 지표를 좁히는 문제입니다.
표준 지표 vs 사용자 지정 지표 #
| 구분 | 표준 지표 | 사용자 지정 지표 |
|---|---|---|
| 제공 주체 | AWS 서비스가 자동 게시 | 사용자가 PutMetricData로 게시 |
| 예시 | EC2 CPU, ELB 지연 시간 | 애플리케이션 응답 시간, 큐 적체 길이 |
| 메모리,디스크 | EC2 표준 지표에 없음 | CloudWatch Agent로 게시해야 수집 |
시험에서 가장 자주 나오는 함정 하나는 EC2의 메모리 사용률과 디스크 사용률은 표준 지표가 아니라는 점입니다. 하이퍼바이저 바깥에서 보이지 않기 때문입니다. 메모리,디스크를 알람으로 감시하려면 CloudWatch Agent를 인스턴스에 설치해 사용자 지정 지표로 게시해야 합니다. 이 패턴은 거의 단골입니다.
알람(Alarm): 감지의 핵심 #
알람은 지표가 정해진 조건을 만족하는지 주기적으로 평가해 상태를 바꾸는 장치입니다. 상태는 셋입니다.
| 상태 | 의미 |
|---|---|
OK | 지표가 임계값 안에 있음 |
ALARM | 지표가 임계값을 위반함 |
INSUFFICIENT_DATA | 평가할 데이터가 부족함(시작 직후, 데이터 누락 등) |
알람을 만들 때 정하는 값이 정답을 가릅니다.
- Period(기간): 지표를 집계하는 단위 시간. 예: 60초
- Evaluation Periods(평가 기간 수): 몇 개의 기간을 보고 판단할지
- Datapoints to Alarm(알람 데이터 포인트 수): 평가 기간 중 몇 개가 위반해야
ALARM으로 갈지
예를 들어 Period=60s, Evaluation Periods=5, Datapoints to Alarm=3이면 최근 5분 중 3분이 임계값을 넘으면 알람이 울립니다. 이런 M of N 설정은 일시적 스파이크로 알람이 오작동하는 것을 막는 표준 방법이며, 시험에 자주 나옵니다.
누락 데이터(Missing Data) 처리 #
지표 데이터가 들어오지 않을 때 알람이 어떻게 행동할지도 설정합니다.
| 옵션 | 동작 |
|---|---|
missing (기본) | 누락 기간을 평가에서 무시 |
notBreaching | 누락을 정상으로 간주 |
breaching | 누락을 위반으로 간주 |
ignore | 현재 알람 상태 유지 |
배치 작업처럼 데이터가 드문드문 들어오는 지표에서는 이 설정을 잘못 두면 알람이 계속 INSUFFICIENT_DATA에 머무릅니다. “간헐적 지표인데 알람이 안 울린다"는 시나리오의 답은 보통 누락 데이터 처리 옵션 조정입니다.
알람 동작(Action) #
알람이 상태를 바꾸면 동작을 트리거할 수 있습니다.
- SNS 알림: 가장 흔한 형태. 이메일,Slack,Lambda로 전파
- Auto Scaling 정책: ASG의 용량을 늘리거나 줄임
- EC2 동작: 인스턴스 중지,종료,재부팅,복구
- Systems Manager 동작: OpsItem 생성, Automation 실행
특히 EC2 자동 복구(recover) 동작은 하드웨어 장애로 인스턴스가 손상됐을 때 같은 인스턴스를 새 하드웨어에서 복구합니다. “인스턴스가 시스템 상태 점검에 실패할 때 자동 복구"는 StatusCheckFailed_System 지표 알람에 복구 동작을 거는 단골 패턴입니다.
복합 알람(Composite Alarm) #
단일 지표 알람을 여러 개 엮어 논리식(AND,OR,NOT)으로 묶는 알람입니다.
ALARM("high-cpu") AND ALARM("high-latency")복합 알람의 핵심 효용은 알람 소음(noise) 감소입니다. CPU가 잠깐 튈 때마다 알림이 오면 운영자가 둔감해집니다. “CPU도 높고 지연 시간도 높을 때만” 알리도록 복합 알람으로 묶으면 진짜 문제일 때만 알림이 갑니다. “알림이 너무 많아 줄이고 싶다"는 시나리오의 답으로 자주 나옵니다.
대시보드(Dashboard) #
대시보드는 여러 지표 그래프와 알람 상태를 한 화면에 모아 보는 구성입니다.
- 교차 리전,교차 계정 위젯을 한 대시보드에 모을 수 있음
- JSON으로 정의되어 CloudFormation,코드로 재현 가능
- 자동 새로 고침으로 운영 상황판(NOC) 용도
시험에서 대시보드 자체는 비중이 작지만, “여러 계정,리전의 지표를 한곳에서 본다"는 요구의 답으로 등장합니다. 교차 계정 관측은 보통 CloudWatch cross-account observability를 함께 구성합니다.
지표 수학(Metric Math)과 이상 탐지 #
- Metric Math: 여러 지표를 수식으로 결합해 새 지표를 만듭니다. 예를 들어 “성공 요청 비율 = 성공 수 / 전체 수"를 계산해 그 결과에 알람을 겁니다.
- Anomaly Detection: 과거 패턴을 학습해 정상 범위 밴드를 만들고, 그 밴드를 벗어나면 알람을 울립니다. 트래픽이 시간대별로 출렁이는 워크로드에서 고정 임계값 대신 씁니다.
“주간,야간 트래픽 차이가 커서 고정 임계값으로는 알람이 부정확하다"는 시나리오의 답이 이상 탐지입니다.
시험 출제 패턴 #
- EC2 메모리,디스크 지표가 안 보인다 → CloudWatch Agent 설치(사용자 지정 지표)
- 일시적 스파이크로 알람이 오작동한다 →
Datapoints to Alarm을 올려M of N설정 - 간헐적 지표인데 알람이 안 운다 → 누락 데이터(
treat missing data) 옵션 조정 - 알림이 너무 많다 → 복합 알람으로 조건을 AND로 묶기
- 시간대별 변동이 커 임계값을 못 정한다 → 이상 탐지
- 시스템 상태 점검 실패 시 자동으로 살리고 싶다 →
StatusCheckFailed_System알람 + EC2 복구 동작
자주 만나는 함정 #
1) 메모리,디스크가 표준 지표에 있다고 생각 #
EC2 표준 지표에는 CPU,네트워크,디스크 I/O는 있어도 OS 안의 메모리 사용률과 파일시스템 사용률은 없습니다. Agent가 필요합니다.
2) Period와 Evaluation Periods를 혼동 #
Period는 “한 데이터 포인트를 집계하는 시간”, Evaluation Periods는 “몇 개를 볼지"입니다. 둘을 곱한 값이 실제 판단 창의 길이입니다.
3) 복합 알람이 지표를 직접 평가한다고 오해 #
복합 알람은 지표가 아니라 다른 알람의 상태를 입력으로 받습니다. 먼저 단일 알람을 만들고 그것들을 묶는 순서입니다.
4) 고해상도 지표의 비용을 무시 #
1초 해상도 사용자 지정 지표는 표준 60초보다 비용이 큽니다. “모든 지표를 1초로” 같은 답안은 비용 제약 시나리오에서 보통 오답입니다.
정리 #
이번 글에서 잡은 것:
- 지표는 Namespace,Metric,Dimension,Resolution으로 정리되는 시계열. 차원으로 대상을 좁힘
- EC2 메모리,디스크는 표준 지표가 아님. CloudWatch Agent로 사용자 지정 지표 게시
- 알람은 Period,Evaluation Periods,Datapoints to Alarm으로
M of N판단. 누락 데이터 처리 옵션 별도 - 알람 동작은 SNS,Auto Scaling,EC2 복구,Systems Manager. EC2 자동 복구는 시스템 상태 점검 실패 단골
- 복합 알람으로 조건을 묶어 알림 소음 감소. 이상 탐지로 변동 큰 워크로드의 동적 임계값
- 대시보드는 JSON 정의로 코드 재현 가능, 교차 계정,리전 통합 관측
다음: Domain 1-2 CloudWatch Logs와 Logs Insights #
지표로 “무슨 일이 일어났는지"를 잡았으니, 다음은 그 일의 자세한 기록인 로그입니다.
#3 Domain 1-2 모니터링: CloudWatch Logs,Logs Insights,에이전트에서는 로그 그룹과 로그 스트림의 구조, CloudWatch Agent로 로그를 수집하는 법, 로그 기반 지표 필터(Metric Filter), Logs Insights 쿼리로 대량 로그를 분석하는 법, 그리고 구독 필터(Subscription Filter)로 로그를 실시간 전달하는 구성까지 정리하겠습니다.