01 / 07
개요 & 아키텍처
기존 단일 이메일 알림의 한계, 멀티채널 AlertHub 설계 목표, 전체 아키텍처 구조
Background
기존 시스템의 한계
기존 모니터링 시스템은 HTTP 상태와 파일 시스템 상태를 점검하고, 이메일 기반 단일 알림만 제공하는 구조였다.
단일 채널
이메일만 사용하여 장애 인지 지연
즉각 대응 불가
야간/주말 이메일 확인 어려움
설정 변경 어려움
알림 조건 변경 시 코드 수정 필요
Goal
AlertHub 설계 목표
즉각 대응
장애 발생 시 전화 알림으로 즉시 인지 가능
채널 다변화
전화 / SMS / Slack / Email 4채널 병렬 알림
유연한 설정
YAML 기반으로 코드 수정 없이 설정 변경
확장 가능 구조
운영 환경에서도 새로운 모니터 추가 용이
Architecture
전체 아키텍처
Before
After — AlertHub
Detail Flow
1. 모니터링 소스
2. AlertHub (통합 알림 레이어)
3. 알림 채널 (병렬 발송)
AWS Connect
음성 전화
AWS SNS
SMS 문자
Slack API
채널 메시지
AWS SES
이메일
4. 감사 로그 분석 (장애 원인 추적)
관리 이벤트 + S3 데이터 이벤트를 장기 보존하여, 장애 원인 추적 및 보안 감사에 활용
Scheduling
EventBridge Scheduler 현황
| 스케줄 | 대상 | 주기 |
|---|---|---|
| Config 보고서 | AWSConfigRulesMailProvider | 평일 매일 09:00 KST |
| Windows 서버 점검 | CheckWindowSvrAppStatus | 5분 간격 |
| ECS Scale Up | ecs-service-scale-up | 매일 08:00 KST |
| ECS Scale Down | ecs-service-scale-down | 매일 18:00 KST |
Lambda Functions
모니터링 Lambda 함수 목록
| Lambda | 트리거 | 알림 채널 |
|---|---|---|
| AWSConfigRulesMailProvider | Scheduler (평일 09:00) | SES → Email |
| CheckWindowSvrAppStatus | Scheduler (5분 간격) | SES + Slack + SMS |
| sns-forward-to-tokyo | SNS | → Tokyo SNS → SMS |
| SendSlackNotification | SNS | Slack Webhook |
| health-ecs-email-notify | EventBridge Rule | SES → Email |
Summary
단일 이메일 기반 모니터링 시스템을 AWS Connect / SNS / Slack / SES 기반의 멀티채널 AlertHub로 확장하여, 장애 대응 속도와 운영 안정성을 크게 향상시켰습니다. EventBridge Scheduler와 Lambda 함수를 조합하여 Config 보고서, Windows 서버 점검, ECS 스케줄링까지 자동화했습니다. CloudTrail + Athena 기반 감사 로그 분석 환경을 구축하여 장애 원인 추적과 보안 감사까지 포괄합니다.