AWS Database

• AWS Aurora
• RDS
• ElastiCache
• DynamoDB
• RedShift

 

Aurora

• MySQL, PostgreSQL 지원
• Single-Master / Multi-Master
• 15개의 Read Replica 생성 가능

Single-Master(대부분 Single로 사용)

한 개의 쓰기 전용 노드, 다수의 읽기 전용 노드

Multi-Master

다수의 읽기, 쓰기 전용 노드 (4개까지 생성 가능)

Multi-Master를 사용하면 Aurora의 여러 기능을 사용하지 못함

 

용량

자동 증감

 

분산 저장

각 AZ마다 2개의 복제본 저장 x 최소 3개 이상의 AZ (최소 6개의 복제본)

 

Failover

Writer가 죽을 경우 자동으로 Read Replica 중 하나가 Writer로 Failover

 

Aurora Global Database

• 전 세계 모든 리전에서 1초 내의 Latency로 데이터 access 가능
• 재해복구용도로도 사용 가능
  • 1초의 RPO(복구 목표 지점)
  • 1분 미만의 RTO(복구 목표 시간)
• 보조 리전에는 총 16개의 Read 전용 노드 생성 가능

 

백업

읽기 복제본 지원

RDS와 같이 자동/수동 백업 가능 

 

복제

기존 DB -> 새 DB를 복제하기 때문에 스냅샷을 통해 새 DB를 생성하는 것보다 빠르고 저렴함.

-> Copy-On-Write 프로토콜 사용

 

Copy-On-Write

Aurora는 모든 데이터를 페이지 단위로 저장하는데, 새 Clone을 생성하면 기존 페이지를 참고하고 있음.

변경이 생기면 해당 페이지만 새로 만들어서 붙여줌.

모든 페이지를 새로 생성하는 것이 아닌 변경된 페이지만 생성해서 붙이기 때문에 스냅샷을 통해 전체 DB를 생성하는 것보다 속도가 훨씬 빠르다는 장점이 있다.

 

Aurora는 아래와 같이 스토리지 볼륨의 페이지에 데이터를 저장한다.

 

복제본이 생성된다고 가정할 때, Clone DB는 Source DB의 데이터를 복사하는 것이 아닌 Source DB의

페이지 집합을 가르킨다.

 

만약 페이지 A의 데이터가 변경되면 Aurora는 새로운 페이지인 1A를 생성하고 기존 A 대신 1A 페이지를 가르키게 된다.

 

마찬가지로 복제본에서 페이지 4가 변경되면 Aurora는 새로운 페이지 4B를 생성하고 이 곳을 가르키게 된다.

 

Backtrack

기존의 DB를 특정 시점으로 되돌리는 것

기존 RDS는 특정 시점의 스냅샷을 사용하여 DB를 새로 만들기 때문에 시간이 많이 소요되고 주소 변경 등의 작업이 필요하다.

그러나, backtrack을 사용하면 기존 DB를 되돌리기 때문에 속도가 빠르고, 실수를 쉽게 만회할 수 있다.

 

종류

• Target Backtrack Window
  • 어느 시점만큼 데이터를 저장할 것인지(ex. 이틀 전까지의 DB는 모두 저장할 거야)
  • 지정 시점 이전으로는 Backtrack 불가능
• Actual Backtrack Window
  • 실제로 시간을 얼만큼 되돌릴 건지
  • Target Backtrack Window보다 작아야 함

 

특징

• MySQL만 가능
• 중간에 Backtrack을 설정할 수 없음
• Multi-Master 상태에서는 Backtrack 불가능

---

RDS

• 관계형 데이터베이스 ( <-> NoSQL--DynamoDB)
• 자동 업데이트
• 가상머신에서 동작
• CloudWatch와 연동
• Storage는 EBS 볼륨 사용
• Parameter Group
  • Root 유저만 설정할 수 있는 DB의 설정값들을 모아 그룹화한 것
• RI 가능(3년 약정으로 하면 약 56% 저렴하게)_
  • 인스턴스 타입 변경이 쉽지 않음
• 라이선스 비용이 추가되는 DB 엔진도 있음(MS SQL, Oracle)

암호화

- EBS 볼륨 암호화

 

백업

- 데이터는 S3에 저장

 

- 매일 스냅샷을 만들고 트랜잭션 로그 저장

-- 데이터가 생성, 수정, 사라지는 모든 기록 저장(특정 시간으로 롤백이 가능하다)

 

- 롤백할 때는 스냅샷을 기반으로 새 DB 클러스터를 생성

 

Multi AZ

• 주로 production level에서 이루어짐
• 두 개 이상의 AZ에 걸쳐 Master-Standby 자동 동기화
• Master 장애 발생 시 자동으로 다른 DB가 원본으로 승격된다.(DNS가 Standby DB로 변경된다.)
  • 평소에는 Standby DB로 접속이 불가능함.(DNS 주소가 주어지지 않기 때문에)
• Master가 돌고 있는 동안 Standby도 계속 동작하기 때문에 비용이 추가로 발생(안전성을 목적으로 두기 때문)

 

Read Replica

• 쓰기는 원본에, 읽기는 읽기 복제본에서 처리하여 워크로드 분산
• 안전성이 아닌 퍼포먼스 중점
• 총 5개까지 생성 가능
• 각각의 복제본은 고유 DNS가 할당됨(접근이 가능)
  • 원본에 장애 발생하면 수동으로 DNS 주소 변경해야 함
• 자동 백업이 활성화 되어 있어야 Read Replica 생성 가능
• 다른 AZ, 다른 Region에 있을 수도 있음

 

Multi Region

• 다른 Region에 지속적으로 동기화 시키는 DB 클러스터 생성
• 로컬 퍼포먼스(현지에 Latency 없는 서비스 제공) 혹은 DR 시나리오로 활용

	Read Replica	Multi AZ	Multi Region
목적	성능 향상	고가용성	DR/로컬 퍼포먼스
복제 방식	Async	Sync	Async
Active	Read만	Master만 읽기/쓰기 가능	Read만
Failover	수동	자동으로 StandBy로 failover	수동
Backup	기본적으로 백업 x	자동백업	자동 백업 가능

 

실습

 

프로덕션은 Multi AZ에 생성, 개발/테스트, 프리 티어는 Single 인스턴스로 생성해준다.

 

db는 기본적으로 퍼블릭 IP를 부여하지 않는다.(보안상의 이유)

[예]를 선택하면 퍼블릭 IP가 부여되고, [아니요] 선택 시 bastion과 같은 방법으로 DB에 접속해야 한다.