[AWS] RDS(Relational Database Service) vs AuroraDB (feat. MySQL, PostgreSQL)

1. RDS(Relational Database Service)란?

1) 정의

클라우드에서 배포,설치,패치,백업을 쉽게만드는 관계형 DB를 관리된 SQL DB로 서비스한다.(아마존 클라우드에서 관계형 데이터베이스를 사용할 수 있는 서비스)Aurora, MySQL,PostgreSQL,MariaDB,Microsoft SQL Server 그리고 Oracle DB 엔진을 지원한다.

(Aurora가 포함되는 개념)

---

2) 특징

• RDS 구축 형태
  
  • 기존 데이터베이스 아키텍처를 중심으로 완전히 관리되는 추상화 계층을 제공
  • RDS 내에서 데이터베이스 플랫폼은 EC2에서 수동으로 수행하는 것처럼 구축
  • EC2인스턴스는 적절한 Amazon Machine Image (AMI)에서 프로비저닝 되고, EBS(Elastic Block Store)스토리지는 프로비저닝된 인스턴스에 연결
  • 적절한 서브넷 그룹과 보안그룹이 인스턴스에 연결되는 구조
  • 단 몇번의 버튼 클릭만으로 데이터베이스 플랫폼을 안전하고 성능있는 방식으로 프로비저닝 할 수 있음
  • 프로비저닝되면 RDS는 백업/복원 및 패치가 모두 자동으로 처리되어 플랫폼 유지관리가 자동으로 이루어짐
• 각 DB 인스턴스당 익숙한 MySQL, MairaDB, PostgreSQL, Oracle 및 Microsoft SQL server DB 엔진 사용 가능
• VPC를 사용하여 가상 사설 클라우드에서 인스턴스 실행 가능
• 다중 AZ(Available Zone): 데이터 중복 및 장애 조치 지원,다른 가용 영역에서 자동으로 프로비저닝하고 유지하는 기능
• 리전 복구에 몇 시간 걸림
• RDS 자체적으로 오토스케일링을 지원하기 때문에, 오토스케일링 그룹에 배치할 필요없음
• RDS SQL Server를 제외하고는 리전 간 Read Replica를 지원함
• Automated Backup
  • RDS의 자동백업기능. 개별 DB를 백업하는 것이 아닌, DB인스턴스 전체를 백업함
  • 매일매일 백업하고 기본 보존기간은 CLI로 생성시 1일, 콘솔로 생성시 7일, 최저 1~35일까지 가능. 그 이상의 기간을 사용하려면 AWS Backup 사용해야함
  • 특정 시점으로 복원가능, 복원기간내로부터 최근 5분까지 특정시점을 지정하여 복원가능
  • 사용자가 지정한 백업시간에 자동백업. 백업 중 스토리지 I/O 일시적 중단 가능.
  • Multi-AZ사용시 Standby에서 백업 실시
• RDS 데이터베이스로 마이그레이션
  • 전환 준비가 될 때까지 대상에서 백업과 다중 AZ를 끄는 것이 좋음
  • Amazon RDS 이외의 시스템으로 마이그레이션할 때는 일반적으로 컷오버 이후까지 타겟에 대한 로깅을 해제하는 것이 좋음

---

[가용 영역과 RDS instance, stroge의 관계]

---

2. AuroraDB란?

1) 정의

완전관리형 MySQL, PostgreSQL 호환 관계형 DB

---

2) 특징

• AWS만의 관계형 데이터베이스로써 기존의 소스를 커스터마이징하여 AWS에 최적화 시킴
• 기존 RDS의 모든 관리 기능 뿐만 아니라 데이터베이스에 최적화된 스토리지 하위 시스템을 제공하여 RDS 플랫폼을 확장
• RDS에서 사용하는 EBS 스토리지 대신 NVMe SSD 드라이브 위에 구축되어 훨씬 빠른 성능 이점을 제공
• Auto Sacling: 자체적으로 지원하지않고 오로라 복제본을 사용
• Amazon Aurora Serverless
  1. Amazon Aurora의 온디맨드 Auto Scaling 구성, 애플리케이션 요구 사항을 기반으로 자동으로 시작 및 종료하고 용량을 확장 또는 축소
  2. 데이터베이스 용량을 관리하지 않고도 클라우드에서 데이터베이스를 실행할 수 있음(컴퓨팅 노드가 얼마나 필요한지 생각할 필요가 없음)
  3. 데이터가 확장에 관계없이 공유 스토리지 볼륨에 남아 있음
