[AWS] RDS

RDS(Relational Database Service)

• 클라우드 환경에서 관계형 데이터베이스를 간편하게 설정, 운영 및 확장 할 수 있음
• 하드웨어 프로비저닝, 데이터베이스 설정, 패치 및 백업과 같은 시간소모적인 관리작업을 자동화하면서 비용 효율적이고 크기 조정이 가능한 용량을 제공한다.
• 사용자가 애플리케이션에 집중하여 애플리케이션에 필요한 빠른 성능, 고가용성, 보안 및 호환성을 제공할 수 있도록 지원한다.

RDS의 아키텍쳐

• 내부적으로 EC2와 EBS를 사용
• EC2에서 배웠던 보안그룹, 서브넷, VPC 등 모두 적용
• VPC안에 Availability zone 안에 있다.

RDS의 특징

1. 관계형 데이터베이스를 제공하는 서비스

cf) noSql (DynamoDB, DocumentDB, ElasticCache)

2. 가상머신 위에서 동작

단, 시스템에 직접 로그인 불가능 --> OS패치, 관리 등은 AWS 역할

3. Serverless 서비스가 아님

단, Aurora Serverless는 Serverless가 맞음

4. CloudWatch와 연동

1) DB 인스턴스의 모니터링 (EC2와 동일)

2) DB에서 발생하는 여러 로그 (Error Log, General Log 등)를 CloudSatch와 연동하여 확인 가능

5. 내부에서는 EC2를 활용

1) VPC안에서 동작

• 기본적으로 public IP를 부여하지 않아 외부에서 접근 불가능
• 설정에 따라 public으로 오픈 가능(DNS로 접근)

2) 서브넷과 보안그룹 지정 필요

3) EC2타입의 지정 필요

4) 스토리지는 EBS 활용

• EBS타입의 선택 필요
• 생성시 EBS의 용량을 지정해서 생성
  cf) Aurora는 용량지정X, 사용한만큼만 비용 지불

6. Paramater Group

• Root 유저만 설정 가능한 DB의 설정값들을 모아 그룹화한 개념
• DB 클러스터에 파라메타그룹을 적용시켜 설정값 적용

7. 업데이트

• 마이너버전 엔진 업데이트는 자동으로 업데이트 설정 가능
• 기타 업데이트의 경우 점검시간(Maintenance Window)을 설정하여 특정시간에 업데이트가 이루어질 수 있도록 설정 가능

RDS의 인증방법

1) 전통적인 유저/패스워드 방식

• AWS Secret Manager와 연동하여 자동 로테이션 가능
• AWS Secret Manager는 여러가지 인증을 관리해주는 서비스
  : 일정주기마다 자동으로 패스워드를 변경해주기도 하고 다른 서비스들이 RDS나 다른 서비스에 접근할 때 패스워드를 하드코딩 할 필요없게 해주는 서비스?

2) IAM DB 인증

• 데이터베이스를 IAM 유저 크레덴셜/Role을 통해 관리 가능

3) Kerberos 인증

• 마이크로소프트의 액티브 디렉토리 안에 포함되어있는 프로토콜
• 네트워크 상에 직접 아이디/패스워드를 입력하지 않아도 되게끔 만들어주는 대칭키 기반의 프로토콜

RDS의 가격모델

• 컴퓨팅 파워 + 스토리지 용량 + 백업 용량 + 네트워크 비용
• Reserved Instance 구매가능
  --> EC2와 마찬가지로 일정기간을 계약하여 저렴한 가격에 서비스를 이용

RDS에서 제공하는 DB엔진

RDS의 암호화

• SQL 서버 또는 Oracle에서는 TDE(Transparent Data Encryption) 지원
• 모든 엔진에서 EBS 볼륨 암호화 지원
  : Default Master Key(로테이션 직접 조정X) 또는 생성한 Master Key(로테이션 직접 조정O) 선택 가능
• 자동 백업, 스냅샷, Read Replica 등에 적용됨

RDS의 백업

1. 자동 백업

• 매일마다 스냅샷을 만들고 트랜잭션 로그를 저장
• 데이터는 S3에 저장되며 데이터베이스의 크기 만큼의 공간 점유
• 저장된 데이터를 바탕으로 일정기간 내의 특정시간으로 롤백 가능
  : 기존 DB를 롤백하는 것이 아니라, 다른 DB클러스터를 새로 생성
