백엔드 모니터링 구성 및 선택 이유
- AWS 리소스(EC2, RDS, Lambda 등) 및 애플리케이션을 모니터링하고 알람을 설정할 수 있는 AWS 기본 서비스
- 로그 수집 및 메트릭, 알람, 대시보드 등 통합된 운영이 가능
- EC2 인스턴스 내부의 로그 파일 및 시스템 메트릭(CPU, Memory 등)을 수집
- logback 으로 남긴 애플리케이션 로그 파일을 CloudWatch로 전송
- CloudWatch Logs에 수집된 로그를 SQL 유사 문법으로 쿼리 가능
- 특정 에러, URI, 응답 시간 등을 기준으로 빠르게 필터링 가능
- 알람 발생 시 팀 커뮤니케이션 채널로 실시간 전송
- 서비스 장애 발생 시 빠른 대응 유도
현재 프로젝트에서는 AWS CloudWatch를 주요 모니터링 도구로 채택하였습니다.
모니터링 도구 비교 및 선택 사유는 다음과 같습니다.
Prometheus
- 애플리케이션 및 인프라 성능 모니터링과 경고 알림을 위한 오픈소스 시스템
- 특히 시계열 데이터(Time Series Data) 수집과 분석에 특화되어 있음
Grafana
- 시계열 기반 메트릭 데이터를 시각화하기 위한 오픈소스 대시보드
- 다양한 데이터 소스를 연결하여 고도화된 시각화가 가능
장점
- 시스템 관점(CPU, Memory, Disk I/O 등)의 지표 시각화에 특화됨
- Pull 방식으로 동작하므로, Exporter만 노출하면 자동 수집 가능
- 대시보드의 커스터마이징 자유도가 높고 고급 시각화 지원
- 자체 호스팅 시 비용이 들지 않음
단점
- Exporter 설치 및 Prometheus 서버, Grafana 인스턴스 구성이 필요
- 초기 설정의 복잡도가 높아 러닝 커브가 높음
- AWS 서비스와 기본 통합되지 않아, Cloud 환경 연동 시 추가 작업 필요
- AWS에서 제공하는 통합 모니터링 서비스로, 로그 수집, 지표 시각화, 알람 설정 등을 한 곳에서 처리 가능
- EC2, RDS, Lambda, ECS 등 AWS 리소스와 기본적으로 연결되어 설정 없이 바로 사용할 수 있음
장점
- AWS 리소스와의 기본 통합으로 별도의 복잡한 설정 없이 바로 모니터링을 시작할 수 있음
- CloudWatch Dashboard를 통해 메트릭, 로그, 알람을 한 화면에서 통합 시각화 가능
- 상태 기반 알람 발생 시, Slack 또는 Discord로 실시간 알림 전송 가능
단점
- 로그 수집, 저장, 메트릭 생성, 쿼리 분석 등에 따른 비용이 누적될 수 있음
- 대시보드의 표현력이나 고급 필터링 기능이 제한되어 있어, 복잡한 시각화에는 다소 한계가 있음 (Grafana 대비)
최종적으로 AWS CloudWatch를 선택한 이유는 다음과 같습니다.
- 러닝 커브가 낮고, 초기 설정이 간단해 빠르게 도입 가능
- 프로젝트 요구사항 항목인 Health Check, Application Log, Response Time 등 주요 항목을 모두 수집 가능
- CloudWatch Dashboard를 통해 메트릭, 로그, 알람을 한 화면에서 통합 시각화 가능
- AWS 리소스와 기본 통합되어 있어 Exporters 설치 없이도 메트릭과 로그 수집이 가능함
- 자체 호스팅 환경 없이 운영할 수 있어 추가 인프라 구성 및 유지보수 부담이 적음
- 운영 비용과 복잡도를 고려했을 때, 소규모~중간 규모의 서비스에 적합
- CPU 사용량
- 메모리 사용량
- 디스크 사용량
- 애플리케이션 로그
- EC2 인스턴스 내부 로그를 CloudWatch Agent가 수집
- JSON 포맷 기반 구조화 로그를 사용하여, 필터링 및 분석 효율성 확보
{
"timestamp": "2025-08-07 03:07:00.558",
"level": "INFO",
"message": "API 처리 성공",
"traceId": "d6b7e401",
"duration": "9ms",
"method": "GET",
"uri": "/region-categories",
"httpStatus": "200"
}- 에러 로그 조회
parse @message '"timestamp":"*"' as timestamp
| parse @message '"level":"*"' as level
| filter level = "ERROR"
| fields message, uri
| sort timestamp desc
| limit 20알람 전송은 CloudWatch Alarm + SNS + Lambda + Discord Webhook으로 구성되어 있습니다.
- CPU 사용량 70% 이상
- 서버 과부하로 응답 지연·장애가 발생하기 전에 미리 감지하기 위함
- 메모리 사용량 70% 이상
- 메모리 부족 시 OOM Killer로 인해 프로세스가 강제 종료될 수 있어, 서비스 다운을 예방하기 위함
- ERROR 레벨 로그 발생 시
- CPU 사용량 70% 이상
- 메모리 사용량 70% 이상
- ERROR, WARN 레벨 로그 발생 시
- 개발 단계에서는 WARN도 잠재적 버그를 의미하므로 운영 전 발견, 수정하기 위함
📈 지표 알람 발생
🕒 시간: 2025-08-26 02:01:13
🏷 알람: turip-dev-memory
📊 메트릭: Turip/dev/MemoryUtilization
🔗 바로가기: https://ap-northeast-2.console.aws.amazon.com/cloudwatch/home?region=ap-northeast-2#alarmsV2:alarm/turip-dev-memory
📝 사유: Threshold Crossed: 1 out of the last 1 datapoints [70.44120047771659 (25/08/25 16:56:00)] was greater than or equal to the threshold (70.0) (minimum 1 datapoint for OK -> ALARM transition).🚨 WARN 로그 발생
🕒 시간: 2025-08-28 19:31:34
📂 로그 그룹: turip-dev
📑 로그 스트림: spring-dev-log
🔗 바로가기: https://ap-northeast-2.console.aws.amazon.com/cloudwatch/home?region=ap-northeast-2#logsV2:log-groups/log-group/turip-dev/log-events/spring-dev-log)
💬 메시지: 컨텐츠를 찾을 수 없습니다.
💥 원인: turip.common.exception.custom.NotFoundException: 컨텐츠를 찾을 수 없습니다.