M7 ‐ 장애 알림 시스템 구축 - 100-hours-a-week/KTB4-4th-wiki GitHub Wiki
목차
- 1. 목적
- 2. 모니터링 범위
- 3. 전체 구조
- 4. CloudWatch Logs 수집
- 5. EC2 리소스 모니터링
- 6. Service Health Check
- 7. 로그 기반 오류 감지
- 8. 장애 중요도
- 9. SNS 알림
- 10. CloudWatch Dashboard
- 11. 장애 발생 시 대응
- 12. 팀원 조회 권한
- 13. V1에서 제외한 항목
- 14. 참고 자료
1. 목적
Need U V1은 단일 EC2에서 Frontend, Backend, AI Server, Redis, MySQL, PostgreSQL을 함께 운영한다.
단일 EC2 구조에서는 인스턴스 장애가 전체 서비스에 영향을 줄 수 있고, EC2가 정상이어도 특정 Application이나 DB만 장애가 발생할 수 있다.
따라서 CloudWatch와 SNS를 이용해 다음 세 영역을 함께 감시한다.
Resource Metric
+
Service Health
+
Application Log
이유
CPU와 Memory만 확인하면 EC2는 정상인데 Backend나 DB만 죽은 상황을 놓칠 수 있다.
반대로 Application 로그만 보면 EC2 자체 장애나 자원 부족을 빠르게 파악하기 어렵기 때문에 세 영역을 함께 본다.
2. 모니터링 범위
| 구분 | 대상 | 주요 감지 내용 |
|---|---|---|
| 인프라 | EC2 | Status Check 실패 |
| 시스템 자원 | EC2 OS | CPU / Memory / Disk 사용량 증가 |
| 서비스 | Frontend / Backend / AI / Redis / MySQL / PostgreSQL | Health Check 실패 |
| Application 오류 | Backend / AI / Frontend | 반복 오류 |
| 사용자 진입 계층 | Nginx | 4xx / 5xx, upstream 오류, timeout |
이유
Need U V1은 여러 서비스가 하나의 EC2에 함께 존재하므로 EC2 상태와 개별 서비스 상태를 분리해서 확인해야 장애 범위를 빠르게 좁힐 수 있다.
3. 전체 구조
EC2
├─ Frontend
├─ Backend
├─ AI Server
├─ Redis
├─ MySQL
└─ PostgreSQL
│
├─ EC2 Metrics
│ └─ CPU / Status
│
├─ CloudWatch Agent
│ └─ Memory / Disk / Nginx Log
│
├─ Service Health Check
│ └─ Custom Metric
│
└─ Application Logs
└─ CloudWatch Logs
↓
CloudWatch Alarm
↓
SNS
↓
운영 담당자 알림
+
CloudWatch Dashboard
이유
V1 규모에서 Prometheus, Grafana, ELK 등을 추가하면 별도 모니터링 시스템의 설치·운영 부담이 생긴다.
현재는 AWS 관리형 서비스인 CloudWatch와 SNS만으로 필요한 장애 감지 범위를 구성한다.
4. CloudWatch Logs 수집
운영 로그를 CloudWatch Logs로 중앙 수집한다.
| 서비스 | Log Group | 수집 방식 |
|---|---|---|
| Backend | /needu/prod/backend |
Docker awslogs |
| AI Server | /needu/prod/ai |
Docker awslogs |
| Frontend | /needu/prod/frontend |
Docker awslogs |
| Nginx | /needu/prod/nginx |
CloudWatch Agent |
Log Group 보존 기간:
14 days
Nginx는 Host에서 직접 실행되므로 다음 파일을 CloudWatch Agent로 수집한다.
/var/log/nginx/access.log
/var/log/nginx/error.log
주요 확인 대상:
Backend : ERROR, Exception, AICHAT_SERVER_UNAVAILABLE
AI : ERROR, Exception, Traceback, timeout, 5xx
Nginx : 404, 502, 504, connection refused, upstream timed out
이유
로그를 EC2 내부에만 두면 장애 시 서버에 직접 접속해야 한다.
CloudWatch Logs로 중앙 수집하면 팀원이 EC2에 접속하지 않고도 서비스별 오류를 확인할 수 있다.
Frontend Container 로그는 서버 측 로그만 포함하며, 브라우저 JavaScript Runtime Error는 브라우저 DevTools에서 별도로 확인한다.
근거
5. EC2 리소스 모니터링
5-1. EC2 Status Check
Metric : StatusCheckFailed
Statistic : Maximum
Period : 5 minutes
Threshold : >= 1
Severity : Critical
이유
StatusCheckFailed는 EC2 인스턴스 또는 기반 인프라에 문제가 발생했는지 확인하기 위한 AWS 기본 지표다.
값이 1이면 정상 상태가 아니므로 즉시 확인이 필요한 Critical 상태로 분류한다.
5-2. CPU
Warning
CPUUtilization >= 70%
5분 평균
Critical
CPUUtilization >= 90%
5분 평균
이유
순간적인 CPU Spike까지 장애로 판단하면 불필요한 알림이 발생할 수 있으므로 5분 평균을 사용한다.
70%는 자원 증가를 확인하기 위한 Warning, 90%는 성능 저하 가능성이 큰 Critical 기준으로 사용한다.
CPU 임계값은 V1 운영을 위한 초기 기준이며, 실제 부하 테스트 결과에 따라 조정한다.
5-3. Memory
EC2 기본 Metric에는 Host Memory 사용률이 포함되지 않으므로 CloudWatch Agent를 사용한다.
Metric: mem_used_percent
Warning >= 80%
Critical >= 90%
Period: 5 minutes
이유
현재 EC2에는 Backend, AI, Redis, MySQL, PostgreSQL 등이 함께 실행된다.
메모리 부족은 OOM 또는 Application/DB 종료로 이어질 수 있으므로 CPU와 별도로 감시한다.
근거
5-4. Disk
Metric: disk_used_percent
Filesystem: /
Warning >= 75%
Critical >= 85%
Period: 5 minutes
주요 증가 원인:
Docker Images
Application / Nginx Logs
MySQL
PostgreSQL
AI Catalog Data
이유
Disk가 가득 차면 로그 기록, Docker Image 저장, DB Write 등이 실패할 수 있다.
장애가 발생하기 전에 정리할 수 있도록 Warning과 Critical 단계를 분리한다.
Disk 임계값 역시 V1 초기 운영 기준이며 실제 증가 추이를 보고 조정한다.
근거
6. Service Health Check
EC2가 정상이어도 특정 Application이나 DB만 비정상일 수 있으므로 서비스별 Health Check를 수행한다.
실행 주기:
1 minute
확인 대상:
| 서비스 | 확인 방식 |
|---|---|
| Frontend | http://127.0.0.1:3000/ |
| Backend | http://127.0.0.1:8080/actuator/health |
| AI Server | http://127.0.0.1:8000/health |
| Redis | redis-cli ping |
| MySQL | mysqladmin ping |
| PostgreSQL | pg_isready |
결과는 CloudWatch Custom Metric으로 전송한다.
Namespace: NeedU/V1
FrontendHealth
BackendHealth
AIHealth
RedisHealth
MySQLHealth
PostgreSQLHealth
1 = Normal
0 = Failure
Alarm 기준:
Statistic: Minimum
Period: 1 minute
Threshold: < 1
Evaluation: 2/2
즉, 2분 연속 Health Check가 실패하면 Critical Alarm을 발생시킨다.
이유
1회 실패만으로 Alarm을 발생시키면 Application 재시작이나 순간적인 지연까지 장애로 판단할 수 있다.
따라서 1분 주기로 확인하되 2회 연속 실패한 경우 장애로 판단한다.
7. 로그 기반 오류 감지
Health Check가 정상이어도 특정 기능만 반복해서 실패할 수 있다.
현재 Backend에서 우선 감지하는 오류:
AICHAT_SERVER_UNAVAILABLE
Metric Filter:
Namespace : NeedU/V1
Metric Name : AIChatServerUnavailableCount
Metric Value: 1
Alarm:
Period : 5 minutes
Statistic : Sum
Threshold : >= 3
Severity : Warning
이유
Health Check는 서비스가 살아 있는지만 확인한다.
특정 기능 장애는 Application 로그를 통해 별도로 감지해야 한다.
일반적인 ERROR, Exception 전체를 Alarm 대상으로 사용하지 않는 이유는 정상적으로 처리되는 예외까지 포함되어 알림이 과도하게 발생할 수 있기 때문이다.
따라서 운영상 의미가 명확한 오류부터 Metric Filter로 등록한다.
근거
8. 장애 중요도
V1에서는 Warning / Critical 두 단계로 관리한다.
| 중요도 | 의미 | 주요 기준 |
|---|---|---|
| Warning | 장애 가능성이 있어 확인 필요 | CPU 70%, Memory 80%, Disk 75%, AI 연결 오류 반복 |
| Critical | 서비스 중단 또는 즉시 대응 필요 | EC2 Status 실패, CPU 90%, Memory 90%, Disk 85%, Service Health Down |
이유
단계를 너무 세분화하면 V1 규모에서는 운영 기준만 복잡해진다.
따라서 사전 확인이 필요한 상태와 즉시 대응이 필요한 상태 두 단계로 단순화한다.
9. SNS 알림
CloudWatch Alarm이 ALARM 상태로 전환되면 SNS를 통해 운영 담당자에게 전달한다.
CloudWatch Alarm
↓
SNS Topic
↓
Email
SNS Topic:
needu-v1-alerts
이유
Dashboard를 사람이 계속 보고 있을 수 없으므로, 장애 또는 위험 상태가 발생했을 때 운영 담당자가 자동으로 인지할 수 있어야 한다.
근거
10. CloudWatch Dashboard
Dashboard:
needu-v1-operations
주요 위젯:
- EC2 CPU
- EC2 Memory
- Root Disk
- Service Health
- Alarm Status
이유
Metric과 Alarm을 각각 찾아보는 대신 인프라와 서비스 상태를 한 화면에서 확인하여 장애 범위를 빠르게 파악하기 위해 사용한다.
근거
11. 장애 발생 시 대응
SNS 알림 수신
↓
CloudWatch Dashboard 확인
↓
Resource / Service Health 확인
↓
발생한 Alarm 확인
↓
관련 CloudWatch Logs 확인
↓
Application / DB / Nginx 상태 확인
↓
원인 조치
↓
Health Metric / Alarm 정상 복구 확인
예를 들어 Backend에서 AICHAT_SERVER_UNAVAILABLE가 반복되면:
Backend 로그 확인
↓
AIHealth 확인
↓
AI 로그 확인
↓
AI Server 장애인지
Backend ↔ AI 연결 문제인지 확인
이유
하나의 로그나 하나의 Metric만으로 원인을 단정하지 않고, Resource → Health → Log를 함께 확인해야 실제 장애 지점을 빠르게 구분할 수 있다.
12. 팀원 조회 권한
팀원은 CloudWatch의 Dashboard, Metric, Alarm, Logs를 조회할 수 있도록 ReadOnly 권한으로 관리한다.
운영 원칙:
- 공용 계정 대신 사람별 IAM User 사용
- CloudWatch 조회 권한만 제공
- 운영 설정 변경 권한은 제공하지 않음
- EC2 직접 접근 권한은 별도 관리
- Console 조회 목적이라면 Access Key를 생성하지 않음
- MFA 사용 권장
이유
장애 확인을 위해 모든 팀원에게 EC2나 CloudWatch 수정 권한을 줄 필요는 없다.
조회와 변경 권한을 분리해 실수로 운영 설정이 변경되는 위험을 줄인다.
근거
13. V1에서 제외한 항목
V1에서는 다음 별도 모니터링 스택을 추가하지 않는다.
Prometheus
Grafana
Loki
ELK / OpenSearch
분산 Trace
복잡한 APM
Kubernetes Monitoring
이유
현재는 단일 EC2 기반의 초기 서비스이므로 별도 모니터링 스택을 운영하는 비용과 복잡도가 더 크다.
CloudWatch만으로 필요한 Resource, Health, Log, Alarm을 우선 구성하고 V2/V3 확장 시 다시 검토한다.
14. 참고 자료
- Amazon EC2 - CloudWatch metrics available for instances
- Amazon CloudWatch - Metrics collected by the CloudWatch Agent
- Amazon CloudWatch Logs - Creating metrics from log events using filters
- Amazon CloudWatch Logs - Filter pattern syntax
- Amazon CloudWatch - Using CloudWatch alarms
- Amazon CloudWatch - Notifying users on alarm changes
- Amazon CloudWatch - Using CloudWatch dashboards
- AWS IAM - Security best practices