• 1~35일까지 보관 지원
• 백업을 시행할 때는 약간의 딜레이 발생 가능성O
  : 그나마 Multi-az로 하면 Standby를 통해 백업을 수행하기 때문에 딜레이가 덜함
• 기본적으로 사용상태로 설정되어있음

2. 수동 백업(DB스냅샷)

• 유저 혹은 다른 프로세스로부터 요청에 따라 만들어지는 스냅샷
• 데이터베이스가 삭제 된 후에도 계속 보관
• 스냅샷의 복구는 항상 새로운 DB Instance를 생성 하여 수행
• 만약 데이터베이스를 복구해야 한다면, 새로운 DB를 만들고 기존DB의 연결을 끊고 새로만든 DB에 연결해주는 작업이 필요

RDS Multi AZ

• 두개 이상의 AZ에 걸쳐 데이터베이스를 구축하고 원본과 다른 DB(Standby)를 자동으로 동기화(Snyc)
  1) SQL Server, Oracle, MySql, PostgreSQL, MariaDB에서 지원
  2) Aurora의 경우 다중AZ를 설계단계에서 지원
• 원본 DB의 장애 발생 시 자동으로 다른 DB가 원본으로 승격 됨 (DNS가 Standby DB로)
• Standby DB는 접근 불가능
• 퍼포먼스의 상승 효과가 아닌 안정성을 위한 서비스
• 비용이 2배가 듬

1) 일반적인 경우 DNS 주소로 RDS Primary 인스턴스에 접속하게 됨

• 이경우 다른 AZ에 있는 RDS Standby 인스턴스로는 접속 불가
  : DNS가 부여되지 않음

2) RDS Primary에 장애가 발생

• 자동으로 DNS를 Standby 인스턴스로 연동을 해준다.
• 그리고 기존에 RDS Primary와의 연결을 끊어준다.
• 이것을 fail over(fail났을 때 복구하는 과정)라고 함
• 동일한 address로 바라보고 있기 때문에 EC2입장에서는 장애를 느끼지 못함
• 굉장히 빠른 속도로 장애복구 가능O

Read Replica(읽기 전용 복제본)

• 원래 데이터베이스의 읽기 전용 복제본을 생성(Async)
• 쓰기: 원본 데이터베이스 / 읽기: 복제본에서 처리 ==> 워크로드 분산
• MySql, PostgreSQL, MariaDB, Oracle, Aurora에서 지원
• 안정성이 아닌 퍼포먼스를 위한 서비스
• 총 5개까지 생성 가능
• 각각의 복제본은 고유 DNS가 할당 됨 ==> 접근 가능
• 원본 DB의 장애 발생 시 수동으로 DNS 변경이 필요함
• 복제본 자체에 Multi-AZ 설정 가능(MySql, PostgreSQL, MariaDB, Oracle)
• Multi-AZ DB에 Read Replica 설정 가능
• 자동 백업이 활성화 되어있어야 읽기 전용 복제본 생성 가능
• 각 DB의 엔진 버전이 다를 수 있음

* Read Replica(읽기 전용 복제본)도 서로 다른 인스턴스 구성을 할수있다.

• 일반적인 Read Replica 구조에서
  

• 복제를 끊고, 독립적인 클러스터 구성O
  

RDS Multi Region

• 다른 리전에 지속적으로 동기화 시키는 DB 클러스터 생성
• Async 복제
• 예를 들어 유럽 국가에 서비스를 한다고 가정하자. 서울에 마스터 리전을 두고 유럽에 Read Replica를 둔다면 유럽 현지에서는 Read Replica로 읽기 때문에 latency(지연시간)가 줄어든다. 우리나라에서는 RR에 복제만 해주면 된다.
• 주로 로컬 퍼포먼스 또는 DR(disaster recovery)시나리오로 활용
• 로컬 퍼포먼스: 그 지역에 있는 사람들이 빨리 읽을 수 있게 해줌
• DR(disaster recovery)시나리오 : 만약 서울에 폭탄이 터져서 리전이 fail이 된다면 다른리전을 마스터로 만드는 구성
• 각 리전별로 자동 백업 가능
• 리전별로 Multi-AZ 가능

참고

• https://www.youtube.com/watch?v=koDIV5QMw38&list=PLfth0bK2MgIa6w63IglYQD_qljDntSh-H&index=11