들어가며
모니터링은 크게 애플리케이션 레벨과 인프라 리소스 레벨로 나눌 수 있다.
•
애플리케이션 모니터링은 로깅이나 비즈니스 지표 중심으로, 예를 들어 어떤 데이터가 얼마나 저장됐는지, 데이터 정합성이 맞는지 추적한다.
•
인프라 모니터링은 서버, 데이터베이스, 네트워크 등 시스템 리소스 상태를 추적해 장애나 성능 저하를 빠르게 감지하는 데 초점을 둔다.
회사에서는 애플리케이션 로그는 AWS OpenSearch를 활용하고, 데이터 지표는 Airflow 배치로 수집해 슬랙 알림으로 받아보고 있다.(ex. 어제 실행된 아테나 쿼리 통계, DMS 데이터 정합성 등)
인프라 모니터링 역시 Airflow 배치로 CloudWatch 메트릭을 조회해 리포트 생성 후 슬랙에 발송하는 방식을 사용하고 있었다.
하지만 기존 방식은 단순히 2시간마다 지난 24시간치를 알람 형태로 받다보니, 실시간성이 떨어지고 장애 대응 목적으로 사용하기도 한계가 있었다.
백엔드 챕터 전체가 Grafana 대시보드 중심의 모니터링을 원칙으로 하고 있기 때문에, 데이터팀도 이를 맞추어 인프라 모니터링 체계를 Grafana로 이전했다.
Grafana란?
Grafana는 다양한 데이터 소스(Prometheus, CloudWatch 등)에서 수집한 시계열 데이터를 시각화하고 알람까지 설정할 수 있는 오픈소스 모니터링 도구다. 단순한 리포트 뷰어가 아니라, 운영자가 원하는 방식으로 지표를 가공·시각화할 수 있어 실시간 장애 대응에 널리 활용된다.
이번 글에서는 데이터팀이 Grafana 대시보드로 전환하면서 어떤 인프라와 지표를 모니터링했는지, 그리고 Grafana를 어떻게 활용하고 있는지를 정리하려 한다.
모니터링 대상 인프라와 핵심 지표
데이터팀에서 관리하는 인프라 서비스는 많지만, 그중 운영 안정성에 직접적인 영향을 주는 핵심 인프라 다섯 가지를 우선적으로 모니터링 대상으로 선정했다.
•
MWAA (Airflow Managed 서비스)
•
EC2 서버
•
ECS 서버
•
RDS 데이터베이스
•
DMS (Database Migration Service)
핵심 지표는 기본적으로 CPU, Memory, Storage를 공통으로 두고, 서비스별 특성에 맞춘 지표를 추가로 수집했다. 예를들면, RDS는 커넥션 개수나 Read/Write I/O 지표를 추가하거나, DMS는 CDC 지연 시간, 버퍼 사용량 등을 포함시켰다.
또한 지표들을 조합해 파생지표를 만들 수도 있다. Airflow는 태스크 성공/실패로 성공/실패율을 만들거나 평균 실행시간 같은 지표를 만들어 활용 가능하다.
인프라별 지표
인프라 | 주요 지표 | 설명 |
MWAA | - Cluster CPU & Memory
- Meta DB CPU & Memory
- Task 상태: Queued, Running
- Task 성공/실패 건수 & 실행시간
- DAG 개수 | Airflow 태스크 및 리소스 상태를 종합적으로 확인 |
EC2 | - CPU, Memory, Storage
- Network In/Out, Packet 수
- EBS Read/Write Bytes, Ops, Balance | 컨테이너 실행 상태 및 자원 사용률 추적
CloudWatch Agent 설치 필요 |
ECS | - CPU, Memory (avg/max/min)
- Task 개수 | 컨테이너 실행 상태 및 자원 사용률 추적 |
RDS | - CPU, Memory, Storage
- Connection 수
- Read/Write Latency, Throughput, IOPS | DB 병목 현상 파악 및 연결 과부하 감지 |
DMS | - 인스턴스 CPU & Memory
- Swap Usage (메모리 부족 여부)
- CDC Latency (Source/Target)
- CDCChanges (디스크·메모리 버퍼)
- CDC 이벤트 Throughput (Row 수, Bandwidth) | 실시간 CDC 파이프라인의 지연 및 병목을 진단 |
Garafana와 연동
Grafana에서는 데이터소스를 연결해 메트릭을 가져올 수 있다.
ECS, RDS, DMS
•
CloudWatch 데이터 소스에 연결하면 별도 설정없이 바로 사용가능
EC2와 CloudWatch Agent
EC2는 기본 메트릭만으로는 메모리·디스크 사용량을 알 수 없다.
•
CloudWatch는 기본적으로 하이퍼바이저(AWS 가상화 계층) 에서 수집 가능한 지표만 제공하기 때문
•
메모리나 디스크 사용률은 OS 내부 정보이기 때문에 기본 제공이 되지 않음
•
따라서 인스턴스 안에서 직접 수집하는 CloudWatch Agent 설치 필요
MWAA와 Prometheus Exporter
MWAA는 일반적인 EC2나 RDS처럼 CloudWatch 메트릭을 바로 가져올 수 없다.
•
일부 메트릭은 AWS/MWAA 네임스페이스, 일부는 AmazonMWAA 네임스페이스로 제공
•
이는 AWS 서비스별 메트릭 네임스페이스 정리 과정에서 생긴 차이로, 동일한 서비스지만 분리된 네임스페이스로 노출되기 때문에 Config에서 둘 다 정의해야 한다.
config.yml 예시
위 두 방식은 Grafan의 Cloudwatch 연결에서 바로 추출할 수 없기 때문에 Prometheus + CloudWatch Exporter를 통해 직접 네임스페이스와 dimension을 정의해 메트릭을 추출해야 한다.
Prometheus란?
Prometheus는 시계열 데이터 수집/저장 시스템이다.
•
다양한 Exporter를 통해 메트릭을 수집
•
시계열 DB에 저장하고 PromQL로 쿼리 가능
•
Grafana와 결합하면 실시간 대시보드와 알람을 구성할 수 있음
즉, CloudWatch Exporter로 API를 통해 Prometheus로 메트릭을 수집하고, Grafana에서 불러와 활용하는 구조라고 이해하면 된다.
Grafana에서의 구현
Grafana에서는 수집된 메트릭을 단순히 보여주는 것에 그치지 않고, 원하는 방식으로 가공하고 시각화할 수 있다.
•
PromQL 기반 쿼리: 평균(mean), 마지막 값(last), 비율(rate) 등 다양한 집계를 적용
•
시각화 커스터마이즈: 색상 변경, 단위(unit) 맞춤(%, ms, MB 등)으로 직관적인 표현 가능
•
변수(variables): 대시보드에서 공통으로 사용할 변수 지정가능, 각 시각화 안에서 이 변수를 지정해 ($변수명) 조건에 변수가 들어가게 할 수 있음
◦
활용 예시: EC2 인스턴스는 기본적으로 i-xxxxxxxx 형식의 ID만 표시되어 id만 보고 어떤 인스턴스인지 파악 어려움
◦
변수에 instance_id와 이름을 매핑해두면 상단에서 이름을 선택해 해당 인스턴스 지표를 불러올 수 있음
자세히보기
•
대시보드 템플릿화: 여러 인스턴스에 동일한 구조를 적용해 공통 대시보드를 구성할 수 있음
대시보드의 제작 난이도가 있는 만큼, 공식 사이트와 커뮤니티에서 공유되는 다양한 대시보드 템플릿을 참고해 시작하면 훨씬 수월하다.
대시보드 구성 예시 - MWAA
데이터팀에서 구성한 MWAA 대시보드를 예로 들어보자.
1.
요약 지표 (Stat 패널)
•
상단에 DAG 개수, 최근 Task 성공/실패 건수 숫자 지표를 배치해 한눈에 파악할 수 있도록 했다.
2.
파생 지표
•
task 실패 비율
sum(sum_over_time(amazonmwaa_task_instance_failures_sum[$__range]))
/
(sum(sum_over_time(amazonmwaa_task_instance_failures_sum[$__range]))
+
sum(sum_over_time(amazonmwaa_task_instance_successes_sum[$__range]))
) * 100
SQL
복사
•
평균 실행 시간
avg(
avg_over_time(amazonmwaa_task_instance_duration_average[$__range])
)
SQL
복사
•
Task 대기/실행 비율
sum(amazonmwaa_queued_tasks_maximum)
/
(sum(amazonmwaa_running_tasks_maximum) + 1)
SQL
복사
3.
리소스 모니터링
MWAA가 제공하는 스케줄러, 워커, 웹서버의 CPU & Memory
MetaDB의 CPU & Memory
이렇게 MWAA 대시보드를 구성하니, 현재 운영 중인 DAG 개수, Task 성공/실패 건수, 평균 실행 시간, 워커 리소스 상태를 한눈에 확인할 수 있게 되었다.
기존에는 CloudWatch 리포트를 배치로 받아보며 장애 징후를 놓치기 쉬웠지만, 지금은 Grafana 대시보드에서 실시간으로 상황을 파악할 수 있어 훨씬 빠르게 대응할 수 있다.
알림 기능
Grafana는 알람(Alerts) 기능을 통해 특정 조건 만족시 Slack으로 알림을 보낼 수 있다.
설정 방식
•
각 대시보드 패널에서 알림 규칙을 추가하거나, Alerting 메뉴에서 중앙 관리 가능
•
예: EC2 메모리 사용률이 60% 이상 지속되면 Slack으로 알림 발송
메모리가 60이상 넘어가면 알림 규칙
효과
•
여러 서비스 콘솔을 직접 찾아가지 않고, 한 곳에서 필요한 지표를 모아 볼 수 있어 편리하다.
•
실시간 대시보드를 통해 리소스 상태를 즉시 파악할 수 있다.
•
알람을 통해 메모리·CPU 과부하 같은 이벤트에 빠르게 대응할 수 있다.
•
데이터팀 인프라를 백엔드팀과 동일한 방식으로 운영하여, 일원화된 모니터링 체계를 구축할 수 있었다.
실제 활용 사례
•
ECS 배포 검증
◦
ECS 배포 직후 워커의 CPU·메모리 사용량과 태스크 개수를 확인해, 정상적으로 기동되었는지 실시간으로 검증할 수 있다.
배포 직후 워커 리소스
•
대규모 데이터 업데이트 시 DMS 모니터링
◦
대량 업데이트 작업이 진행될 때는 CDC Latency가 치솟는 경우가 있는데, Grafana 대시보드를 통해 지연 상태 파악가능
대규모 업데이트 DMS CDC 지표들