[AWS] Developer Associate #2 Relational DB(RDS, Aurora)

RDB(Relational Database)란?

• RDB는 관계형 데이터베이스라고 하며 데이터를 테이블(Table)로 구성하고 관리하는 시스템으로 테이블 간의 관계(Relation)을 정의하고 SQL(Structured Query Language)를 사용하여 데이터를 쿼리하고 조작할 수 있습니다.
• RDB에서 테이블이란 데이터의 집합으로 각 테이블의 열(Column)은 데이터의 속성(Attribute)을 나타내고 테이블의 행(Row)는 데이터의 레코드(Record)를 나타냅니다.
  예를 들어 고객 정보 테이블에서 ‘이름, 나이, 주소’는 데이터의 속성을 나타내고 ‘홍길동, 26, 수원시’는 데이터의 레코드로 여러 가지 데이터 속성들의 값을 포함합니다.
• AWS의 대표적인 RDB 서비스로 Amazon RDS(Relational Database Service)가 있습니다.

RDS란?

• Amazon RDS란 관계형 데이터베이스(Relational Database Service)로 DB 프로비저닝과 자동 백업, OS 패치, 모니터링을 제공합니다.
• RDS는 DB 엔진으로 MySQL, MariaDB, Oracle, Postgres, Microsoft SQL Server, Db2, Aurora(AWS에서 지원하는 엔진) 를 지원합니다.
• RDS DB Instance는 DB 엔진을 실행하는 가상 서버로 사용자가 직접 SSH로 접근할 수 없으며 OS 제어가 불가능합니다.
• RDS의 DB Instance는 VPC에 생성하고 스토리지로 Amazon Elastic Block Store(Amazon EBS) 볼륨을 사용합니다.
• DB instance identifier(식별자)는 고객이 지정하는 DB instance의 이름으로 동일한 AWS 계정과 리전 내에서는 중복되지 않아야 합니다.

Aurora란?

• Amazon Aurora는 MySQL 및 PostgreSQL과 호환되는 관계형 데이터베이스 엔진으로 AWS에서 만들었습니다.
• Aurora는 관리형 데이터베이스 서비스인 Amazon Relational Database Service(Amazon RDS)의 일부입니다.
• Aurora은 기존 애플리케이션을 거의 변경하지 않고도 MySQL의 처리량을 최대 5배, PostgreSQL의 처리량을 최대 3배 제공할 수 있습니다.
• Aurora는 데이터베이스를 구성하고 관리하는데 가장 어려운 측면 중 하나인 데이터베이스 클러스터링 및 복제를 자동화하고 표준화합니다.
• Aurora DB 클러스터는 1개 이상의 DB 인스턴스와 데이터를 관리하는 클러스터 볼륨으로 구성됩니다.
• Aurora DB 클러스터에서 Primary 인스턴스 및 Replica는 클러스터 볼륨 데이터가 단 1개의 논리 볼륨(클러스터 볼륨)으로 표시됩니다.
• Aurora 클러스터 볼륨은 3개의 AZ에 6개의 데이터 복사본을 갖습니다.
• 클러스터 볼륨에 데이터를 쓰는건 Primary instance만 가능합니다.
• 일반적으로 Auroa는 RDS에 비해 비용이 20% 정도 비쌉니다.

RDS의 Storage Auto Scaling

• Storage Autoscaling(스토리지 자동 크기 조정)은 DB 인스턴스의 여유 공간이 부족한 것을 감지하면 자동으로 스토리지를 확장하는 기능입니다.
• 워크로드 예측할 수 없는 애플리케이션에게 상당히 유용한 기능입니다.
• 스토리지를 확장하기 위해 DB를 중단하는 등의 어떤 작업도 할 필요가 없습니다.
• RDS는 Storage Auto Scaling 기능을 활성화해야 하지만 Aurora는 별도로 Storage Auto Scaling 기능을 활성화하지 않아도 Storage가 자동으로 확장됩니다.

