[12-1] AWS RDS

✔️ RDS

AWS RDS(Relational Database Service)는 Amazon이 제공하는 완전 관리형 관계형 데이터베이스 서비스이다. MySQL, PostgreSQL, Oracle, Aurora 등 여러 엔진을 지원하며 운영에 필요한 인프라 작업에 상당 부분을 대신 처리해준다.

---

✔️ RDS의 주요 이점

RDS를 사용했을 때의 주요 이점은 아래와 같이 정리할 수 있다.

• 자동 백업 & 복원: 자동 스냅샷과 Point-in-Time 복구를 기본으로 제공해 데이터 유실 리스크를 낮춤
• 자동 패치 & 업그레이드: OS 및 DB 엔진 패치를 유지보수 윈도우에 적용해 취약점 대응 부담을 줄임
• 간편한 스케일링: 인스턴스 타입 변경, 스토리지 자동 확장 등을 손쉽게 할 수 있음
• Multi-AZ 고가용성: Multi-AZ 구성으로 가용 영역 장애 시 SLA 수준의 가용성을 손쉽게 확보
• 보안 & 암호화: 저장 데이터 암호화, SSL/TLS 통신, IAM 인증, VPC 격리를 통합 지원
• CloudWatch 통합 모니터링: CPU, 메모리, IOPS, 커넥션 수 등 핵심 지표를 CloudWatch와 연동해 자동 수집

✔️ RDS vs EC2

항목	RDS	EC2
운영 부담	낮음 (패치, 백업, 모니터링 자동화)	높음 (모든 작업 직접 수행)
초기 설정	빠름 (몇 분 내 프로비저닝)	느림 (OS 설정, DB 설치, 튜닝 등 필요)
고가용성	Multi-AZ 기본 옵션으로 간단히 활성화	Replication, Failover 스크립트 구성 필요
비용	높음 (인스턴스 비용 대비 프리미엄 존재)	저렴 (하지만 운영 인건비 고려 시 역전 가능)
커스터마이징	OS 접근 불가, 일부 파라미터만 수정 가능	자유로움 (OS 레벨 튜닝, 플러그인 설치 가능)
백업/복구	자동 스냅샷, 보존 기간 설정 지원	직접 스크립트 작성 및 스케줄링 관리
스케일링	스토리지 자동 확장, Read Replica 간편 추가	수동으로 볼륨 확장, 복제 구성 직접 설정
DB 엔진 선택	지원 엔진 한정	비지원 엔진 설치 가능

 

✔️ RDS가 적합하지 않을 수 있는 상황

일반적으로 RDS를 사용하는 것이 유리하지만, 항상 정답인 것은 아니다. 아래의 상황에서는 EC2 자가 운영이 더 합리적일 수 있다.

• 극단적인 비용 최적화가 필요한 경우
  • 대규모 DB 클러스터에서 RDS의 관리형 프리미엄은 수십만 달러 규모로 불어날 수도 있음. 비용에 민감한 스타트업이나 자체 DBA 역량이 있는 팀이라면 EC2가 유리함.
• OS 수준의 접근 및 커스터마이징이 필요한 경우
  • 특정 커널 파라미터 조정, 전용 스토리지 드라이버 등 RDS가 노출하지 않는 레이어를 건드려야 한다면 EC2 사용이 필수적임.
• RDS가 지원하지 않는 DB 엔진을 사용해야 하는 경우
  • ClickHouse, ScyllaDB, CockroachDB 등 RDS 미지원 엔진을 사용해야 한다면 EC2나 다른 관리형 서비스를 사용해야 함.
• 특수한 규제 및 컴플라이언스 요건이 있는 경우
  • 데이터가 특정 물리 서버에만 존재해야 하거나, AWS가 허용하지 않는 수준의 격리가 필요할 때에는 전용 EC2 환경 또는 온프레미스(기업이나 기관이 클라우드 같은 외부 원격 환경을 빌려 쓰지 않고, 자체 사내 서버실이나 데이터 센터에서 IT 인프라를 구축하고 운영하는 방식)가 요구될 수 있음.
• 극한의 성능 튜닝이 필요한 경우
  • 스토리지 I/O, 네트워크 스텍 등을 직접 제어해야 하는 초고성능 워크로드에서는 RDS의 추상화 레이어가 오히려 병목이 될 수 있음.

---

✔️ 정리

RDS는 가장 합리적인 기본값이다. 당장의 비용 부담이 있지만 운영 부담을 AWS에 위임하고, 개발과 서비스 품질에 집중하는 편이 장기적으로 이득인 경우가 더 많다. 특히 DBA 전담 인력이 없는 소규모 팀이나, 빠른 시장 진입이 중요한 초기 서비스에서는 RDS의 이점이 더욱 두드러진다.

 

반면 전담 DBA 팀이 있고 대규모 인프라를 운영 중이거나, 비표준 DB 엔진/특수 성능 요구사항 등이 있다면 EC2 자가 운영 등의 대안을 검토해야 한다. 즉 어떤 것이 더 나은지의 문제가 아닌, 우리 팀의 역량과 비즈니스 요구에 어떤 것을 선택하는 것이 더 유리한지 고민해보아야 한다.