지금까지(OOM 디버깅기, systemd 자동 복구) 서버가 죽어도 스스로 복구되도록 만들었다. 근데 곰곰이 생각해보니 아직 빈 구멍이 하나 있었다 — 자동 복구가 안 되는 종류의 장애(예: AWS 인스턴스 자체의 상태 이상)가 나면, 나는 여전히 "우연히 콘솔에 들어가봐서" 알게 되는 구조였다. 실제로 이번 장애도 며칠 지나서야 사이트에 들어가봤다가 발견한 거였다.
그래서 문제가 생기면 이메일로 바로 알림이 오도록 CloudWatch 알람을 설정했다.
어떤 지표를 볼 것인가
EC2 상태 검사 관련 지표는 이렇게 나뉘어 있다.
| 지표 | 의미 |
|---|---|
| StatusCheckFailed_System | AWS 인프라(하드웨어/네트워크) 문제 |
| StatusCheckFailed_Instance | 인스턴스 내부(OS, 메모리 등) 문제 |
| StatusCheckFailed_AttachedEBS | 연결된 디스크 문제 |
| StatusCheckFailed | 위 세 개 중 하나라도 실패하면 1 |
원인을 세밀하게 구분하고 싶으면 개별 지표에 알람을 걸 수도 있지만, 개인 프로젝트 규모에서는 어떤 원인이든 일단 다 잡아내는 게 우선이라 접미사 없는 StatusCheckFailed 하나로 설정했다.
알람 생성
CloudWatch 콘솔 → Alarms → Create alarm
-
지표 선택: EC2 → 인스턴스별 지표(Per-Instance Metrics) → 해당 인스턴스의
StatusCheckFailed선택 -
조건:
-
통계: 최대
-
기간: 5분
-
임계값:
StatusCheckFailed >= 1
-
알림 설정: 새 SNS 주제 생성 → 이메일 주소 등록
-
알람 이름 지정 → 생성
헷갈렸던 것: "5분마다 메일이 오는 거야?"
처음엔 "기간을 5분으로 하면 5분마다 메일이 스팸처럼 오는 거 아닌가" 싶었는데, 그게 아니었다.
- CloudWatch는 5분마다 지표를 확인한다 (평가 주기)
- 근데 이메일은 알람의 "상태가 바뀔 때"만 온다 — 정상(OK) → 이상(ALARM)으로 바뀌는 순간 딱 한 번
즉 장애가 3시간 지속돼도 메일은 시작될 때 한 통만 온다 (반대로 "복구됐다"는 알림까지 받고 싶으면 OK 상태 전환에 대한 알림도 별도로 설정해야 한다). 처음 설정할 때 이 부분이 헷갈릴 수 있으니 참고하면 좋을 것 같다.
삽질: 구독이 "비활성화됨"으로 떴다
알람을 만들고 나면 등록한 이메일로 구독 확인(Subscription Confirmation) 메일이 오고, 그 안의 링크를 눌러야 실제로 알림을 받을 수 있다. 그런데 나는 분명 확인했다고 생각했는데, 나중에 다시 보니 이런 메일이 와 있었다.
Your subscription to the topic below has been deactivated:
arn:aws:sns:ap-northeast-2:XXXXXXXXXXXX:ec2-status-alerts
- 구독이 비활성화됐다는 알림이었다. 이대로면 알람이 울려도 메일이 안 온다. SNS 콘솔에서 Topics → 해당 주제 → Subscriptions 탭에 들어가서 상태를 확인하고, 비활성 상태면 삭제 후 재구독해야 한다. 재구독하고 이번엔 메일 안의 "Confirm subscription" 링크만 정확히 눌렀더니 상태가 "확인됨"으로 바뀌었다.
(정확한 원인은 못 찾았지만, 메일 클라이언트나 보안 스캐너가 메일 안의 다른 링크를 자동으로 클릭하면서 벌어지는 경우가 있다고 한다. 확인 메일을 열 때는 이 점을 염두에 두면 좋을 것 같다.)
결과
나의 메일@메일.com EMAIL 확인됨
이제 인스턴스 상태 검사가 실패하면 콘솔에 들어가보지 않아도 이메일로 바로 알 수 있다. 테스트해보고 싶으면 CloudWatch 콘솔에서 알람을 선택하고 Actions → Test alarm으로 강제로 알람을 울려서 실제 메일이 오는지 확인해볼 수 있다.
회고
- 자동 복구(systemd)만으로는 부족하고, "복구가 안 되는 상황"까지 대비한 능동적인 알림 체계가 있어야 진짜 안심할 수 있다는 걸 깨달았다.
- 구독 확인처럼 사소해 보이는 단계 하나를 놓치면 알람 자체가 무용지물이 된다. 설정하고 끝이 아니라, 테스트까지 해봐야 진짜 설정이 끝난 것이다.
- 비용 걱정 없이(프리티어 범위 내) 개인 프로젝트에도 이 정도 모니터링 체계는 갖춰두는 게 좋겠다는 생각이 들었다. 장애를 막을 수는 없어도, 장애를 빨리 아는 것만으로 대응 속도가 완전히 달라진다.
