MySQL HeatWave 운영 모니터링, 어떻게 구성하나요?
핵심 요약: HeatWave 운영 상태를 Metrics, Alerts, Logs 3개 레이어와 MELC 프레임워크로 보는 방법을 정리해요. 메모리 85% 임계값, 오프로드 검증, 장애 원인 추적 SQL을 바로 적용할 수 있어요.
지난 글에서 MySQL HeatWave의 아키텍처와 도입 배경을 다뤘어요. 이번에는 실제 운영 단계에서 마주치는 질문을 다룰게요. "HeatWave가 잘 돌아가고 있는지 어떻게 알 수 있나요?"
도입 후 처음 며칠은 쿼리가 빠르게 응답하는 것만 확인하고 넘어가는 경우가 많아요. 그런데 운영하면서 계속 느낀 건, 모니터링 체계 없이는 문제가 생겼을 때 원인을 찾는 데 너무 오래 걸린다는 거예요. CPU가 갑자기 치솟거나, HeatWave 쿼리가 예상보다 느려지거나, 어느 날 갑자기 오프로드가 안 되는 상황이 생기는데, 그때 로그와 메트릭이 없으면 막막해요.
이 글에서는 HeatWave 운영 모니터링을 3개 레이어로 구조화하는 방법, 실제로 쓰는 SQL 쿼리들, 그리고 장애 상황에서 어떻게 원인을 추적하는지를 정리했어요.
3-Layer 모니터링 아키텍처
모니터링을 처음 설계할 때 "무엇을 봐야 하는가"를 정리하지 않으면 대시보드가 지표로 가득 차지만 정작 필요한 순간에 아무것도 보이지 않아요. 오래된 건물을 리모델링하려다 벽 안에 배선이 얼마나 복잡한지 뒤늦게 발견하는 것과 비슷해요. 처음부터 구조를 잡아야 해요.
HeatWave 모니터링은 3개 레이어로 나눠서 생각하면 관리하기 쉬워요.
| 레이어 | 역할 | 주요 데이터 소스 |
|---|---|---|
| Layer 1: Metrics | 현재 상태 수치화 | performance_schema, sys schema, HeatWave 전용 메트릭 |
| Layer 2: Alerts | 임계값 초과 감지 | 임계값 기반 알림, 이상 탐지 |
| Layer 3: Logs | 이벤트 기록 추적 | error_log, slow_query_log, audit_log |
세 레이어가 독립적으로 동작하는 것처럼 보이지만, 실제 장애 대응에서는 항상 함께 봐야 해요. 메트릭에서 CPU 스파이크를 발견하면, 그 시점의 슬로우 쿼리 로그와 에러 로그를 교차 확인해야 원인이 보여요.
MELC 모니터링 프레임워크
운영 경험을 쌓으면서 정리한 프레임워크가 있어요. MELC 모델이에요. Metrics, Errors, Logs, Correlation 네 가지 축으로 모니터링 항목을 분류해요.
Metrics는 시스템의 현재 상태를 수치로 표현해요. CPU 사용률, 메모리, 디스크 I/O, 네트워크 처리량 같은 인프라 메트릭과 함께 HeatWave 전용 메트릭인 오프로드 비율, 노드 상태, 쿼리 처리 속도를 포함해요.
Errors는 연결 오류, 쿼리 실패, HeatWave 오프로드 실패처럼 시스템이 명시적으로 기록하는 오류 이벤트예요. 메트릭이 "얼마나 나쁜가"를 보여준다면, 에러는 "무엇이 잘못됐는가"를 알려줘요.
Logs는 에러보다 더 넓은 범위의 이벤트를 기록해요. 슬로우 쿼리, 일반 쿼리 로그, 감사 로그가 여기에 해당해요. 특히 슬로우 쿼리 로그는 성능 저하의 원인을 찾을 때 가장 먼저 확인하는 항목이에요.
Correlation은 세 가지를 교차 분석하는 과정이에요. 메트릭 스파이크가 발생한 시점에 어떤 에러가 기록됐는지, 그 시점의 슬로우 쿼리는 무엇인지를 연결해야 진짜 원인이 보여요. 이 단계를 건너뛰면 증상만 보고 원인을 놓치는 경우가 생겨요.
HeatWave 상태 확인을 위한 핵심 SQL 쿼리
클러스터 상태 확인
HeatWave 노드가 정상적으로 동작하는지 확인하는 첫 번째 쿼리예요. 노드 상태가 AVAIL_RPDGSTABCDEFG 이외의 값이면 문제가 있는 거예요.
-- HeatWave 노드 상태 확인
SELECT * FROM performance_schema.rpd_nodes;실행 결과에서 NODE_STATUS 컬럼을 확인해요. 정상 상태는 AVAIL_RPDGSTABCDEFG이고, OFFLINE이나 ERROR 상태가 보이면 즉시 조치가 필요해요.
-- HeatWave 실행 상태 확인
SELECT * FROM performance_schema.rpd_exec_status;이 쿼리는 HeatWave 엔진의 현재 실행 상태를 보여줘요. 쿼리가 실제로 HeatWave에서 처리되고 있는지, 대기 중인 작업이 있는지 확인할 수 있어요.
메모리 사용량 모니터링
HeatWave는 인메모리 엔진이라 메모리 관리가 핵심이에요. 메모리가 부족하면 테이블 로드가 실패하거나 쿼리 성능이 급격히 떨어져요.
-- HeatWave 클러스터 메모리 사용량
SELECT * FROM sys.heatwave_cluster_usage;MEMORY_USED와 MEMORY_TOTAL 비율이 85%를 넘으면 노드 확장을 검토해야 해요. 운영하면서 계속 느낀 건, 메모리 사용률이 90%를 넘기 전에 미리 대응해야 한다는 거예요. 그 이후에는 이미 성능 저하가 시작된 상태예요.
쿼리 오프로드 검증
HeatWave를 도입했는데 쿼리가 실제로 HeatWave에서 실행되고 있는지 확인하는 방법이에요. 오프로드가 안 되면 MySQL InnoDB에서 처리되기 때문에 기대했던 성능이 나오지 않아요.
-- 쿼리 실행 계획에서 HeatWave 오프로드 확인
EXPLAIN SELECT department, SUM(salary)
FROM employees
GROUP BY department;실행 계획의 Extra 컬럼에 Using secondary engine RAPID가 표시되면 HeatWave에서 처리되는 거예요. 이 문구가 없으면 InnoDB에서 처리되고 있다는 뜻이에요.
-- HeatWave 쿼리 통계 확인
SELECT * FROM performance_schema.rpd_query_stats;이 쿼리로 HeatWave에서 처리된 쿼리 수, 평균 실행 시간, 오프로드 실패 횟수를 확인할 수 있어요.
테이블 로드 상태 확인
HeatWave에 로드된 테이블과 컬럼 목록을 확인하는 쿼리예요. 특정 테이블이 로드되지 않았다면 해당 테이블을 포함한 쿼리는 오프로드되지 않아요.
-- HeatWave에 로드된 테이블 목록
SELECT * FROM performance_schema.rpd_tables;
-- HeatWave에 로드된 컬럼 목록
SELECT * FROM performance_schema.rpd_columns;LOAD_STATUS가 AVAIL_RPDGSTABCDEFG인 테이블만 HeatWave에서 쿼리를 처리할 수 있어요. NOT_LOADED나 LOAD_ERROR 상태인 테이블은 수동으로 다시 로드해야 해요.
에러 로그 모니터링
HeatWave 관련 에러만 필터링해서 확인하는 쿼리예요. 전체 에러 로그에서 HeatWave 관련 항목만 추출하기 때문에 노이즈 없이 핵심 문제를 파악할 수 있어요.
-- HeatWave 관련 에러 로그 최근 20건
SELECT * FROM performance_schema.error_log
WHERE subsystem = 'HeatWave'
ORDER BY logged DESC
LIMIT 20;PRIO 컬럼이 Error나 Warning인 항목을 우선 확인해요. Note 수준은 정보성 메시지라 일반적으로 무시해도 돼요.
슬로우 쿼리 분석
성능 저하의 원인을 찾을 때 가장 먼저 확인하는 쿼리예요.
-- 풀 테이블 스캔이 발생하는 쿼리 목록
SELECT * FROM sys.statements_with_full_table_scans;
-- 실행 시간 기준 상위 10개 쿼리
SELECT * FROM performance_schema.events_statements_summary_by_digest
ORDER BY sum_timer_wait DESC
LIMIT 10;sum_timer_wait는 나노초 단위예요. 1,000,000,000으로 나누면 초 단위로 변환돼요. 풀 테이블 스캔이 발생하는 쿼리는 HeatWave 오프로드 대상인지 확인하고, 오프로드가 안 된다면 인덱스 추가를 검토해야 해요.
복제 지연 모니터링
HeatWave는 MySQL 복제 위에서 동작하기 때문에 복제 지연이 생기면 HeatWave 데이터도 최신 상태가 아닐 수 있어요.
-- 복제 그룹 멤버 상태 확인
SELECT * FROM performance_schema.replication_group_members;
-- 복제 상태 상세 확인
SHOW REPLICA STATUS\GSeconds_Behind_Source 값이 1초를 넘으면 복제 지연이 발생하고 있는 거예요. 대용량 트랜잭션이나 네트워크 지연이 원인인 경우가 많아요.
무엇을 기준으로 "정상"을 판단하나요?
모니터링 체계를 구축할 때 가장 먼저 해야 할 일은 SLO(Service Level Objective)를 정의하는 거예요. 숫자 없이는 알림 임계값을 설정할 수 없고, 임계값 없이는 의미 있는 알림을 만들 수 없어요.
HeatWave 운영에서 권장하는 SLO 기준이에요.
| 항목 | 목표값 | 측정 방법 |
|---|---|---|
| OLTP 쿼리 지연 p95 | 200ms 미만 | performance_schema.events_statements_summary_by_digest |
| OLAP/HeatWave 쿼리 지연 p95 | 5초 미만 | rpd_query_stats |
| 가용성 | 99.95% | 월간 다운타임 22분 이내 |
| HeatWave 오프로드 비율 | 95% 이상 | rpd_query_stats 기준 |
| 에러율 | 0.1% 미만 | 전체 쿼리 대비 실패 쿼리 비율 |
| 복제 지연 | 1초 미만 | SHOW REPLICA STATUS |
처음에는 이 숫자들이 너무 엄격하게 느껴질 수 있어요. 하지만 실제 프로젝트에서는 SLO를 느슨하게 잡으면 나중에 고객사가 "왜 이렇게 느리냐"고 할 때 대응 근거가 없어요. 처음부터 명확한 기준을 잡는 게 중요해요.
Grafana vs Datadog, 어떤 도구를 선택할까요?
모니터링 도구 선택은 고객사의 상황에 따라 달라져요. 비용, 운영 인력, 기존 인프라 환경을 함께 고려해야 해요.
| 항목 | Grafana + Prometheus | Datadog |
|---|---|---|
| 비용 | 오픈소스 (인프라 비용만 발생) | 호스트당 과금 |
| 초기 설정 | 수동 구성 필요 | 에이전트 기반 자동 탐지 |
| MySQL 연동 | mysqld_exporter 별도 설치 | 네이티브 통합 |
| HeatWave 메트릭 | 커스텀 쿼리 작성 필요 | 커스텀 쿼리 작성 필요 |
| 알림 | AlertManager | 내장 알림 시스템 |
| 대시보드 | 높은 커스터마이징 자유도 | 사전 구성 템플릿 제공 |
| 학습 곡선 | 가파름 | 완만함 |
| 적합한 상황 | 비용 민감, 커스텀 요구사항 많음 | 빠른 구축, 엔터프라이즈 지원 필요 |
주의할 점이 있어요. HeatWave 전용 메트릭은 두 도구 모두 기본 제공하지 않아요. performance_schema에서 커스텀 쿼리로 데이터를 수집하는 방식을 직접 구성해야 해요. 이 부분은 어떤 도구를 선택하든 동일한 공수가 들어요.
비용이 중요한 고객사라면 Grafana + Prometheus 조합이 합리적이에요. 반면 운영 인력이 부족하거나 빠른 구축이 필요한 경우라면 Datadog의 자동 탐지와 사전 구성 대시보드가 시간을 많이 절약해줘요.
장애 대응 시나리오
원인을 추적한 끝에 패턴이 보이기 시작했어요. 자주 발생하는 장애 유형은 대부분 비슷한 흐름으로 진행돼요.
시나리오 1. CPU 스파이크
CPU 사용률이 갑자기 80%를 넘으면 다음 순서로 확인해요.
1단계: 현재 실행 중인 쿼리 확인
SELECT id, user, host, db, command, time, state, info
FROM information_schema.processlist
WHERE command != 'Sleep'
ORDER BY time DESC;2단계: 실행 시간이 긴 쿼리를 찾아서 실행 계획 확인. HeatWave 오프로드가 안 되는 무거운 쿼리가 InnoDB에서 처리되고 있는 경우가 많아요.
3단계: 필요하면 KILL [id]로 해당 쿼리를 종료하고, 근본 원인은 쿼리 최적화나 인덱스 추가로 해결해요.
시나리오 2. HeatWave 오프로드 실패
쿼리가 예상보다 느린데 실행 계획에 Using secondary engine RAPID가 없다면 오프로드 실패예요.
1단계: 노드 상태 확인
SELECT NODE_ID, NODE_STATUS, MEMORY_USED, MEMORY_TOTAL
FROM performance_schema.rpd_nodes;2단계: 테이블 로드 상태 확인
SELECT TABLE_NAME, LOAD_STATUS
FROM performance_schema.rpd_tables
WHERE LOAD_STATUS != 'AVAIL_RPDGSTABCDEFG';3단계: 로드 실패한 테이블이 있으면 수동으로 다시 로드해요.
ALTER TABLE [table_name] SECONDARY_LOAD;4단계: 메모리 사용률이 높아서 로드가 실패하는 경우라면 노드 수를 늘리거나 불필요한 테이블을 언로드해야 해요.
시나리오 3. 디스크 풀
바이너리 로그가 쌓여서 디스크가 가득 차는 경우예요. 특히 복제 환경에서 자주 발생해요.
1단계: 바이너리 로그 목록 확인
SHOW BINARY LOGS;2단계: 보존 기간 설정 확인
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';3단계: 오래된 바이너리 로그 수동 삭제 (복제 지연이 없는 상태에서만 실행)
PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 3 DAY);이 작업은 복제 슬레이브가 아직 읽지 않은 로그를 삭제하면 복제가 깨질 수 있어요. 반드시 SHOW REPLICA STATUS로 복제 상태를 확인한 후 진행해야 해요.
핵심 요약
- HeatWave 모니터링은 Metrics, Alerts, Logs 3개 레이어로 구조화하면 관리가 쉬워요.
- MELC 모델(Metrics, Errors, Logs, Correlation)로 장애 원인을 체계적으로 추적할 수 있어요.
performance_schema.rpd_nodes,rpd_tables,rpd_query_stats는 HeatWave 상태 확인의 핵심 뷰예요.- SLO를 먼저 정의해야 의미 있는 알림 임계값을 설정할 수 있어요. HeatWave 오프로드 비율 95% 이상, 복제 지연 1초 미만이 기본 기준이에요.
- Grafana와 Datadog 모두 HeatWave 전용 메트릭은 커스텀 쿼리로 수집해야 해요. 도구 선택은 비용과 운영 인력 상황에 따라 결정해요.
FAQ
Q. HeatWave 쿼리가 오프로드되는지 어떻게 확인하나요?
EXPLAIN 명령어로 실행 계획을 확인했을 때 Extra 컬럼에 Using secondary engine RAPID가 표시되면 HeatWave에서 처리되는 거예요. 이 문구가 없으면 InnoDB에서 처리되고 있어요. performance_schema.rpd_query_stats에서 오프로드된 쿼리 수와 실패 횟수도 확인할 수 있어요.
Q. HeatWave 노드 메모리가 부족할 때 어떻게 대응하나요?
sys.heatwave_cluster_usage에서 메모리 사용률을 확인하고, 85%를 넘으면 두 가지 방법을 검토해요. 첫 번째는 불필요한 테이블을 ALTER TABLE [table_name] SECONDARY_UNLOAD로 언로드하는 것이고, 두 번째는 HeatWave 노드 수를 늘리는 거예요. 메모리 압박이 심한 상태에서 새 테이블을 로드하려 하면 로드 자체가 실패할 수 있어요.
Q. 복제 지연이 발생하면 HeatWave 데이터에도 영향이 있나요?
네, 있어요. HeatWave는 MySQL 복제 스트림을 통해 데이터를 동기화하기 때문에 복제 지연이 생기면 HeatWave의 데이터도 최신 상태가 아닐 수 있어요. 실시간 분석이 중요한 워크로드라면 복제 지연 모니터링을 SLO에 포함시키고, 1초 이상 지연이 발생하면 알림이 오도록 설정하는 게 좋아요.
Q. Grafana와 Datadog 중 어떤 걸 선택해야 하나요?
운영 인력이 충분하고 커스터마이징이 중요하다면 Grafana + Prometheus 조합이 비용 효율적이에요. 빠른 구축이 필요하거나 엔터프라이즈 지원이 필요한 고객사라면 Datadog이 초기 설정 시간을 많이 줄여줘요. 단, HeatWave 전용 메트릭은 두 도구 모두 커스텀 쿼리를 직접 작성해야 한다는 점은 동일해요.
Q. 슬로우 쿼리 로그를 활성화하면 성능에 영향이 있나요?
long_query_time을 너무 낮게 설정하면 로그 양이 많아져서 디스크 I/O에 영향을 줄 수 있어요. 운영 환경에서는 1초 이상 걸리는 쿼리만 기록하도록 설정하는 게 일반적이에요. HeatWave 환경에서는 OLAP 쿼리가 수 초 걸리는 경우도 있으니, 슬로우 쿼리 임계값을 OLTP와 OLAP 워크로드 특성에 맞게 조정해야 해요.
다음 글에서는 HeatWave Auto Parallel Load와 쿼리 힌트를 활용한 성능 최적화를 다룰게요. 모니터링 체계를 갖춘 다음 단계는 데이터를 기반으로 성능을 개선하는 거니까요.
운영하면서 계속 느낀 건, 모니터링은 문제가 생긴 후에 구축하면 이미 늦다는 거예요. 도입 초기에 3-Layer 구조와 SLO를 먼저 잡아두면, 나중에 장애가 생겼을 때 원인을 찾는 시간이 훨씬 줄어들어요.