RDS 엔진 및 인스턴스 클래스

Amazon RDS는 여섯 가지 데이터베이스 엔진을 지원합니다. MySQL, PostgreSQL, MariaDB, 오라클, 마이크로소프트 SQL 서버, 아마존 오로라입니다. 각 엔진은 이미 익숙한 오픈 소스 또는 상용 데이터베이스를 완전 관리형으로 제공하는 버전입니다. AWS가 패치 적용, 백업 및 장애 조치를 처리하므로 애플리케이션 로직에 집중할 수 있습니다.

적절한 엔진을 선택하려면 기존 애플리케이션의 요구 사항, 라이선스 비용, 각 엔진이 제공하는 기능을 고려해야 합니다. 오로라는 성능과 가용성을 위해 설계된 AWS의 클라우드 네이티브 옵션입니다.

MySQL은 세계에서 가장 널리 사용되는 오픈 소스 관계형 데이터베이스로, 웹 애플리케이션과 CMS에 자연스럽게 적합합니다. PostgreSQL은 고급 SQL 표준 준수, 강력한 JSONB 지원, 강력한 확장 기능 생태계를 제공하므로 분석 및 지리 공간 작업에 널리 사용됩니다.

RDS의 두 엔진 모두 자동 백업, Multi-AZ 배포 및 읽기 전용 복제본을 지원합니다. PostgreSQL 읽기 전용 복제본은 리전 간에 배치할 수 있으며, MySQL은 Aurora MySQL을 사용하면 리전 간 복제본을 최대 15개까지 지원합니다.

MariaDB는 커뮤니티에서 개발한 MySQL 파생 엔진으로, 네트워크 프로토콜 수준에서 MySQL 클라이언트와 완전히 호환됩니다. 추가 스토리지 엔진, 일부 작업 부하에서의 향상된 성능, 독점 기능이 없는 개방형 개발 모델을 제공합니다.

RDS에서 MariaDB는 오라클의 MySQL 라이선스를 피하거나 커뮤니티 파생 엔진을 선호할 때 사용할 수 있는 MySQL의 즉시 대체 엔진입니다. MySQL과 동일하게 자동 백업, Multi-AZ 및 읽기 전용 복제본 기능을 지원합니다.

RDS의 오라클 데이터베이스는 License Included (LI)와 Bring Your Own License (BYOL) 모델을 모두 지원합니다. LI는 시간당 요금에 오라클 SE2 라이선스를 포함하며, BYOL을 사용하면 기존 Enterprise Edition 라이선스로 파티셔닝 및 Advanced Security와 같은 기능을 사용할 수 있습니다.

RDS의 마이크로소프트 SQL 서버도 LI 에디션(Express, Web, Standard, Enterprise)과 BYOL을 제공합니다. 두 엔진 모두 동기식 미러링을 사용하는 Multi-AZ를 지원하지만, 오픈 소스 엔진과 동일한 방식으로 읽기 전용 복제본을 지원하지는 않습니다.

아마존 오로라는 MySQL 및 PostgreSQL과 호환되는 클라우드 네이티브 관계형 데이터베이스입니다. 오로라는 세 개의 가용 영역에 걸쳐 분산 스토리지 계층을 사용해 데이터를 여섯 방향으로 자동 복제하므로 동일한 하드웨어에서 MySQL보다 최대 5배 높은 처리량과 PostgreSQL보다 최대 3배 높은 처리량을 제공합니다.

오로라의 스토리지는 10 GB 단위로 최대 128 TiB까지 자동 확장되므로 수동으로 스토리지를 프로비저닝할 필요가 없습니다. 컴퓨팅과 스토리지를 분리하면 Aurora Serverless가 용량을 자동으로 늘리거나 줄일 수도 있습니다.

RDS 인스턴스 클래스는 EC2와 동일한 명명 규칙을 따르지만, 패밀리 문자 앞에 db.가 붙습니다. 주요 패밀리는 다음과 같습니다.

• db.t — 버스트 가능한 성능을 제공하며 개발/테스트에 비용 효율적입니다(예: db.t3.micro, db.t4g.small)
• db.m — 범용 용도로 CPU와 메모리의 균형이 잡혀 있습니다(예: db.m6g.large)
• db.r — 대형 캐시와 메모리 내 테이블에 적합하도록 메모리에 최적화되어 있습니다(예: db.r6g.xlarge)
• db.x — SAP 작업 부하를 사용하는 오라클 및 SQL 서버를 위한 초대형 메모리를 제공합니다

개발에는 db.t, 일반적인 프로덕션 환경에는 db.m, 작업 데이터 집합이 큰 데이터베이스에는 db.r을 선택하세요.

