Database types

• RDBMS(SQL/ OLTP(OnLine Transaction Processing): RDS, Aurora
  - RDS: Postgres, MySQL, MariaDB, ...
  - Aurora: 엔터프라이즈급 데이터베이스
  - 웹사이트에 제공하기 좋으며 join을 많이 하는 경우, 정규화된 데이터인 경우에 적합하다.
• NoSQL: DynamoDB(Jason like), ElastiCache(key/ value pairs), Neptune(Graphs)
  - join을 하지 않으며 SQL을 사용하지 않는다.
• Object Store: S3(object 당 5 terabytes까지 저장 가능(RDS는 400KB까지 저장)), Glacier(backup 또는 archive용으로 사용)
  - 데이터베이스처럼 보이지는 않지만 실제로는 데이터베이스가 맞다. 왜냐하면 데이터를 저장하고 가져오는 용도로 사용하고 있기 때문이다.
  - 한 객체의 크기가 매우 큰 경우 S3를 이용하는 것이 좋다.
• Data Warehouse(SQL analytics/ BI): Redshift(OLAP(OnLine Analytic Processing)), Athena(S3를 쿼리할 때 사용)
• Search: ElasticSearch(JSON)
  - 자유 텍스트 및 비정형화된 검색에 사용하기 좋으며 많은 쿼리와 검색 능력을 가지고 있다.
• Graphs: Neptune
  - 데이터 간의 관계를 보여주는 데 사용한다.
  

Database 타입 별 특징

RDS

• RDS의 백엔드에서는 EC2 인스턴스를 프로비저닝 하고 EBS volume 타입과 사이즈를 정해서 사용한다.
  - 사용자가 해당 EC2에 직접 접근할 수는 없다.
• Read Replica와 multi AZ를 제공한다.
  - Read Replica는 읽기를 확장하는 데 사용한다.
  - Multi-AZ는 재난 극복에 사용할 수 있다.
• 여러 보안을 사용할 수 있다.
  - IAM
  - 보안 그룹
  - KMS
  - 전송중 암호화(SSL)
• 백업/ 스냅샷/ 특정 시점 복원 기능을 제공한다.
• 관리 및 스케줄링 된 유지 보수 작업을 지원한다.
• CloudWatch를 이용한 모니터링이 가능하다.

Solutions Architect 관점에서 보기

운영 관점

• 장애 극복 기능 사용시 다운타임이 적다.
• 읽기, 즉 ec2 instance를 조정하면 EBS는 복원되며 이 때는 수동 개입이 필요하다.
  - 즉, 약간의 작업을 해야 한다.
  

보안 관점

• AWS가 자체적으로 os 보안을 책임지지만 사용자가 직접 KMS 세팅 또는 IAM 정책, 인바운드 설정, SSL 암호화 등을 해야 한다.

신뢰성 관점

• multi-AZ를 지원하기 때문에 장애 극복이 가능하다.

성능 관점

• EC2 instanc를 백엔드로 사용하기 때문에 인스턴스 타입에 따라, 그리고 EBS volumes 타입에 따라 성능이 달라진다.
• 크기를 조정하고 읽기 능력을 향상시키고 싶은 경우 read replica를 추가하면 된다.
• 저장 공간 auto-scaling 기능이 있어서 EBS volume이 클수록 더 많은 저장 공간을 사용할 수 있다.
• 만약 인스턴스 사용량을 늘리려면 인스턴스를 수동으로 확장해야 한다.

비용 관점

• 프로비저닝 된 EC2 타입과 EBS 볼륨 타입에 따라 시간 단위로 지불한다.

RDS backups

• RDS는 자동으로 백업을 지원해 준다.
• 자동 백업 덕분에 과거 어느 시점이든 복원이 가능함(~5분 전까지)
  - 매일 데이터베이스 전체 백업(유지 관리 기간 동안)이 진행되며 원하는 시간대(window)를 지정할 수 있다.
  - 트랜잭션 로그 백업(5분 마다)
  - 7일 동안 보관(35일까지 설정 늘릴 수 있음)
• 스냅샷 생성
  - 유저 설정에 의해 수동으로 진행된다.
  - 원하는 기간 동안 보관이 가능하다.
  
  

RDS Storage Auto-scaling

• 남는 저장 공간이 없을 경우 RDS가 이를 감지해 자동으로 저장 공간을 확장한다.
• 이를 위해서는 최대 저장 공간 threshold(한계치)를 설정해야 한다.
  - 한계치 이상 저장 공간이 늘어나지 못하도록 하는 것이다(무한대가 되도록 할 수는 없으니까).
• 만약 저장 공간 상태가 아래와 같은 조건 동안 유지되었다면 auto-scaling이 진행 된다.
  - 만약 할당된 저장 공간에서 남는 공간이 10% 이하라면,
  - 이 상태가 5분 이상 지났다면
  - 마지막 수정 이후 6시간이 지났다면
• 모든 RDS 데이터베이스 엔진에서 지원되는 기능이다.

Read replicas vs Multi-AZ

Read replicas 확장

• 5개까지 확장 가능하다.
• AZ 내에, 여러 AZ, 또는 여러 리전에 read replicas를 확장할 수 있다.
• read replicas가 확장 되어 여러개 생성 되면 Master로부터 read replica에 비동기적 복제가 일어난다.
  - 그런데 만약 read replica 복제가 다 일어나지 않은 상태에서 application으로부터 읽기 요청이 들어 온다면 이 경우 모든 데이터를 얻게 될 것이다.
  - 그렇기 때문에 결과적으로는 일관적인 비동기 복제라 일컬어 지는 것이다.
• read replicas는 각각의 database로 promotion 된다.
  - 즉, read replicas 또한 하나의 데이터베이스가 되어 Master로 작동하게 된다.
  - 그러면 application은 RDS 클러스터에 있는 모든 read replica 리스트를 사용하기 위해서 connection string을 업데이트 해놔야 한다.
• read replica는 읽기 작업만을 위해서 사용해야 한다.

Network cost

• 데이터가 한 AZ에서 다른 AZ로 넘어갈 때 Network cost(복제비용)가 발생한다.
  - 만약 읽기 복제본이 같은 리전의 다른 AZ에 있다면 이 때는 비용을 지불하지 않아도 된다.
  
  

Multi-AZ

• 서로 다른 가용영역에 있는 standby 인스턴스의 경우 Master에 대해 동기식 복제가 일어나게 된다.
• 또한 standby 인스턴스와 Master 인스턴스는 서로 같은 DNS를 사용하기 때문에 장애가 발생할 경우 바로 standby 인스턴스가 장애 대응용으로 사용 된다.
  - 이를 통해 가용성을 높일 수 있다.
  - 그러면 이 때 Standby는 새로운 Master가 된다.
• 따라서, read replica는 재해복구만을 위해 multi-AZ로 셋업해서 사용하게 될 수 있다.
  - 이 경우 해당 인스턴스에는 read, write 어느 것도 할 수 없으며 이는 그저 대기 용도로만 사용된다.
  

### Single-AZ에서 Multi-AZ로 업그레이드 하는 방법 * multi-AZ를 생성할 경우 다운타임은 발생하지 않는다. - 따라서, DB를 중단할 필요는 없다. - "modify"를 클릭해 multi-AZ로 만들기만 하면 된다. - 이를 통해 Master는 바로 standby 인스턴스를 갖게 되며 이 때 동기적 복제가 일어난다. * 내부적으로는 다음과 같은 일이 발생한다. 1. Master DB의 스냅샷을 생성한다. 2. standby DB에 저장한다. 3. 동기 복제가 완료된다. 4. 사용자는 Multi-AZ에 있게 된다.

헷갈리지 않아야 하는 점은,

• standby는 동기 복제가 일어나며 읽기/쓰기 어느 것도 발생하지 않는다.
• read replica는 비동기 복제가 일어나며 읽기만 가능하다.

이는 용도에 따라 달라진다.

Aurora

• Postgres, MySQL과 호환 가능한 API이다.
• 3개의 가용 영역에 6개의 replica가 존재한다.
• Auto healing 능력이 있다.
• Multi AZ이며 Read Replicas를 auto-scaling 할 수 있다.
• Read Replica는 전세계적으로 존재할 수 있기 때문에 재해 복구 또는 지연 시간 단축이 가능하다.
• 저장공간은 10 GB ~ 128TB까지 확장 가능하다.
• 오로라 인스턴스는 EC2 인스턴스를 사용한다.
  - 만약 서로 다른 인스턴스를 사용 중이라면 커스텀 엔드포인트로 묶어서 사용할 수 있다.
• RDS와 같은 보안, 모니터링 기능을 제공한다.
• Aurora Serverless도 있다.
  - 예측 불가능한, 간헐적인 워크로드를 위해 사용 가능하다.
• Aurora Multi-Mater 기능이 있다.
  - 지속적으로 쓰기의 실패에 대응해야 하는 경우 multi-master를 이용해 대응할 수 있다.
  

Aurora는 RDS와 전반적으로 유사하지만 적은 관리와 높은 유연성, 그리고 높은 성능을 원하는 경우 사용하기 좋다.

Solutions architect 관점에서 보기

신뢰성

• RDS보다 더 높은 가용성을 지닌다.
• Aurora serverless 옵션이 있다.
• Aurora multi-master 옵션이 있다.
  

성능

• Read replica를 15개까지 가질 수 있다.
  - RDS는 5개까지만 가능하다.
• RDS보다 5배 더 좋은 성능을 갖는다.
  - AWS에 따르면 더욱 최적화된 architecture 덕분이라고 한다.
  

비용

• RDS와 마찬가지로 프로비저닝 된 EC2 instance 종류에 따라, 그리고 저장 공간 사용 정도에 따라 시간 당 지불한다.
• 오라클과 같은 엔터프라이즈 급 데이터베이스보다 저렴하다.