서버가 실행된 후 발생하는 모든 일을 기록하고, 문제가 생겼을 때 즉시 알림을 받는 시스템을 구축하는 방법이다.
1. CloudWatch Logs: 로그 통합 관리
서버 내부의 파일(예: app.log)에 로그를 남기면 서버가 삭제될 때 로그도 사라진다. 따라서 모든 로그는 CloudWatch Logs로 전송해야 한다.
수집 방법
- ECS/Lambda: 별도 설정 없이
console.log나System.out.println등을 호출하면 자동으로 CloudWatch로 전송된다. (ECS는awslogs드라이버 설정 필요) - EC2: 서버에 CloudWatch Agent를 설치하여 특정 파일 경로의 로그를 실시간으로 가져와 올리도록 설치해야 한다.
실무 팁: 로그 레벨 관리
- 운영 환경:
INFO레벨 이상만 기록하여 비용을 아끼고 로그량을 줄인다. - 구조화된 로그 (Structured Logging): 단순 텍스트보다 JSON 형식으로 로그를 남기면 CloudWatch Logs Insight에서 특정 필드(예:
userId,responsetime)로 쿼리하고 통계를 내기 훨씬 쉬워진다.
2. CloudWatch Alarms: 장애 감지기
로그만 쌓아두는 것은 의미가 없다. 특정 조건이 만족되면 자동으로 움직일 수 있어야 한다.
주요 알람 설정 지표
- Error Log Count: 로그에
ERROR또는Exception이라는 단어가 5분간 10번 이상 등장할 때 - HTTP 5XX Count: 로드밸런서(ALB)에서 응답 코드 500번대가 급증할 때
- Latency (지연 시간): 응답 속도가 평균 2초 이상으로 느려질 때
- CPU/Memory: 서버 자원이 부족하여 곧 뻗을 것 같을 때 (보통 80% 이상)
3. 실무 알림 연동: Slack(슬랙) 알림 구축
장애 발생 시 메일은 확인이 늦는다. 실시간 채팅 도구(Slack, Microsoft Teams 등)와 연동하는 것이 정석이다.
아키텍처 흐름
[CloudWatch Alarm] → [SNS (Simple Notification Service)] → [AWS Chatbot / Lambda] → [Slack 채널]- SNS 주제 생성: 알림을 전달받을 ‘우체통’을 만든다.
- AWS Chatbot 설정: SNS에 메시지가 오면 슬랙으로 예쁘게 포멧팅해서 보내주는 역할을 한다 (이 방식이 제일 간단하다)
4. 로그 보존 및 비용 최적화
- 보존 정책 (Retention Policy): 기본은 ‘영구 보관’이다. 로그가 쌓이면 비용이 상당하므로 운영 로그는 30~90일, 개발 로그는 7일 정도로 보존 기간을 설정하는 것이 좋다.
- Log Insignts: 장애 발생 시 수백만 줄의 로그에서 범인을 찾을 때 SQL과 유사한 문법으로 빠르게 검색할 수 있다.
5. 체크리스트
- 중앙 집중화: 모든 서버 로그가 CloudWatch Logs 한 곳으로 모이는가?
- 알람 설정: 서비스의 핵심 API(로그인, 결제 등)에 대해 실패 알람이 걸려있는가?
- 알람 수신: 슬랙 알림이 팀원들이 모두 있는 채널에 정확히 도달하는가?
- 로그 포맷: 로그가 JSON 형태이거나 검색하기 쉬운 일정한 형식을 갖추었는가?
- 매트릭 모니터링: 로그뿐만 아니라 서버의 하드웨어 상태(CPU, Memory) 모니터링 대시보드가 있는가?
백엔드 개발자를 목표로 공부하는 대학생