개요
기존 모니터링 시스템은 HTTP 상태와 파일 시스템 상태를 점검하고, 이메일 기반 단일 알림만 제공하는 구조였다. 이를 개선하여 AWS Connect(전화) / SNS(SMS) / Slack / SES(Email) 4채널 병렬 알림 구조인 AlertHub로 확장했다.
설계 목표
- 장애 발생 시 즉각 대응 가능 (전화 알림)
- 알림 채널 다변화 (전화 / SMS / Slack / Email)
- YAML 기반으로 유연한 설정 변경
- 운영 환경에서도 확장 가능한 구조
전체 아키텍처
[모니터링 시스템]
├─ HTTP Monitor
├─ Folder Monitor
└─ Batch / API Runner
↓
[문제 감지]
↓
[AlertHub (통합 알림 레이어)]
↓
├─ AWS Connect (전화)
├─ AWS SNS (SMS)
├─ Slack API
└─ AWS SES / SMTP (Email)
기존 "이메일 단일 알림"에서 멀티 채널 병렬 알림 구조로 확장했다.
모니터링 트리거 구조
HTTP 모니터링
HTTP 응답 코드가 2xx가 아니거나, 응답 시간이 3초 이상인 경우 장애로 판정한다.
if (responseCode < 200 || responseCode >= 300 || responseTime > 3000) {
alertHub.notify(service, alertConfig);
}파일 시스템 모니터링 (FolderMonitor)
파일이 특정 시간 이상 유지(적체)되면 장애로 간주한다.
if (now.isAfter(lastModified + duration)) {
alertHub.notify(service, alertConfig);
}AlertHub 채널 구현
1. AWS Connect (전화 알림)
StartOutboundVoiceContact API를 사용하여 장애 발생 시 자동 음성 콜을 발신한다.
StartOutboundVoiceContactRequest request =
StartOutboundVoiceContactRequest.builder()
.contactFlowId(contactFlowId)
.instanceId(instanceId)
.queueId(queueId)
.destinationPhoneNumber(phoneNumber)
.build();
connectClient.startOutboundVoiceContact(request);2. SMS (AWS SNS)
서울 리전 SMS 미지원으로 **도쿄 리전(ap-northeast-1)**을 사용한다. Sandbox 환경에서는 검증된 번호(최대 10개)에만 발송 가능하다.
3. Slack 알림
YAML 설정 기반으로 Bot Token과 채널 ID를 지정하여 1분 단위 실시간 알림을 전송한다.
notification:
by: slack
token: xoxb-xxxx-xxxx-xxxx
channel: C06209CHQ4W4. Email (AWS SES)
기존 사내 SMTP(비즈메카)에서 발생하던 지연 및 AWS 환경 차단 문제를 AWS SES로 전환하여 해결했다.
YAML 기반 알림 제어
코드 수정 없이 설정만으로 알림 채널, 실행 시간, 조건을 변경할 수 있다.
notificationMethod: ["call", "sms", "email", "slack"]
time: "0 0/1 * * * ?"
conditions:
- 'total == 0'
- 'fail > 100'
- 'pending > 1000'스케줄링
Quartz Scheduler 기반으로 Cron 표현식을 사용하여 모든 모니터링/알림 로직을 자동화했다.
| Cron 표현식 | 실행 주기 | 용도 |
|---|---|---|
0 0/1 * * * ? | 매 1분 | 실시간 HTTP/파일 모니터링 |
0 0 0 * * ? | 매일 00:00 | 일일 리포트 생성 |
0 0 9-18 * * ? | 업무 시간대 | 특정 시간대 반복 점검 |
주요 설계 포인트
- 멀티채널 Fail-safe: 단일 채널 장애 시에도 나머지 채널로 알림 전달 보장
- 설정 기반 아키텍처: YAML로 서비스/알림/스케줄 분리, 코드 수정 없이 운영 제어
- ServiceLoader 확장 구조: Reflection 기반 서비스 생성으로 새 모니터 추가 용이
- 실시간 + 배치 혼합: FileEventRunner(실시간) + Quartz Scheduler(배치) 병행
문제 해결
Spring Bean vs 수동 Registry 충돌
ServiceRegistry는 수동 객체 관리, Spring은 Bean 컨테이너 관리로 충돌 발생. ApplicationContext에서 Bean을 직접 조회하거나 직접 인스턴스를 생성하여 해결했다.
AWS 인증 보안 처리
Access Key 코드 포함 문제를 YAML + 환경변수 분리, secret 파일 .gitignore 등록으로 해결했다.
AWS SMS Sandbox 제한
서울 리전 미지원을 도쿄 리전 우회로 해결하고, 검증된 번호를 사전 등록하여 운영했다.
결과
- 장애 대응 속도 향상 (전화 알림으로 야간/주말 즉시 인지)
- 운영 가시성 향상 (Slack + Email로 팀 전체 장애 상황 공유)
- 확장성 확보 (YAML 기반 구조로 새 모니터/채널 추가 용이)
- 안정성 향상 (멀티채널 Fail-safe로 알림 누락 방지)
상세 내용은 AlertHub 프로젝트 페이지에서 확인할 수 있습니다.