EC2 Monitoring System
Projects | | Links:
216대 서버를 5분마다 자동 감시하고, 장애 시 Slack + 전화 자동 발신 온콜 체계를 갖춘 서버리스 모니터링 시스템입니다.
프로젝트 기여도 80% (설계·개발·운영 수행)
1. Overview
216대의 EC2 서버를 실시간으로 모니터링하고, 장애 발생 시 5분 이내에 자동 알람 + 전화 발신까지 수행하는 서버리스 모니터링 시스템을 설계·구축했습니다.
2. Background — 왜 만들었는가
실제 장애 사례 (2026.03.05)
AWS 물리 호스트 장애로 운영 서버 1대가 응답 불가 상태에 빠졌으나, DevOps 파트의 장애 인지가 6시간 이상 지연된 사건이 발생했습니다.
| 시간 (KST) | 내용 |
|---|---|
| 02:15 | EC2 System Status Check Failed (AWS 물리 호스트 장애) |
| 02:20 | NLB 헬스체크 실패 → 자동 트래픽 차단 (서비스 영향 없음) |
| 02:20 | AWS system-reboot 예약 이메일 수신 |
| 08:31 | DevOps 파트 장애 인지 (6시간 16분 후) |
서비스 자체는 NLB 이중화 덕분에 영향이 없었으나, 인스턴스 장애를 빠르게 인지하지 못한 것이 문제로 지적되었습니다.
근본 원인
- EC2 상태 변화에 대한 자동 알람 체계 부재
- SSM 연결 끊김, Target Group Unhealthy 등에 대한 감시 없음
- 야간/주말 장애 시 담당자에게 통보할 온콜 체계 없음
이 사건의 개선책으로 EC2 모니터링 시스템을 설계·구축하게 되었습니다.
3. Problem Statement
| 문제 | 영향 |
|---|---|
| 216대 서버 상태를 수동으로 확인 | 장애 인지까지 수십 분~수 시간 소요 |
| 장애 알림 체계 부재 | 사용자 신고 후에야 인지 |
| 온콜 체계 없음 | 야간/주말 장애 대응 불가 |
4. Architecture
EC2 Monitoring Diagram
- Lambda + EventBridge: 5분 주기 실행, 서버리스로 자체 장애 없음
- S3 상태 관리: 이전 상태와 비교하여 5분 이상 지속된 문제만 알람 (오알람 방지)
- 스누즈 기능: Slack 버튼 클릭으로 15분간 알람 차단 (알람 피로 방지)
- 심각도 분리: WARNING은 Slack만, CRITICAL은 Slack + 전화 자동 발신
5. 모니터링 항목
핵심 모니터링 (장애 사례 기반)
| # | 항목 | 방식 |
|---|---|---|
| 1 | EC2 Instance Status | EC2 API (running 여부) |
| 2 | SSM 연결 상태 | SSM API (online 여부) |
| 3 | Target Group Health | ELB API (healthy 여부) |
추가 기능 (운영 중 확장)
| # | 항목 | 방식 |
|---|---|---|
| 4 | Disk 사용량 | SSM RunCommand (80%+ 알람) |
| 5 | Batch 실행 여부 | S3 마커 파일 확인 |
| 6 | 인증서 만료일 | 만료 D-30 사전 알람 |
6. Key Results
| 지표 | Before | After |
|---|---|---|
| 장애 인지 시간 | 수십 분~수 시간 (위 사례: 6시간+) | 5분 이내 |
| 모니터링 대상 | 수동 확인 가능한 범위 | 216대 전체 |
| 야간/주말 대응 | 불가 | 전화 자동 발신 + 온콜 |
7. Used Skills
- AWS Lambda (Python)
- Amazon EventBridge
- Amazon S3 (상태 관리)
- SSM Parameter Store
- API Gateway (스누즈 엔드포인트)
- Slack Webhook + 전화 자동 발신
