TIL - 20260616

juni·2026년 6월 16일

TIL

목록 보기

379/468

0616 AWS 운영 실무 기초 (7/N): CloudWatch와 모니터링, 알람 관리

✅ 1. CloudWatch란 무엇인가?

CloudWatch는 AWS 리소스와 애플리케이션의 상태를 모니터링하고 로그를 수집하는 서비스입니다.
EC2, RDS, Lambda, ECS, CloudFront 같은 AWS 서비스의 CPU, 메모리, 네트워크, 로그, 알람을 확인할 수 있습니다.
운영에서는 사용자가 장애를 제보하기 전에 개발자가 먼저 문제를 감지하는 것이 중요합니다.
CloudWatch는 그 역할을 도와주는 AWS의 대표적인 모니터링 도구입니다.

➕ 1-1. CloudWatch가 중요한 이유

장애 조기 감지
- CPU 사용률, DB 연결 수, 디스크 사용량, 에러 로그를 통해 장애 징후를 빠르게 확인할 수 있습니다.
운영 상태 확인
- 서버가 정상적으로 동작하는지, 리소스 사용량이 안정적인지 확인할 수 있습니다.
알람 설정
- 특정 조건이 발생하면 이메일, Slack, SNS 등으로 알림을 받을 수 있습니다.
장애 원인 분석
- 언제부터 문제가 발생했는지, 어떤 로그가 남았는지 확인할 수 있습니다.

✅ 2. 모니터링이란 무엇인가?

모니터링(Monitoring)은 서비스가 정상적으로 동작하는지 지속적으로 관찰하는 작업입니다.
단순히 서버가 켜져 있는지만 보는 것이 아니라, 성능, 오류, 트래픽, 비용, 보안 이벤트까지 함께 확인해야 합니다.

➕ 2-1. 모니터링 대상

대상	확인할 내용
EC2	CPU, 메모리, 디스크, 네트워크, 프로세스
RDS	CPU, 연결 수, 스토리지, 느린 쿼리
S3	요청 수, 용량, 에러
CloudFront	요청 수, 캐시 적중률, 4xx/5xx 에러
애플리케이션	API 에러, 로그, 응답 시간
비용	예상 청구 금액, 리소스 사용량

✅ 3. CloudWatch의 주요 구성 요소

➕ 3-1. Metrics

Metric은 숫자로 측정되는 지표입니다.
예를 들어 EC2 CPU 사용률, RDS 연결 수, CloudFront 요청 수가 Metric입니다.

EC2 CPUUtilization: 35%
RDS DatabaseConnections: 12
CloudFront 5xxErrorRate: 0.2%

➕ 3-2. Logs

Logs는 애플리케이션이나 AWS 서비스에서 발생한 로그를 저장하는 기능입니다.
서버 로그, 에러 로그, 접근 로그, Lambda 로그 등을 CloudWatch Logs에서 확인할 수 있습니다.

[ERROR] POST /api/consults 500 DB_SAVE_FAILED
[INFO] GET /api/products 200 34ms
[WARN] SMS API timeout retry=1

➕ 3-3. Alarms

Alarm은 특정 지표가 조건을 만족했을 때 알림을 보내는 기능입니다.
예를 들어 EC2 CPU가 80% 이상 5분 동안 유지되면 알림을 받을 수 있습니다.

EC2 CPUUtilization > 80%
5분 이상 지속
  ↓
Alarm 발생
  ↓
이메일/Slack 알림

➕ 3-4. Dashboards

Dashboard는 여러 지표를 한 화면에서 볼 수 있게 구성한 모니터링 화면입니다.
EC2, RDS, CloudFront, 애플리케이션 로그를 한 곳에서 확인할 수 있습니다.

✅ 4. EC2 모니터링

EC2는 백엔드 서버, Nginx, PM2, Docker가 실행되는 핵심 서버입니다.
EC2 상태가 나빠지면 API 응답 지연, 502 오류, 배포 실패가 발생할 수 있습니다.

➕ 4-1. EC2에서 확인할 주요 지표