RDS와 Aurora의 Read replica

• Read replica(읽기 전용 복제본)은 Primary DB 인스턴스의 읽기 워크로드를 분산하는 방법입니다.
• RDS의 Read replica는 Primary DB 인스턴스와 비동기 복제(Asynchronous replication)됩니다.
• Aurora Replica(읽기 전용 복제본)은 Primary 인스턴스와 동일한 기본 스토리지를 공유하므로 데이터를 Replica 노드에 복사할 필요가 없습니다.
• Aurora는 Primary와 Replica가 논리적으로 동일한 볼륨을 사용하기 때문에 Primary가 문제가 생기면 Replica로 Fail-over(장애조치) 할 수 있습니다.
• RDS의 read replica는 동일한 AZ, 다른 AZ, 다른 region에 생성할 수 있습니다.

RDS와 Aurora의 Multi-AZ

• RDS Multi-AZ DB instance deployment(다중 AZ DB 인스턴스 배포)
  • Primary DB instance와 Stanby DB instance를 각각 다른 AZ에 배포하는 옵션입니다.
  • HA(고가용성)와 Data redundancy(데이터 중복성)를 제공하지만 Standby DB instance는 읽기 워크로드에 대한 connection을 지원하지 않습니다.
  • Primary DB instance와 Stanby DB instance 간에는 Synchronous replication이 이루어집니다.
  • Primary DB instance에 장애가 발생하면 자동으로 다른 AZ의 Stanby로 전환됩니다. 일반적으로 60초에서 120초 정도의 시간이 걸립니다.
• RDS Multi-AZ DB Cluster(다중 AZ DB 클러스터)
  • Primary DB instance 1개와 Readable standby DB instance 2개로 구성된 클러스터를 배포하는 옵션으로 각 DB 인스턴스는 서로 다른 AZ에 배포됩니다.
  • HA와 Data redundancy를 제공하고 Standby DB instance도 읽기 워크로드를 처리합니다.
  • DB 엔진의 네이티브 복제 기능을 사용하여 Primary DB instance의 데이터를 Readable Standby DB instance로 복제합니다.
  • Semisynchronous(반동기식) 고가용성 배포 모드입니다.
• Aurora의 Multi AZ
  • Aurora는 Cluster Volume을 공유하기 때문에 replica(읽기 전용 복제본)을 사용하는 것이 Multi AZ를 구성하는 방법입니다.
  • Aurora는 Primary 인스턴스에 문제가 생기면 Replica를 Primary로 승격시키거나 새로운 Primary 인스턴스를 만들어 장애를 해결합니다.
  • Replica를 승격시키는 경우의 복구 시간은 60초 미만이고 새로운 인스턴스를 만드는 경우 10분 미만의 시간이 걸립니다.

RDS Proxy란?

• RDS Proxy는 RDS DB Write instance에 대한 connection pooling을 수행합니다.
• 일반적으로 DB와 같은 리소스에 connection을 맺는 것은 오버헤드가 많이 들어가는 작업입니다. connection pool은 오버헤드를 줄이기 위해 connection을 미리 생성하여 관리하는 방식입니다.
• RDS Proxy는 DB connection pool을 설정하고 이 pool에서 connection을 재사용합니다. 이를 통해 매번 새 DB connection을 만드는 데에서 오는 메모리 및 CPU 오버헤드를 방지합니다.
• RDS Proxy를 사용하면 idle 상태를 유지하는 connection을 닫았다가 만드는 로직을 추가할 필요가 없습니다.
• RDS Proxy는 예상하지 못한 트래픽 급증을 대응할 수 있습니다.
• 기본적으로 RDS Proxy는 세션에서 각 트랜잭션 후에 연결을 재사용할 수 있습니다. 이 트랜잭션 수준 재사용을 멀티플렉싱이라고 합니다.