• 타DB 대비 Aurora특징
  1. Aurora MySQL 병렬 쿼리 클러스터 => 쿼리 옵티마이저가 판단하여 자동결정
  2. DB복제, DB backtracking, DB 활동 모니터링
  3. Aurora Serverless 클러스터 => AutoScaling
  4. Aurora 머신러닝 => Amazon SageMaker, Amazon Comprehend 
  5. Aurora MySQL 멀티 마스터 클러스터 => 액티브-패시브 워크로드 or 액티브-액티브 워크로드

[Aurora 다중 마스터 vs 단일 마스터]
다중 마스터 클러스터의 모든 노드가 읽기/쓰기 노드이므로 Aurora 다중 마스터는 단일 쓰기 마스터를 가진 Aurora 보다 더 높은 가용성을 제공합니다. 단일 마스터 Aurora를 사용하면 단일 쓰기 노드가 실패하면 읽기 전용 복제본을 새 쓰기 마스터로 승격시켜야하고, 이 시간 동안 가용성이 확보되지 않습니다. 대신 Aurora 다중 마스터의 경우, 특정 쓰기 노드가 실패하면 다른 쓰기 노드에 대한 연결을 열면 됩니다.

[Aurora 글로벌 DB]
Aurora 글로벌 DB는 글로벌하게 분산된 앱을위해 디자인됐고,
데이터를 복제하지 않고 단일 Amazon Aurora 데이터베이스를 여러 AWS 지역에 걸쳐 사용할 수 있습니다.

---

[가용 영역과 aurora instance, stroge의 관계]

Aurora는 RDS의 Primary-Secondary-Read Replica 개념이 아니라 Primary-Replica 개념으로 Replica들이 Secondary 역할까지 함

---

3. RDS(Relational Database Service) vs AuroraDB

•  스토리지 - AWS Aurora는 Shared Storage를 사용하며 MySQL의 경우 Binlog 기반의 Replication이 아닌 Storage와 Page 기반의 Replication을 사용합니다.

구분	Aurora	RDS
아키텍처 디자인	1.신뢰할 수 있고, 결함에 관대한 설계 2.인스턴스와 분리된 스토리지 3.1개의 인스턴스에 6개의 복사본이 3개의 가용영역에 나뉘어 있음	1. EC2에 DB 엔진 설치하는 것과 비슷하지만 배포와 유지는 AWS가 해줌 2. 자동 failover, 백업 등을 제공 3. RDS는 database랑 log 스토리지로 EBS 볼륨을 사용함 4.신뢰성을 얻기위해 다중 가용지역 기능을 활성화 해야 함(다른 가용지역의 standby 복사본에 동기적으로 복사함)
성능	1.RDS보다 성능이 더 좋고 일관적임 2.log 버퍼 없이 log를 스토리지에 직접 씀 3. 비슷한 하드웨어를 기준으로 PostgreSQL보다 2배의 처리 성능을 보여주고, MySQL보다 5배 좋은 처리 성능을 보여줌 4. 복제본에 대한 복제는 캐시된 데이터에 한에 비동기적으로 복제함(복제본은 같은 스토리지 클러스터를 공유하기 때문 → 복제본의 지연은 적고, 시간이 갈수록 일관성 있게 됨) 5. 부하가 증가할 때 성능이 더욱 눈에 띔	1. 더 나은 입출력 처리 성능을 위해 SSD 스토리지를 사용 2. 높은 성능의 OLTP 앱을위해 최적화 됨 3. 비용 효율적인 일반적인 사용에 좋음
지원하는 DB엔진	PostgreSQL,MySQL	MySQL,PostgreSQL,MariaDB,Microsoft SQL Server, Oracle
가용성과 지속성	1. RDS보다 높은 가용성과 지속성을 제공(특별한 스토리지 모델 때문에) 2. 지속적 백업과 회복(아주 낮은 *RPO)이 뛰어남 3. 1개의 인스턴스당 6개의 스토리지 노드가 3개의 가용영역에 걸쳐서 있음(가용성이 좋음)	읽기 복제본을 많이 늘려야 가용성이 보장됨
탄력성	1. RDS보다 더 탄력적임(아키텍처 설계 상) 2. failure로 부터 빠른 회복이 가능(컴퓨팅 노드의 충돌 같은 케이스) 3. 새로운 읽기 복제본을 최소한의 지연으로 시작 가능 4. 쓰기 복제본이 fail하게 될 시, 다른 복제본이 쓰기의 역할을 할 수 있게끔 역할이 자동으로 바뀜 5.데이터 노드에 모든 공유되는 상태가 저장됨(fail 됐을 시 즉각적으로 대체 가능)	복제본을 여러 가용영역에 많이 늘려야 탄력성이 보장됨
스토리지	1. 최소 10GB 부터 최대 128TiB까지 자동으로 증가 가능 2. 증가될 때, 데이터베이스 성능에 영향을 주지 않고 10GB 단위로 수행됨, 필수 항목은 아님	1.스토리지 수용량을 64TiB까지 자동으로 늘려줌(SQL Server만 16TiB)(다운되는 시간 없이) 2. 원하는 최대 스토리지 임계점을 지정하기만 하면 됨
확장성	수직적 확장: 메모리와 컴퓨팅 자원을 몇 번의 클릭으로 244GiB의 RAM과 32vCPU까지 확장시켜줌
	동적 확장: 갑작스러운 작업 혹은 부하의 증가에 대비해 자원(컴퓨팅,복제본)의 auto scaling이 가능함	동적확장을 지원하지 않음