지표	의미
CPUUtilization	CPU 사용률
NetworkIn	들어오는 네트워크 트래픽
NetworkOut	나가는 네트워크 트래픽
StatusCheckFailed	EC2 상태 체크 실패
Disk 사용량	디스크 용량 사용률
Memory 사용량	메모리 사용률

기본 CloudWatch만으로는 EC2 메모리와 디스크 사용량이 바로 보이지 않을 수 있습니다.
메모리와 디스크는 CloudWatch Agent를 설치해야 자세히 수집할 수 있습니다.

➕ 4-2. EC2에서 자주 발생하는 위험 신호

CPU 80% 이상 지속
메모리 부족으로 프로세스 종료
디스크 90% 이상 사용
Status Check Failed 발생
NetworkOut 급증
PM2 프로세스 반복 재시작

이런 신호가 보이면 서버 증설보다 먼저 로그, 프로세스, 쿼리, 트래픽 원인을 확인해야 합니다.

✅ 5. RDS 모니터링

DB는 웹서비스 성능의 핵심입니다.
DB가 느려지면 API 전체가 느려지고, 사용자는 화면이 멈춘 것처럼 느낄 수 있습니다.

➕ 5-1. RDS에서 확인할 주요 지표

지표	의미
CPUUtilization	DB CPU 사용률
DatabaseConnections	DB 연결 수
FreeableMemory	사용 가능한 메모리
FreeStorageSpace	남은 스토리지
ReadLatency	읽기 지연
WriteLatency	쓰기 지연
ReadIOPS	초당 읽기 작업 수
WriteIOPS	초당 쓰기 작업 수

➕ 5-2. RDS 위험 신호

CPU 80% 이상 지속
DB Connection 수 급증
FreeStorageSpace 감소
Read/Write Latency 증가
특정 관리자 목록 조회 시 DB 부하 증가
배포 후 API 응답 속도 급격히 저하

RDS 부하가 높을 때는 인스턴스만 키우기보다 먼저 쿼리, 인덱스, 페이지네이션, 커넥션 풀을 확인해야 합니다.

✅ 6. CloudFront 모니터링

CloudFront는 이미지, 정적 파일, 프론트엔드 배포에 많이 사용됩니다.
CloudFront 지표를 보면 사용자 요청 수, 에러율, 캐시 효율을 확인할 수 있습니다.

➕ 6-1. CloudFront 주요 지표

지표	의미
Requests	요청 수
BytesDownloaded	사용자에게 전송된 데이터
BytesUploaded	사용자로부터 받은 데이터
4xxErrorRate	클라이언트 오류 비율
5xxErrorRate	서버 오류 비율
CacheHitRate	캐시 적중률

➕ 6-2. CloudFront에서 볼 수 있는 문제

이미지 URL 오류로 404 증가
S3 권한 문제로 403 증가
원본 서버 장애로 5xx 증가
캐시 정책 문제로 새 파일 반영 지연
트래픽 급증으로 비용 증가

CloudFront 403 증가
  ↓
S3 버킷 정책 또는 OAC 설정 확인

CloudFront 404 증가
  ↓
S3 key 또는 배포 파일 경로 확인

CloudFront 5xx 증가
  ↓
원본 서버 또는 S3 상태 확인

✅ 7. CloudWatch Logs

CloudWatch Logs는 애플리케이션 로그를 AWS에서 모아서 확인할 수 있게 해주는 기능입니다.
EC2 내부의 PM2 로그나 Nginx 로그도 CloudWatch Agent를 통해 CloudWatch Logs로 보낼 수 있습니다.

➕ 7-1. CloudWatch Logs로 모을 수 있는 로그

백엔드 애플리케이션 로그
Nginx access log
Nginx error log
배포 로그
시스템 로그
보안 관련 로그
외부 API 실패 로그

➕ 7-2. 로그를 중앙화하는 이유

서버에 직접 SSH 접속하지 않아도 로그를 볼 수 있습니다.
여러 서버의 로그를 한 곳에서 검색할 수 있습니다.
장애 발생 시간대의 로그를 빠르게 찾을 수 있습니다.
알람과 연결할 수 있습니다.
서버가 교체되어도 로그 기록을 유지할 수 있습니다.

