RDS 핵심 모니터링 지표
AWS RDS를 운영할 때 데이터베이스 성능과 안정성을 보장하려면 핵심 지표를 지속적으로 모니터링해야 합니다. CloudWatch는 RDS의 주요 메트릭을 실시간으로 제공하며, 이를 통해 문제가 발생하기 전에 미리 감지하고 대응할 수 있습니다.
CloudWatch Top 10 RDS 메트릭
| 메트릭 | 의미 | 위험 임계값 | 카테고리 |
|---|---|---|---|
| CPUUtilization | CPU 사용률 | > 80% 지속 | Compute |
| DatabaseConnections | 활성 커넥션 수 | max_connections 근접 | Connection |
| FreeableMemory | 사용 가능 메모리 | < 25% 총 메모리 | Memory |
| ReadIOPS / WriteIOPS | 초당 I/O 작업 수 | gp3 기본 3000 초과 | Storage |
| DiskQueueDepth | 디스크 대기 큐 | > 1 지속 | Storage |
| FreeStorageSpace | 남은 디스크 | < 20% | Storage |
| ReplicaLag | 복제 지연 시간 | > 1초 | Replication |
| SwapUsage | 스왑 메모리 사용량 | > 0 (발생 자체가 문제) | Memory |
| ReadLatency / WriteLatency | I/O 지연 시간 | > 20ms | Storage |
| NetworkReceiveThroughput | 네트워크 수신 처리량 | 대역폭 한계 근접 | Network |
핵심 포인트: RDS 모니터링에서 가장 중요한 3가지는 CPUUtilization, DatabaseConnections, DiskQueueDepth입니다. 이 세 지표만 제대로 추적해도 대부분의 성능 문제를 사전에 감지할 수 있습니다.
CPU & 커넥션
CPUUtilization 분석
CPU 사용률은 데이터베이스가 쿼리를 처리하는 데 사용하는 컴퓨팅 리소스의 비율입니다. 지속적인 높은 CPU 사용률은 쿼리 최적화가 필요하거나 인스턴스 스케일업이 필요하다는 신호입니다.
정상
30-60%
여유 있는 상태. 트래픽 증가에 대응 가능
주의
60-80%
모니터링 강화 필요. 최적화 검토
위험
80%+
지속 시 즉각 대응 필요
원인과 대응
비효율적 쿼리, 인덱스 누락, 과도한 동시 요청, 풀 테이블 스캔
• EXPLAIN으로 slow query 분석
• 인덱스 추가 (적절한 컬럼 선택)
• 읽기 복제본(Read Replica) 활용
• 인스턴스 스케일업 (최후 수단)
DatabaseConnections 분석
동시에 데이터베이스에 연결된 클라이언트 수입니다. RDS 인스턴스마다 최대 커넥션 수가 정해져 있으며, 이를 초과하면 새로운 연결 요청이 거부됩니다.
max_connections 계산 공식
예: db.r5.large (16GB) → max_connections ≈ 1,340
커넥션 풀 설정 가이드
적정 풀 사이즈 = (CPU cores * 2) + 1
예: 4 vCPU 인스턴스 → 풀 크기 = (4 * 2) + 1 = 9
애플리케이션 인스턴스가 10개라면 → 총 90개 커넥션 사용
Warning
커넥션 풀 없이 요청마다 새 커넥션을 열면 순식간에 max_connections에 도달합니다. 반드시 애플리케이션 레벨에서 커넥션 풀을 구현하세요.
CloudWatch 쿼리 예시
{
"metrics": [
["AWS/RDS", "CPUUtilization", "DBInstanceIdentifier", "mydb-prod"],
["AWS/RDS", "DatabaseConnections", "DBInstanceIdentifier", "mydb-prod"]
],
"period": 300,
"stat": "Average"
}IOPS & 스토리지
gp3 vs io2 비교
| 항목 | gp3 | io2 |
|---|---|---|
| 기본 IOPS | 3,000 | 프로비저닝 |
| 최대 IOPS | 16,000 | 64,000 |
| 기본 처리량 | 125 MB/s | 프로비저닝 |
| 가격 모델 | 용량 + IOPS 추가 | 용량 + IOPS 프로비저닝 |
| 적합한 경우 | 일반 워크로드 | 높은 I/O 요구 |
Burst Credit 소진 시나리오 (gp2 레거시)
gp2는 AWS의 구형 스토리지 타입으로, Burst Credit 메커니즘을 사용합니다. 신규 RDS는 gp3를 사용하지만, 레거시 시스템에서는 여전히 gp2를 사용할 수 있으므로 이해가 필요합니다.
gp2 IOPS 계산
• 기본 IOPS = 3 IOPS/GB
• 100GB 볼륨 = 300 IOPS 기본
• 최대 3,000 IOPS까지 burst 가능 (단, credit 소진 시 기본으로 복귀)
증상: Burst Credit 소진
• 갑자기 쿼리가 느려짐 (이전엔 빨랐는데 갑자기 지연)
• DiskQueueDepth가 급증
• CloudWatch에서 BurstBalance가 0%에 근접
해결: gp3로 마이그레이션하거나 볼륨 크기 증가
DiskQueueDepth
디스크에 대기 중인 I/O 요청의 수입니다. 이 값이 높다는 것은 디스크가 처리할 수 있는 속도보다 더 많은 I/O 요청이 들어오고 있다는 의미입니다.
0-0.5
이상적인 상태. I/O가 즉시 처리됨
0.5-1
약간의 대기. 모니터링 필요
1+
디스크 병목. 즉시 조치 필요
대응 방법
• IOPS 프로비저닝 증가 (gp3: 3,000 → 6,000+)
• io2로 스토리지 타입 변경 (높은 I/O 워크로드)
• 쿼리 최적화로 I/O 요청 자체를 줄임
ReadLatency / WriteLatency
디스크 I/O 작업의 평균 완료 시간입니다. 밀리초(ms) 단위로 측정되며, 낮을수록 좋습니다.
해석 가이드
매우 양호. SSD 기대 성능
정상 범위. 모니터링 유지
높은 지연. IOPS 증가 또는 쿼리 최적화 필요
Replication & 지연
Read Replica 구조
AWS RDS는 읽기 부하를 분산하기 위해 Read Replica를 지원합니다. Primary 인스턴스의 변경사항이 비동기 방식으로 Replica에 복제됩니다.
쓰기 + 읽기
읽기 전용
비동기 복제 (Asynchronous Replication)
ReplicaLag 원인
ReplicaLag는 Primary와 Replica 간의 데이터 차이를 초(second) 단위로 나타냅니다. 이 값이 높을수록 Replica의 데이터가 Primary보다 뒤처져 있다는 의미입니다.
주요 원인
Primary의 쓰기 부하가 높음
Replica가 변경사항을 따라잡을 수 없을 만큼 빠른 쓰기
Replica 인스턴스 스펙 부족
Replica의 CPU/메모리가 Primary보다 낮음
네트워크 대역폭 한계
Primary-Replica 간 네트워크 지연 또는 포화
Replica에 과도한 읽기 부하
복제 적용 프로세스와 읽기 쿼리가 리소스 경쟁
데이터 정합성 문제
ReplicaLag가 존재하면 사용자가 최신 데이터를 볼 수 없는 문제가 발생할 수 있습니다.
실제 사례: "완료했는데 진도가 안 올라가요"
시간 순서
10:30:00 학생이 학습 완료 → Primary에 기록
10:30:02 학생이 진도 페이지 새로고침 → Replica에서 읽기
10:30:02 ReplicaLag = 5초 → 아직 Replica에 미반영
결과: "완료했는데 진도가 안 올라가요!" 문의 발생
해결 방법
1. Write-after-Read 패턴
쓰기 직후 읽기는 Primary에서, 이후 읽기는 Replica에서
2. Session Stickiness
사용자 세션 동안 같은 DB 엔드포인트 사용
3. ReplicaLag 모니터링
Lag > 1초 지속 시 알람 설정
Tip: Replica 스펙 맞추기
ReplicaLag가 지속적으로 증가한다면, Replica 인스턴스 사양을 Primary와 동일하게 맞추세요. 비용을 아끼려고 Replica를 작은 인스턴스로 운영하면 복제가 따라잡지 못해 오히려 문제가 됩니다.
Performance Insights
Performance Insights는 RDS의 성능 병목을 시각적으로 분석할 수 있는 AWS의 강력한 도구입니다. 단순한 메트릭을 넘어, 어떤 쿼리가 문제를 일으키는지, 어떤 리소스에서 대기가 발생하는지 상세하게 보여줍니다.
DB Load 그래프
DB Load는 데이터베이스에서 동시에 활성화된 세션(Active Session) 수를 나타냅니다. 이 값이 인스턴스의 vCPU 수보다 높으면 일부 세션이 대기 상태에 있다는 의미입니다.
해석 예시
인스턴스: db.r5.xlarge (4 vCPU)
DB Load = 2 → 정상. 여유 있음
DB Load = 4 → CPU 포화. 대기 시작 직전
DB Load = 12 → 3배 과부하. 8개 세션이 대기 중
Top SQL
데이터베이스에서 가장 많은 리소스(CPU, I/O, Lock 등)를 소비하는 쿼리를 순위별로 보여줍니다. 성능 최적화의 출발점은 항상 Top SQL 분석입니다.
Top SQL에서 확인할 사항
• 실행 횟수 (Executions): 얼마나 자주 호출되는가?
• 평균 지연 시간 (Average Latency): 한 번 실행에 걸리는 시간
• 총 DB Time: 실행 횟수 × 평균 지연 시간
• Wait Event 분포: CPU, IO, Lock 중 어디서 시간을 소비하는가?
Wait Events 분류
쿼리가 실행될 때 CPU 외의 리소스를 기다리는 이벤트를 Wait Event라고 합니다. Wait Event 종류를 보면 성능 병목의 원인을 정확히 파악할 수 있습니다.
주요 Wait Events
| 카테고리 | Wait Event | 의미 | 대응 |
|---|---|---|---|
| CPU | CPU | 쿼리 실행 중 CPU 사용 | 쿼리 최적화, 인덱스 |
| IO | IO:DataFileRead | 디스크에서 데이터 읽기 | 메모리 증설, IOPS 증가 |
| IO | IO:DataFileWrite | 디스크에 데이터 쓰기 | IOPS 증가, io2 전환 |
| Lock | Lock:wait | 행 잠금 대기 | 트랜잭션 최적화, 락 범위 축소 |
| Lock | LWLock:BufferMapping | 버퍼 매핑 잠금 | 메모리 증설 |
| Memory | bufferpin:BufferPin | 버퍼 핀 대기 | shared_buffers 조정 |
Performance Insights 활성화 방법
- 1. RDS 콘솔에서 DB 인스턴스 선택
- 2. "Modify" 클릭
- 3. "Performance Insights" 섹션에서 "Enable Performance Insights" 체크
- 4. 보관 기간 선택 (7일 무료 / 25개월 유료)
- 5. "Continue" → "Apply immediately" → "Modify DB instance"
비용 안내
Performance Insights는 7일 보관 기준으로 추가 비용 없이 사용할 수 있습니다. 25개월 장기 보관은 유료입니다. 대부분의 경우 7일 보관으로도 충분합니다.
실전: DB 응답 지연 추적 워크스루
실제 장애 상황을 시뮬레이션하여 RDS 메트릭 분석 전체 프로세스를 경험해봅시다.
시나리오: API 타임아웃 증가 알림 수신
오전 10시 30분, Datadog에서 API 응답 시간 P99가 5초를 초과했다는 알림을 받았습니다. 사용자들이 앱이 느리다는 문의를 하기 시작했습니다. 어떻게 추적할까요?
CloudWatch 알람 확인
RDS CloudWatch 알람 히스토리를 확인합니다.
⚠ ALARM: RDS-CPUUtilization-High
Threshold: CPUUtilization > 80% for 5 minutes
State changed at: 2025-01-15 10:30:00 UTC
CloudWatch 대시보드 분석
CPU 그래프를 열어 시간대별 추이를 확인합니다.
📊 CPU Utilization Graph
10:00 - 10:25: 30-40% (정상)
10:30 - 10:45: 85-92% (급증!)
→ 10:30부터 갑자기 CPU가 치솟았음
Performance Insights 열기
RDS 콘솔 → Performance Insights로 이동하여 DB Load 확인
📈 DB Load: 12
vCPU: 4
→ DB Load가 vCPU의 3배! 심각한 과부하
Top SQL 확인
Performance Insights에서 가장 많은 DB Time을 소비하는 쿼리 확인
SELECT * FROM study_activity_instances
WHERE created_at > '2025-01-01'
ORDER BY created_at DESC;⚠ 이 쿼리가 DB Time의 67%를 차지함
EXPLAIN 실행
문제 쿼리를 EXPLAIN으로 분석하여 실행 계획 확인
EXPLAIN SELECT * FROM study_activity_instances
WHERE created_at > '2025-01-01'
ORDER BY created_at DESC;type: ALL (풀 테이블 스캔!)
rows: 257,000,000
key: NULL (인덱스 미사용)
🔥 2.5억 건을 풀 스캔 → 인덱스 누락!
해결: 인덱스 추가
created_at 컬럼에 인덱스를 추가하여 풀 스캔 방지
CREATE INDEX idx_sai_created_at
ON study_activity_instances(created_at);인덱스 생성 시간: 약 5분 (백그라운드)
결과 확인
CloudWatch와 Performance Insights에서 개선 확인
✓ CPU Utilization: 85% → 15%
✓ DB Load: 12 → 2
✓ API P99 Latency: 5000ms → 150ms
→ 문제 해결! 사용자 문의 중단
학습 포인트
Performance Insights → Top SQL → EXPLAIN 순서로 추적하면 대부분의 DB 성능 문제를 해결할 수 있습니다. 메트릭만 보지 말고, 실제로 어떤 쿼리가 문제인지 파고들어야 근본 원인을 찾을 수 있습니다.
퀴즈
학습한 내용을 확인해봅시다. 5문제를 모두 풀어보세요.