MSSQL -> MySQL 데이터 마이그레이션- 5.모니터링 및 성능 최적화 단계

마이그레이션 후: 모니터링 및 성능 최적화 단계

마이그레이션이 완료되었더라도 모니터링과 성능 최적화는 안정적인 운영을 위해 필수입니다.

다음은 AWS RDS MySQL 환경에서의 모니터링 및 성능 튜닝을 단계별로 자세히 설명합니다.

---

🔍 1. 모니터링 설정 및 지표 확인

AWS RDS는 Amazon CloudWatch와 Performance Insights를 통해 다양한 성능 지표를 제공합니다.

다음과 같은 **핵심 지표(Key Metrics)**를 중점적으로 모니터링해야 합니다.

📈 1-1. CloudWatch 메트릭 구성

AWS Console → RDS → Monitoring → Enable Enhanced Monitoring

메트릭 설명 권장 액션

CPUUtilization	CPU 사용률(%)	70% 이상 시 쿼리 최적화 필요
FreeableMemory	가용 메모리(GB)	InnoDB Buffer Pool 조정
DiskQueueDepth	디스크 I/O 대기열	I/O 병목 시 IOPS 증설
ReadIOPS/WriteIOPS	초당 읽기/쓰기 요청 수	애플리케이션 패턴 확인
ReplicationLag	레플리케이션 지연 시간(초)	CDC 사용 시 반드시 체크
DatabaseConnections	동시 연결 수	예상보다 많으면 커넥션 풀링 적용

✅ CloudWatch 알람 설정

• CPU 사용률 70% 초과 시 알림 전송
• FreeableMemory 500MB 이하 시 알림 전송

AWS CLI 설정 예제:

bash

aws cloudwatch put-metric-alarm \\
  --alarm-name "HighCPUUsage" \\
  --metric-name "CPUUtilization" \\
  --namespace "AWS/RDS" \\
  --statistic "Average" \\
  --period 60 \\
  --threshold 70 \\
  --comparison-operator "GreaterThanOrEqualToThreshold" \\
  --dimensions "Name=DBInstanceIdentifier,Value=my-mysql-instance" \\
  --evaluation-periods 2 \\
  --alarm-actions "arn:aws:sns:region:account-id:my-sns-topic" \\
  --unit "Percent"

---

🎯 1-2. Performance Insights 분석

AWS Console → RDS → Performance Insights

확인 포인트:

1. Top SQL Queries: CPU를 과도하게 사용하는 쿼리 식별
2. Wait Events: DB Lock 및 디스크 I/O 병목 탐지
3. DB Load by Wait Event: 병목 현상의 원인(예: InnoDB buffer pool waits) 파악

🔍 실제 대기 이벤트 예제 분석

• innodb_buffer_pool_wait_free: 버퍼 풀이 가득 참 → 버퍼 크기 증가 필요
• log_sys_mutex: 로그 쓰기 병목 → Redo Log Buffer 크기 증가 필요

---

⚙️ 2. 성능 최적화(Performance Tuning)

MySQL의 성능을 최적화하기 위해 다음 설정을 검토합니다.

---

🛠️ 2-1. InnoDB Buffer Pool 최적화

MySQL의 InnoDB 스토리지 엔진은 **버퍼 풀(Buffer Pool)**을 활용해 성능을 최적화합니다.

✅ 버퍼 풀 현황 확인

SHOW ENGINE INNODB STATUS;

⚙️ 버퍼 풀 크기 조정

-- 전체 메모리의 60~70%로 설정(OLTP 환경)
SET GLOBAL innodb_buffer_pool_size = 6G;

-- 변경 내용 영구 적용
[mysqld]
innodb_buffer_pool_size=6G

권장 기준:

• OLTP(Online Transaction Processing): 메모리의 60~70%
• OLAP(Online Analytical Processing): 디스크 I/O 중심 최적화 필요

---

🔍 2-2. 쿼리 성능 분석 및 튜닝

MySQL은 Slow Query Log를 통해 쿼리 성능을 분석할 수 있습니다.

✅ Slow Query Log 활성화

-- 슬로우 쿼리 로그 활성화
SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 1; -- 1초 이상 실행된 쿼리 기록

-- 로그 파일 경로 확인
SHOW VARIABLES LIKE 'slow_query_log_file';

CloudWatch Logs 연동 시:

AWS Console → RDS → Configuration → Slow Query Logs 활성화.

---

🔍 문제 쿼리 분석 예제

슬로우 쿼리 로그에서 다음과 같은 쿼리를 발견했다고 가정:

SELECT name FROM customers WHERE email LIKE '%@gmail.com%';

🚨 문제점:

• 좌측 와일드카드(% 앞에 값이 없음)로 인해 인덱스 미사용.

🔧 개선방안:

1. Email 도메인 분리 컬럼 추가
2. email_domain 컬럼에 INDEX 생성 후 검색.

ALTER TABLE customers ADD COLUMN email_domain VARCHAR(50);
UPDATE customers SET email_domain = SUBSTRING_INDEX(email, '@', -1);

-- 인덱스 생성
CREATE INDEX idx_email_domain ON customers(email_domain);

-- 최적화된 쿼리
SELECT name FROM customers WHERE email_domain = 'gmail.com';

---

⚡ 2-3. 쿼리 캐싱(Query Cache) 전략

MySQL 8.0 이상에서는 **쿼리 캐시(Query Cache)**가 제거되었습니다.