복제	1. 15개의 복제본까지 배포 가능 2. 수 밀리초만에 배포 가능함(공유 스토리지 볼륨을 사용하기 때문)  3. 새로운 복제본이 쿼리를 즉각적으로 서빙할수 있음	1. 5개의 복제본까지 배포 가능 2. 복제하는 과정이 오로라에 비해 더 느림
Failover	읽기 복제본에 대한 failover가 자동으로 수행되고 데이터 손실을 방지함	읽기 복제본에 대한 failover가 수동으로 수행되므로 데이터가 손실될 수 있음
Cluster Endpoints	1. Aurora에서는 cluster endpoint 사용 가능 2.읽기 복제본에 대한 로드 밸런서 엔드포인트를 제공 3.failover의 경우 읽기 복제본 중 하나는 마스터 집합에서 제거 됨	1.RDS에는 쓰기 쿼리에 사용하는 cluster endpoint 있음 2. 현재 마스터 DB 인스턴스를 가리키는 DNS endpoint 3.failover 중에 RDS는 간단한 DNS 변경을 통해 이 endpoint를 새 마스터로 라우팅 4. 읽기 복제본의 경우 인스턴스 endpoint를 사용하여 응용프로그램의 로드 균형을 조정해야 함 5. RDS는 읽기 복제본에 대한 로드 밸런서를 제공하지 않음
Backup	1.클러스터 볼륨을 자동으로 백업하고 회복된 데이터를 얻게 됨 2.지속적이고 증가 되므로 보유하고 있는 백업 포인트로 빠르게 회복할 수 있음 3. 백업데이터가 써지는 동안 어떠한 역효과나 방해가 DB 서비스에 생기지 않음	1. DB인스턴스의 백업 윈도우를 DB인스턴스가 자동화된 백업으로 생성하고 저장함 2. 보유하는 백업 기간으로 다시 회복할 수는 있지만, 스토리지 입출력은 영향 받을 것이고, 데이터베이스 성능에 영향을 줌
가격	RDS보다 비쌈(인스턴스 크기와 스토리지의 실제사용에 따라 가격이 책정됨)	Aurora 보다는 쌈

*RPO(Recovery Point Objective)
복구 시점 목표는 특정 시점, 즉 재해, 장애 또는 계획되지 않은 데이터 손실 이벤트가 발생한 순간부터 손실될 수 있는 허용 가능한 최대 볼륨/데이터 양으로 정의됩니다. 시간. RPO는 재해가 발생하기 전에 경과 시간부터 데이터가 성공적으로 복구될 수 있는 마지막 시점까지의 백업 사이에 회사가 허용할 수 있는 손실 가치가 있는 데이터의 최대 기간을 지정합니다.