✅ 8. EC2 로그와 CloudWatch Logs 연결 개념

EC2 서버 안에는 기본적으로 로그 파일이 여러 위치에 쌓입니다.
CloudWatch Agent를 설치하면 이 로그 파일을 CloudWatch Logs로 전송할 수 있습니다.

/var/log/nginx/access.log
/var/log/nginx/error.log
/home/ubuntu/.pm2/logs/api-error.log
/home/ubuntu/.pm2/logs/api-out.log
  ↓
CloudWatch Agent
  ↓
CloudWatch Logs

➕ 8-1. 실무에서 유용한 로그 그룹 예시

togethermall-prod-api
togethermall-prod-nginx-access
togethermall-prod-nginx-error
togethermall-prod-deploy

서비스명, 환경, 로그 종류를 구분해서 이름을 정하면 나중에 찾기 쉽습니다.

✅ 9. 로그 보관 기간

CloudWatch Logs는 로그를 계속 저장하면 비용이 발생합니다.
운영에서는 로그 그룹마다 보관 기간을 설정하는 것이 좋습니다.

➕ 9-1. 로그 보관 기간 예시

로그 종류	보관 기간 예시
개발 서버 로그	7일
일반 API 로그	14일 ~ 30일
에러 로그	30일 ~ 90일
보안/감사 로그	90일 이상
장기 보관 로그	S3로 아카이브

주의:
보관 기간을 설정하지 않으면 로그가 계속 쌓여 비용이 늘어날 수 있음

✅ 10. 알람이 필요한 상황

알람은 모든 지표에 다 걸 필요는 없습니다.
실제 장애와 연결되는 중요한 지표에 우선 설정하는 것이 좋습니다.

➕ 10-1. 기본 알람 후보

대상	알람 조건 예시
EC2	CPU 80% 이상 5분 지속
EC2	StatusCheckFailed 발생
EC2	디스크 사용량 85% 이상
RDS	CPU 80% 이상 5분 지속
RDS	FreeStorageSpace 부족
RDS	DatabaseConnections 급증
CloudFront	5xxErrorRate 증가
애플리케이션	500 에러 로그 증가
비용	예상 비용이 기준 금액 초과

✅ 11. SNS와 알림

CloudWatch Alarm은 알림을 보내기 위해 보통 SNS(Simple Notification Service)와 연결합니다.
SNS Topic을 만들고 이메일을 구독하면 알람 발생 시 메일을 받을 수 있습니다.

➕ 11-1. 알림 흐름

CloudWatch Alarm 조건 충족
  ↓
SNS Topic
  ↓
이메일 또는 다른 알림 채널

➕ 11-2. 운영 알림 예시

EC2 CPU 80% 이상
RDS 스토리지 부족
CloudFront 5xx 급증
예상 비용 10만원 초과
API 500 에러 증가

1인 개발자라면 이메일 알림부터 시작해도 충분합니다.
팀 운영에서는 Slack, Discord, Teams 같은 채널과 연결하는 것도 좋습니다.

✅ 12. 너무 많은 알람의 문제

알람을 너무 많이 만들면 오히려 중요한 알람을 놓칠 수 있습니다.
의미 없는 알람이 계속 오면 결국 무시하게 됩니다.

➕ 12-1. 나쁜 알람 예시

CPU가 1분 동안 50% 넘으면 알림
일시적인 404 하나 발생하면 알림
트래픽 조금만 늘어도 알림
개발 서버 로그 경고까지 운영 채널에 알림

➕ 12-2. 좋은 알람 기준

실제 장애 가능성이 있는가?
사람이 대응해야 하는가?
일시적인 현상과 지속적인 문제를 구분하는가?
알람 메시지만 보고 어느 시스템 문제인지 알 수 있는가?
알람이 너무 자주 오지 않는가?

좋은 조건:
CPU 80% 이상이 5분 이상 지속
5xx 에러율이 평소보다 급증
RDS 남은 스토리지가 일정 기준 이하

