RDS

• Relational Database Service
• SQL 데이터베이스를 다룸
  - Postgresql
  • MySQL
  • MariaDB
  • Oracle
  • Microsoft SQL Server
  • Aurora (AWS Proprietary database)

RDS를 쓰는 것 vs EC2에 DB를 설치해서 쓰는것

• RDS를 쓰면
  - 프로비저닝 자동화, OS Patching
  - 지속적으로 백업되고 특정 시간대로 복구할 수 있음.
  - 모니터링 대시보드
  - 읽기 성능을 위해 레플리카를 읽도록 할 수 있음.
  - 재해 복구를 위한 Multi AZ
  - 업그레이드를 위한 유지관리창
  - 수직, 수평적 스케일링
  - EBS에 백업(gp2 or io1)
  - RDS->EC2로 SSH접근이 불가능함
  

Storage 오토 스케일링

• 수동으로 스케일링 하는걸 막아줌
• 최대 임계값, 리밋을 정할 수 있음.

Read Replicas

• 15개까지 만들 수 있음
• AZ내부, multi AZ, multi Region이 가능함
• 원본 인스턴스와 비동기로 복제됨
• 레플리카는 원본으로 변할 수 있음.
• 프로덕션 상황에서 데이터 분석등을 하고싶을 때 레플리카를 통해서 하면 원본 인스턴스에 아무런 영향이 없기 때문에 제품에 영향이 가지 않음.
• SELECT만 써야함
• 네트워크 비용
  - 다른 AZ이지만 같은 region임 -> 무료
  • region이 다르다면 복제 비용을 내게됨

Multi AZ (Disaster Recovery

• 동기 복제 (Replica는 비동기 복제)
• 1개의 DNS 이름을 가지고있음 -> 원본이 고장나면 같은 DNS이름이 있기 때문에 자동장애대응을 함 -> 가용성
• 원본이 고장나면 자동으로 대기 데이터베이스가 새로운 마스터 데이터베이스가됨
• 대기 데이터베이스는 못씀
• 리드 복제본은 multi AZ로 되어야함.
• single AZ -> Multi AZ로 갈때
  - 대기시간 없음 -> DB 중단 없음
  • 원본 DB 스냅샷 -> 새로운 AZ에 스냅샷으로 DB restore -> 두개의 데이터베이스에 동기화 설정됨 -> Multi AZ 셋업

Amazon Aurora

• AWS 독점 기술(오픈소스 아님)
• Postgresql & MySQL과 연동됨
• 클라우드최적화
• 자동으로 커짐 -> 10GB~128TB
• 레플리카 15개까지
• RDS보다 20퍼센트정도 비쌈
• 고가용성 & 스케일링 읽기
  - 3개의 AZ에 걸쳐 6개의 데이터 복제를 함
  • 6개중 4개만 쓰기에 필요하고 3개만 읽기에 필요함
  • peer to peer 복제를 통해 자가회복을함
    - 마스터가 30초동안 응답을 하지않으면 자동으로 장애조치함 -> 6개의 복제본 중 하나가 마스터가 됨
  • cross region 복제를 지원함
• Aurora DB Cluster
  • 자동으로 확장되는 공용 저장소 (10GB~128TB)
  • 마스터만 쓰기동작을 할 수 있음
    - DNS, Writer endpoint는 항상 마스터를 가리킴
  • read replica 는 오토스케일링됨
    - Reader Endpoint
    • 레플리카의 로드밸런싱 & 자동연결
• 기능
  • 자동 장애조치
  • 백업, 리커버리
  • isolation, 보안
  • industry compliance
  • push-button scaling
  • 정지시간 제로의 자동패치
  • Backtrack: 백업없이 어떤시점의 데이터든 복구해줌
  • Custom Endpoints
• Serverless
  - 자동화된 데이터베이스 인스턴스화와 실 사용 기반의 오토스케일링 베이스
  - 작업이 간헐적이고 예측 불가능한 경우에 초당 비용을 지불하기 때문에 실제로 On-demand가 될 수 있음
• Multi Master
  - 모든 인스턴스가 writer node임

RDS Backups

• Automated backup
  - 매일 백업 윈도우에서 전체 백업이 됨.
  • 매 5분마다 transaction 로그가 남음
  • 자동백업기록은 1~35일까지 지속된다. 만약 끄고싶으면 0으로 두면됨
• 수동 db snapshot
  - user가 수동으로 트리거해야함
  • 원하는 만큼 보존할 수 있음
  • 비용을 절감할 때 사용
    • RDS를 한달에 두시간만 사용할 때 2시간 동안 사용한 후 snapshot 저장 후 원본 데이터베이스 삭제
      • 데이터베이스를 다시 사용하고 싶을때 스냅샷 복구를 하면됨

Aurora Backups

• Automated backups
  - 1~35일 까지, 해제 불가능
  • 해당시간 내의 어떤 시간대라도 복구 가능함
• 수동 DB snapshot
  - 유저에 의해 트리거됨
  • 원하는 만큼 보존 가능

RDS & Aurora Restore option

• RDS/Aurora backup이나 스냅샷으로 새로운 database로 복구 가능함
• S3에서 mysql RDS database를 복구할 수 있음.
  - on-premises database를 s3에 백업함 (object storage)
  • 이 백업파일로 새로운 RDS instance로 복원 가능
• s3에서 aurora cluster 복구
  - 온프래미스 데이터베이스를 백업 가능함
  - percona XtraBackup 이라는걸 사용해야함
  • 복구도 마찬가지

Aurora Database Cloning

• 새롱운 오로라 DB 클러스터를 이미 존재하는거에서 복제하는것
• snapshot & restore보다 빠름
• copy-on-write protocol 사용
  - 처음 클론을 만들때 기존 db cluster와 같은 data volume을 사용함 (데이터 복사본이 없기때문에 빠르고 효율적임)
  - 업데이트가 새로운 디비에 만들어지면 추가적인 ㅅ저장소가 배정되고 데이터는 복사되고 분리된다.
• 매우 빠르고 효율적임
• production database에서 영향을 주지않고 staging database를 만들때 좋다.

RDS & Aurora Security

At-rest encryption

• database mater와 replica는 AWS KMS를 이용하여 암호화됨.
  - launch time에 정의됨 (옵션)
• 마스터가 암호화 되지 않으면 replica들은 암호화 될 수 없음.
• 암호화되지 않은 데이터베이스를 암호화하려면 DB snapshot & restore를 통해 암호화 해야함

In-flight encryption

• default로 TLS가 준비되어 있음 - 클라이언트는 AWS TLS 루트 인증서를 사용함

IAM authentication

• IAM rol을 이요해 데이터베이스에 연결할 수 있음.

Security Groups

• 네트워크 액세스를 설정 가능함

No SSH available

• RDS/Aurora는 SSH 액세스가 없음.

Audit Logs 는 가능함

• cloudWatch logs에 보내서 조금 더 오래 보존할 수 있음

RDS Proxy