→ 응용 프로그램 레벨에서 캐싱 전략(예: Redis 사용)을 고려해야 합니다.

---

🔍 2-4. 인덱스 전략 점검

MySQL 인덱스가 제대로 작동하지 않으면 성능이 급격히 저하됩니다.

✅ 인덱스 현황 확인

SHOW INDEX FROM employees;

🛠️ 인덱스 튜닝 체크리스트

• 과도한 인덱스 → INSERT/UPDATE 성능 저하
• 자주 조회되는 컬럼 → Composite Index 고려
• 인덱스 힌트 사용 시점 검토

---

🚦 3. MySQL 파라미터 튜닝

MySQL RDS의 성능은 파라미터 그룹 설정에 크게 영향을 받습니다.

AWS Console → RDS → Parameter Groups

파라미터 설명 권장 설정

innodb_buffer_pool_size	InnoDB 버퍼 크기	RAM의 60~70% 설정
max_connections	동시 연결 수	애플리케이션 부하에 따라 증가
query_cache_size	MySQL 5.x 버전만 적용	0(기본) 권장(동시성 개선)
innodb_flush_log_at_trx_commit	로그 플러시 정책	1(기본)(데이터 무결성)

파라미터 변경 시: RDS 재시작 필요할 수 있음.

---

📡 4. AWS 기반 추가 성능 개선

AWS RDS에서는 성능 개선을 위한 다양한 기능을 제공합니다.

---

🚀 4-1. RDS 인스턴스 유형 업그레이드

• 현재 인스턴스 사양이 CPU/Memory 병목이 있다면 인스턴스 타입 변경 필요.
• 예: db.t3.medium → db.r5.large

---

⚡ 4-2. 스토리지 유형 변경

AWS RDS MySQL은 스토리지 성능에 따라 성능 차이가 큽니다.

스토리지 유형 특징 사용 시점

GP3(General Purpose SSD)	기본 SSD 성능 제공	대부분의 워크로드
IO1/IO2(Provisioned IOPS)	고성능 I/O 제공	OLTP 환경

변경 방법:

• AWS Console → RDS 인스턴스 → Storage Type 변경

---

📡 4-3. 읽기 성능 향상을 위한 Read Replica

Read-heavy 애플리케이션의 경우 Read Replica를 생성하여 쿼리 부하 분산 가능.

✅ Read Replica 생성:

• AWS Console → RDS 인스턴스 → Actions → Create Read Replica

자동 페일오버를 위한 Multi-AZ 배포도 고려.

---

🔐 4-4. 네트워크 및 보안 성능 검토

1. VPC Peering: Lambda → MySQL 호출 시 네트워크 대역폭 확인.
2. Security Group 최적화: 불필요한 IP 접근 제거.
3. SSL/TLS 활성화: MySQL DB 연결 시 암호화 필수.

---

🧪 5. 테스트 및 검증 단계

🛠️ 5-1. 부하 테스트(Load Testing)

AWS RDS MySQL이 실제 트래픽을 처리할 수 있는지 검증.

• Apache JMeter 또는 k6 도구를 활용하여 부하 테스트 수행.
• Lambda 기반 S3 URL 생성 서비스 성능 테스트 포함.

---

🧪 5-2. 장애 시나리오 테스트(Failover Testing)

Multi-AZ 및 Read Replica 구성 시, 장애 발생 시 동작을 검증.

✅ RDS 강제 페일오버 테스트

• AWS Console → RDS 인스턴스 → Actions → Reboot with failover

테스트 시 확인 사항:

• 애플리케이션 연결 시간 지연 측정
• Lambda → MySQL 연결 시 URL 생성 지연 확인

---

📖 6. 운영 환경 Best Practices

✅ 6-1. 백업 및 복구 전략

• 자동 백업: Retention period(보존 기간) 7일 이상 설정.
• 스냅샷 생성 자동화: AWS Lambda + EventBridge로 주기적 스냅샷 생성.

Lambda 코드 예제:

import boto3

def lambda_handler(event, context):
    rds = boto3.client('rds')
    db_instance_id = 'my-mysql-instance'
    snapshot_id = f"{db_instance_id}-snapshot-{event['time']}"

    rds.create_db_snapshot(
        DBInstanceIdentifier=db_instance_id,
        DBSnapshotIdentifier=snapshot_id
    )

---

🔐 6-2. 보안 강화(Security Hardening)

• IAM 정책 최소 권한 원칙(Least Privilege) 적용
• RDS MySQL 암호화: AES-256을 사용한 KMS Key 적용
• SQL Injection 방지: ORM JPA 설정 검토

---

🌐 6-3. AWS Lambda 연동 점검

AWS Lambda를 통해 S3 URL 단축 서비스가 정상 동작하는지 확인.

특히, RDS Proxy 사용을 통해 Lambda 콜드 스타트 시 연결 지연을 최소화.

---

🎯 마무리: 최종 체크리스트

항목 확인 완료(✔/❌)

CloudWatch 지표 설정 및 알림 활성화	✅
Slow Query Log 분석 및 쿼리 최적화	✅
InnoDB 버퍼 풀 크기 최적화	✅
RDS Proxy 및 Lambda 연결 테스트	✅
백업/복구 시나리오 테스트 완료	✅

---

🔔 이제 AWS RDS MySQL로의 마이그레이션이 안정적으로 완료되었습니다! 🚀