✅ 13. 애플리케이션 로그 설계

CloudWatch로 로그를 모으더라도 애플리케이션 로그 자체가 엉망이면 분석이 어렵습니다.
로그는 나중에 검색할 수 있게 일정한 형식으로 남기는 것이 좋습니다.

➕ 13-1. 좋은 로그에 포함할 정보

요청 메서드
요청 URL
상태 코드
응답 시간
사용자 ID 또는 관리자 ID
요청 IP
에러 코드
에러 메시지
요청 ID
발생 시간

[ERROR] requestId=abc123 method=POST path=/api/consults status=500 userId=anonymous errorCode=DB_SAVE_FAILED duration=832ms

➕ 13-2. 로그에 남기면 안 되는 정보

비밀번호
JWT Access Token
Refresh Token
주민등록번호
인증번호
카드번호
AWS Secret Key
DB 비밀번호

좋은 예시:
phone=010****5678

나쁜 예시:
phone=01012345678

✅ 14. 요청 ID

요청 ID(Request ID)는 하나의 요청을 추적하기 위한 고유한 값입니다.
프론트엔드, 백엔드, 외부 API, DB 로그를 연결해서 볼 때 유용합니다.

➕ 14-1. 요청 ID가 필요한 이유

사용자 상담 신청 실패
  ↓
프론트엔드 에러 발생
  ↓
백엔드 API 로그 확인
  ↓
문자 발송 API 실패 확인
  ↓
같은 requestId로 전체 흐름 추적

장애가 복잡할수록 요청 ID가 있으면 원인 추적이 쉬워집니다.

➕ 14-2. 로그 예시

[INFO] requestId=req-001 POST /api/consults started
[ERROR] requestId=req-001 SMS API timeout
[INFO] requestId=req-001 POST /api/consults failed duration=1500ms

✅ 15. 비용 모니터링

AWS 운영에서는 성능 모니터링만큼 비용 모니터링도 중요합니다.
리소스를 잘못 만들거나 방치하면 예상보다 큰 비용이 발생할 수 있습니다.

➕ 15-1. 비용이 늘어나는 흔한 원인

사용하지 않는 EC2 방치
테스트 RDS 방치
오래된 스냅샷 방치
CloudWatch Logs 무제한 보관
S3 백업 파일 계속 누적
NAT Gateway 사용
CloudFront 트래픽 급증
고성능 인스턴스 실수 생성

➕ 15-2. 비용 알림 기준 예시

월 예상 비용 5만원 초과
월 예상 비용 10만원 초과
평소 대비 비용 2배 이상 증가
특정 서비스 비용 급증

1인 개발자나 작은 회사일수록 비용 알림을 반드시 설정해야 합니다.

✅ 16. 장애 대응에서 CloudWatch 활용 흐름

장애가 발생했을 때 CloudWatch는 원인을 좁혀가는 데 도움을 줍니다.

➕ 16-1. 예시: API가 느릴 때

1. CloudWatch에서 EC2 CPU 확인
2. RDS CPU/Connection 확인
3. Nginx access log에서 느린 요청 확인
4. 애플리케이션 error log 확인
5. 특정 API 또는 쿼리 문제인지 판단
6. 최근 배포와 트래픽 변화 확인

➕ 16-2. 예시: 502 Bad Gateway 발생

1. EC2 Status Check 확인
2. PM2 프로세스 상태 확인
3. Nginx error log 확인
4. 애플리케이션 로그 확인
5. 환경변수 누락 또는 DB 연결 실패 확인
6. 최근 배포 이력 확인

➕ 16-3. 예시: 이미지가 안 보일 때

1. CloudFront 4xxErrorRate 확인
2. S3 객체 key 확인
3. S3 권한 또는 OAC 설정 확인
4. CloudFront 캐시 확인
5. 브라우저 Network 탭에서 상태 코드 확인

✅ 17. 1인 개발자 기준 최소 모니터링 세팅

