RDS 인스턴스 클래스 선택 기준: db.t·db.m·db.r 비교
RDS 인스턴스 클래스는 EC2 타입 앞에 db.가 붙은 모양이라 규칙은 같아 보입니다. 그런데 선택 기준은 다릅니다. 데이터베이스는 메모리가 곧 캐시라서 m과 r을 가르는 축이 EC2보다 메모리 쪽으로 기울고, t의 크레딧 소진은 서비스 전체 지연으로 직결됩니다. 결론을 먼저 적으면, 개발·검증은 db.t4g, 프로덕션은 db.m8g에서 시작하되, 워킹셋이 메모리를 넘는 실측이 보이면 db.r8g로 옮깁니다. EC2 쪽 이름 규칙과 패밀리 일반론은 EC2 인스턴스 패밀리 비교에서 다뤘습니다. 요금은 us-east-1, MySQL, Single-AZ 온디맨드 기준입니다.
이름은 같은 규칙, 지원은 엔진마다 다릅니다 #
db.m8g.large는 EC2의 m8g.large와 같은 하드웨어입니다. 패밀리(t·m·r), 세대 숫자, 속성 글자(g=Graviton, i=Intel)를 읽는 법도 같습니다. 다른 점은 두 가지입니다.
- 엔진·버전에 따라 쓸 수 있는 클래스가 다릅니다. 현행 Graviton4 세대(db.m8g·db.r8g)는 PostgreSQL, MySQL, MariaDB에서 지원되고, 엔진 버전 하한(MySQL 8.0.32 이상, PostgreSQL 13.8 이상 등)이 있습니다. Oracle, SQL Server는 지원 클래스 목록이 따로 갑니다. 클래스를 고르기 전에 콘솔에서 해당 엔진·버전으로 실제 선택지가 뜨는지부터 확인합니다.
- c 계열이 없습니다. 데이터베이스에서 vCPU 대 메모리 1:2는 수요가 없어서, 선택지는 사실상 t, m, r과 고메모리(db.x2g)입니다.
같은 하드웨어인데 요금이 두 배인 이유 #
m8g.large(EC2)가 시간당 약 $0.090, db.m8g.large(RDS MySQL)가 약 $0.168입니다. 차액이 관리 요금입니다. 자동 백업과 특정 시점 복원, 마이너 버전 패치, Multi-AZ 페일오버 오케스트레이션, 스냅샷 관리가 인스턴스 요금에 접혀 들어가 있습니다. EC2에 직접 DB를 올리면 하드웨어 요금은 절반이지만 이 운영을 전부 직접 해야 하므로, 단순 요금 비교는 성립하지 않습니다.
주의할 점은 여기에 더해지는 항목입니다. Multi-AZ는 스탠바이 인스턴스만큼 요금이 두 배가 되고, 스토리지와 프로비저닝드 IOPS는 별도 과금입니다. RDS 스토리지도 gp3가 기본값이 됐고 선택 논리는 EBS와 같으므로 gp3 vs io2의 기준이 그대로 적용됩니다. 백업·운영 쪽 실무는 AWS 중급 #4에서 다뤘습니다.
db.t: 개발용으로는 정답, 프로덕션에서는 시한부 #
db.t4g와 db.t3는 EC2의 t와 같은 버스트 모델입니다. db.t4g.micro가 시간당 약 $0.016으로 가장 싸고, 프리 티어 대상이라 학습·검증용으로는 정답입니다.
프로덕션에서는 이야기가 다릅니다. 애플리케이션 서버의 크레딧 소진은 해당 서버만 느려지지만, 데이터베이스의 크레딧 소진은 그 DB를 보는 모든 서비스의 지연으로 퍼집니다. 트래픽이 늘어 쿼리가 밀리기 시작하는 시점이 곧 CPU가 베이스라인을 넘는 시점이라, 가장 바쁜 순간에 가장 느려지는 구조입니다. db.t로 프로덕션을 버티고 있다면 CPUCreditBalance를 알람으로 걸어 두고, 소진 그래프가 보이는 즉시 db.m으로 옮깁니다.
db.m vs db.r: 버퍼 풀이 가르는 기준 #
| 클래스 | vCPU | 메모리 | 시간당 요금 | 프로파일 |
|---|---|---|---|---|
| db.t4g.micro | 2 | 1GiB | 약 $0.016 | 개발·검증 |
| db.m8g.large | 2 | 8GiB | 약 $0.168 | 범용 |
| db.r8g.large | 2 | 16GiB | 약 $0.239 | 메모리 위주 |
데이터베이스에서 메모리는 버퍼 풀·캐시입니다. RDS MySQL은 기본 설정으로 인스턴스 메모리의 75%를 InnoDB 버퍼 풀에 배정하므로, 클래스의 메모리가 곧 캐시 크기입니다. 자주 읽는 데이터(워킹셋)가 버퍼 풀에 들어가면 읽기가 메모리에서 끝나고, 넘치면 그만큼 디스크 I/O로 흘러넘칩니다.
그래서 판정 지표는 CPU가 아니라 이 흘러넘침입니다. FreeableMemory가 바닥에 붙어 있고 ReadIOPS가 트래픽 증가보다 가파르게 오르면, 워킹셋이 메모리를 넘었다는 신호입니다. 이때 db.m의 크기를 올리는 것과 db.r로 옮기는 것 중에서는 같은 메모리 기준으로 r이 쌉니다. 16GiB가 필요할 때 db.r8g.large가 약 $0.239, db.m8g.xlarge(4vCPU)가 약 $0.336입니다. DB의 CPU가 놀고 있다면 r이 같은 캐시를 7할 요금에 줍니다. 반대로 쓰기 위주라 CPU와 커밋 처리량이 병목이면 m의 크기를 올리는 쪽이 맞습니다.
Graviton 전환: EC2보다 쉽습니다 #
EC2에서 Graviton 전환은 ARM 빌드 확인이 필요했지만(체크리스트 참조), RDS는 사정이 다릅니다. 엔진 바이너리를 AWS가 관리하므로 애플리케이션 쪽에서 바꿀 것이 없습니다. 클라이언트는 전과 같은 프로토콜로 접속할 뿐이라, db.m6i에서 db.m8g로 가는 일은 클래스 변경 한 번입니다. 인텔 클래스(db.m6i 등)를 유지할 이유는 엔진·버전이 Graviton 클래스를 아직 지원하지 않는 경우 정도입니다.
세대 교체도 같은 조작입니다. 클래스 변경은 재시작을 동반하므로 다운타임이 생기지만, Multi-AZ 구성이면 스탠바이를 먼저 바꾸고 페일오버하는 방식으로 중단이 수십 초 수준으로 줄어듭니다. 변경 실무 절차는 AWS 실전 #2에서 다뤘습니다.
선택 순서: 실측이 먼저입니다 #
- 현재 소비량을 잽니다: CloudWatch의
CPUUtilization,FreeableMemory,ReadIOPS·WriteIOPS,DatabaseConnections를 봅니다. 쿼리 단위 병목은 Performance Insights(기본 활성, 7일 무료)로 확인합니다. 튜닝으로 해결될 문제(인덱스 누락, N+1)를 클래스 증설로 덮고 있지 않은지가 먼저입니다. - 환경을 나눕니다: 개발·검증은 db.t4g로 충분하고, 야간·주말 정지까지 걸면 요금이 더 줄어듭니다(상시 점검 목록 참조).
- 프로덕션 클래스를 정합니다: db.m8g에서 시작하고,
FreeableMemory바닥과ReadIOPS급증이 보이면 db.r8g로 옮깁니다. r로도 부족한 초대형 인메모리 요구만 db.x2g 같은 고메모리로 갑니다. - 크기를 정합니다: 버퍼 풀에 워킹셋이 들어가는 최소 메모리를 기준으로 잡고, 작게 시작해 올립니다. Multi-AZ 여부와 스토리지 IOPS는 클래스와 별도로 결정합니다.
- 약정을 겁니다: 장기 운영이 확정된 프로덕션 DB는 리저브드 인스턴스 약정으로 온디맨드 대비 요금을 크게 내립니다. Graviton4 클래스(db.m8g·db.r8g)도 약정 대상입니다.
정리 #
- RDS 클래스는 EC2와 같은 이름 규칙에
db.접두사입니다. 다만 엔진·버전마다 지원 클래스가 달라서, 콘솔의 실제 선택지 확인이 먼저입니다. - 같은 하드웨어라도 관리가 포함되어 EC2의 두 배쯤입니다. Multi-AZ는 다시 두 배, 스토리지·IOPS는 별도입니다.
- db.t는 개발·검증용입니다. 프로덕션 DB의 크레딧 소진은 전 서비스 지연으로 퍼지므로,
CPUCreditBalance알람과 함께 시한부로만 씁니다. - db.m과 db.r은 버퍼 풀로 가릅니다.
FreeableMemory바닥과ReadIOPS급증이 신호이고, 같은 메모리라면 r이 m의 크기 증설보다 쌉니다. - Graviton 전환은 RDS 쪽이 EC2보다 쉽습니다. 앱 변경 없이 클래스 변경 한 번이고, Multi-AZ면 중단도 수십 초 수준입니다.