RDS 인스턴스 클래스를 선택하려면 작업 부하의 CPU 사용률, 메모리 사용량, IOPS 요구 사항, 네트워크 대역폭을 프로파일링해야 합니다. AWS Compute Optimizer와 RDS Performance Insights 도구를 사용하면 현재 인스턴스에 리소스가 과도하게 할당되었는지 또는 부족한지 파악할 수 있습니다.

일반적인 패턴은 프로토타이핑을 위해 db.t3으로 시작하고, 부하가 안정되면 db.m6g로 이동한 다음, 더 큰 버퍼 풀이 쿼리에 도움이 될 때 db.r6g로 전환하는 것입니다. Graviton2 기반 인스턴스(db.m6g, db.r6g)는 일반적으로 x86 동급 인스턴스보다 가격 대비 성능이 최대 35% 더 뛰어납니다.

RDS는 내부적으로 EBS 볼륨에 매핑되는 세 가지 스토리지 유형을 제공합니다.

• gp2 / gp3 — 범용 SSD입니다. gp3에서는 스토리지를 더 추가하지 않고도 IOPS와 처리량을 독립적으로 프로비저닝할 수 있습니다
• io1 / io2 — 일관된 1밀리초 미만의 응답 시간이 필요한 지연 시간 민감형 OLTP 데이터베이스를 위한 프로비저닝된 IOPS SSD입니다
• st1 — 처리량 최적화 HDD이며, 특정 엔진과 테스트 작업 부하에서만 사용할 수 있습니다

대부분의 프로덕션 RDS 배포에서는 gp3를 기본값으로 권장합니다. 추가 비용 없이 3,000 IOPS를 제공하며 스토리지 크기와 독립적으로 확장할 수 있기 때문입니다.

RDS는 두 가지 확장 방식을 지원합니다. 수직 확장(인스턴스 클래스 변경)은 Multi-AZ가 활성화되어 있지 않으면 짧은 중단 시간이 필요합니다. Multi-AZ를 사용하면 장애 조치로 크기 조정 중에도 중단 시간을 거의 없앨 수 있습니다. 변경 사항을 다음 유지 관리 기간에 적용하도록 예약하거나 즉시 적용할 수 있습니다.

수평 확장은 읽기 전용으로만 가능합니다. 기본 인스턴스에서 SELECT 쿼리를 분산하려면 읽기 전용 복제본을 추가합니다. 읽기 전용 복제본은 비동기식 복제를 사용하므로 약간의 복제 지연이 발생하며, 애플리케이션은 이를 허용해야 합니다.

Aurora와 커뮤니티 MySQL/PostgreSQL 중에서 선택할 때는 다음과 같은 장단점을 고려하세요.

• Aurora: 더 높은 처리량, 6방향 자동 복제, 빠른 장애 조치(약 30초), 수동 스토리지 관리 불필요, 더 높은 시간당 비용
• MySQL/PostgreSQL: 더 낮은 비용, 더 폭넓은 커뮤니티 확장 기능, BYOL 옵션, 익숙한 운영 도구

시험 시나리오에서는 문제에서 고가용성, 자동 스토리지 확장 또는 오픈 소스 가격으로 상용 데이터베이스에 가까운 성능을 강조할 때 Aurora가 선호됩니다. 비용 최소화 또는 온프레미스 환경과의 기능 동등성이 우선순위라면 커뮤니티 엔진이 더 적합합니다.

RDS는 마이너 버전 업그레이드(예: MySQL 8.0.32 → 8.0.36)와 메이저 버전 업그레이드(예: MySQL 5.7 → 8.0)를 구분합니다. --auto-minor-version-upgrade를 활성화하면 유지 관리 기간에 마이너 업그레이드가 자동으로 적용되도록 설정할 수 있습니다. 메이저 업그레이드는 수동으로 진행하며 애플리케이션 호환성 테스트가 필요할 수 있습니다.

메이저 버전 업그레이드는 항상 먼저 스테이징 환경에서 테스트하세요. 업그레이드 전에 DB 스냅샷을 생성하면 문제가 발생했을 때 롤백할 수 있습니다. Aurora 클러스터는 중단을 최소화하면서 제자리 메이저 버전 업그레이드를 지원합니다.

이 단원에서 다룬 AWS 솔루션스 아키텍트(SAA-C03) 개념에 대한 이해도를 확인해 보세요.

이 단원에서는 다음을 배웠습니다. RDS는 여섯 가지 엔진을 지원합니다(MySQL, PostgreSQL, MariaDB, 오라클, SQL 서버, Aurora). 인스턴스 클래스는 작업 부하 프로필에 대응합니다(개발/테스트에는 db.t, 범용 작업에는 db.m, 메모리 집약적 작업에는 db.r). 또한 Aurora는 커뮤니티 엔진보다 뛰어난 처리량과 자동 스토리지 확장을 제공합니다. 다음에는 고가용성을 위한 Multi-AZ 배포와 자동 백업을 살펴보겠습니다.