처음부터 복잡한 모니터링 시스템을 만들 필요는 없습니다.
하지만 최소한의 장애 감지 장치는 있어야 합니다.

➕ 17-1. 최소 구성

EC2 CPU 알람
EC2 Status Check 알람
RDS CPU 알람
RDS 스토리지 부족 알람
CloudFront 5xx 알람
AWS 비용 알림
PM2 로그 확인 루틴
Nginx error log 확인 루틴

➕ 17-2. 매일 확인하면 좋은 것

PM2 프로세스가 online 상태인가?
Nginx error log에 반복 오류가 있는가?
API 500 에러가 증가하지 않았는가?
RDS CPU와 연결 수가 안정적인가?
디스크 용량이 부족하지 않은가?
AWS 비용이 평소보다 급증하지 않았는가?

✅ 18. 실무 체크리스트

➕ 18-1. CloudWatch 체크리스트

EC2 주요 지표를 확인할 수 있는가?
RDS 주요 지표를 확인할 수 있는가?
CloudFront 에러율을 확인할 수 있는가?
필요한 로그가 CloudWatch Logs에 수집되는가?
로그 그룹 이름이 서비스/환경별로 구분되어 있는가?
로그 보관 기간이 설정되어 있는가?
중요한 지표에 알람이 설정되어 있는가?
알람 수신자가 실제로 알림을 받을 수 있는가?

➕ 18-2. 알람 체크리스트

EC2 CPU 알람이 있는가?
EC2 Status Check 알람이 있는가?
RDS CPU 알람이 있는가?
RDS 스토리지 부족 알람이 있는가?
CloudFront 5xx 알람이 있는가?
비용 알림이 설정되어 있는가?
알람 조건이 너무 민감하지 않은가?
알람 발생 시 대응 방법이 정리되어 있는가?

➕ 18-3. 로그 체크리스트

로그에 요청 URL, 상태 코드, 응답 시간이 남는가?
에러 로그에 stack trace가 남는가?
개인정보와 토큰이 로그에 남지 않는가?
requestId로 요청 흐름을 추적할 수 있는가?
외부 API 실패 로그가 남는가?
로그가 너무 오래 보관되어 비용이 늘지 않는가?

✅ 19. AI를 활용해 CloudWatch 문제를 해결할 때 질문법

모니터링 문제는 지표, 로그, 알람 조건, 발생 시간대를 같이 알려줘야 정확한 답을 받을 수 있습니다.
“서버가 느려”라고만 말하면 원인을 좁히기 어렵습니다.

➕ 19-1. 좋은 질문 예시

AWS EC2 + RDS + CloudWatch 환경에서 API 응답이 느려졌어.

상황:
1. 백엔드는 EC2에서 NestJS + PM2로 실행 중
2. DB는 RDS PostgreSQL
3. 최근 배포 이후 관리자 상담 목록 조회가 느려짐
4. CloudWatch에서 RDS CPU가 85%까지 올라감
5. DatabaseConnections도 평소보다 증가함
6. EC2 CPU는 30% 정도로 안정적임
7. Nginx access log에서 /api/admin/consults 요청이 오래 걸림

이 상황에서 원인 후보와 확인 순서를 알려줘.
쿼리, 인덱스, 페이지네이션, 커넥션 관리 관점으로 설명해줘.

➕ 19-2. AI 답변 검증 기준

EC2와 RDS 지표를 구분하는가?
로그와 지표를 함께 보라고 하는가?
무조건 서버 스펙부터 올리라고 하지 않는가?
쿼리, 인덱스, 페이지네이션을 확인하는가?
최근 배포 변경사항을 확인하게 하는가?
알람 조건과 로그 보관 비용까지 고려하는가?
민감정보가 포함된 로그를 그대로 보내라고 하지 않는가?

📌 요약

CloudWatch는 AWS 리소스와 애플리케이션의 지표, 로그, 알람을 관리하는 모니터링 서비스입니다.
EC2에서는 CPU, 네트워크, 상태 체크, 메모리, 디스크를 확인해야 하고, 메모리/디스크는 CloudWatch Agent가 필요할 수 있습니다.
RDS에서는 CPU, 연결 수, 스토리지, 읽기/쓰기 지연, IOPS를 확인해야 합니다.
CloudFront에서는 요청 수, 4xx/5xx 에러율, 캐시 적중률을 확인할 수 있습니다.
CloudWatch Logs를 사용하면 EC2, Nginx, PM2, 애플리케이션 로그를 한 곳에서 모아 볼 수 있습니다.
로그에는 사용자 ID, 요청 URL, 상태 코드, 응답 시간, 에러 코드를 남기되, 비밀번호와 토큰 같은 민감정보는 남기면 안 됩니다.
알람은 너무 많이 만들기보다 실제 장애와 연결되는 중요한 조건에 우선 설정해야 합니다.
1인 개발자라도 EC2, RDS, CloudFront, 비용 알림 정도는 최소한 설정해두는 것이 좋습니다.

juni

이전 포스트

TIL - 20260615

다음 포스트

TIL - 20260616

TIL

0616 AWS 운영 실무 기초 (7/N): CloudWatch와 모니터링, 알람 관리

✅ 1. CloudWatch란 무엇인가?

➕ 1-1. CloudWatch가 중요한 이유

✅ 2. 모니터링이란 무엇인가?

➕ 2-1. 모니터링 대상

✅ 3. CloudWatch의 주요 구성 요소

➕ 3-1. Metrics

➕ 3-2. Logs

➕ 3-3. Alarms

➕ 3-4. Dashboards

✅ 4. EC2 모니터링

➕ 4-1. EC2에서 확인할 주요 지표

➕ 4-2. EC2에서 자주 발생하는 위험 신호

✅ 5. RDS 모니터링

➕ 5-1. RDS에서 확인할 주요 지표

➕ 5-2. RDS 위험 신호

✅ 6. CloudFront 모니터링

➕ 6-1. CloudFront 주요 지표

➕ 6-2. CloudFront에서 볼 수 있는 문제

✅ 7. CloudWatch Logs

➕ 7-1. CloudWatch Logs로 모을 수 있는 로그

➕ 7-2. 로그를 중앙화하는 이유

✅ 8. EC2 로그와 CloudWatch Logs 연결 개념

➕ 8-1. 실무에서 유용한 로그 그룹 예시

✅ 9. 로그 보관 기간

➕ 9-1. 로그 보관 기간 예시

✅ 10. 알람이 필요한 상황

➕ 10-1. 기본 알람 후보

✅ 11. SNS와 알림

➕ 11-1. 알림 흐름

➕ 11-2. 운영 알림 예시

✅ 12. 너무 많은 알람의 문제

➕ 12-1. 나쁜 알람 예시

➕ 12-2. 좋은 알람 기준

✅ 13. 애플리케이션 로그 설계

➕ 13-1. 좋은 로그에 포함할 정보

➕ 13-2. 로그에 남기면 안 되는 정보

✅ 14. 요청 ID

➕ 14-1. 요청 ID가 필요한 이유

➕ 14-2. 로그 예시

✅ 15. 비용 모니터링

➕ 15-1. 비용이 늘어나는 흔한 원인

➕ 15-2. 비용 알림 기준 예시

✅ 16. 장애 대응에서 CloudWatch 활용 흐름

➕ 16-1. 예시: API가 느릴 때

➕ 16-2. 예시: 502 Bad Gateway 발생

➕ 16-3. 예시: 이미지가 안 보일 때

✅ 17. 1인 개발자 기준 최소 모니터링 세팅

➕ 17-1. 최소 구성

➕ 17-2. 매일 확인하면 좋은 것

✅ 18. 실무 체크리스트

➕ 18-1. CloudWatch 체크리스트

➕ 18-2. 알람 체크리스트

➕ 18-3. 로그 체크리스트

✅ 19. AI를 활용해 CloudWatch 문제를 해결할 때 질문법

➕ 19-1. 좋은 질문 예시

➕ 19-2. AI 답변 검증 기준

📌 요약

TIL - 20260615

TIL - 20260617

0개의 댓글