[AWSCloudClubs] RDS, Read replica, Multi AZ, Aurora, Elastic Cache, Redis, Memchached

RDS 읽기 전용 복제본과 다중 AZ의 차이를 이해하고 사용 사례를 아는 것이 중요하다고 한다.

Disaster Recovery를 대비해서 Read Replicas(읽기 전용 복제본)을 Multi AZ로 설정할 수 있다. (O)
→ Multi-AZ에서 Read Replicas를 보유할 수 있도록 하는 것.

???

이 부분이 제일 헷갈렸다..

그리고 Elastic Cache에 대해 공부하면서

캐시는 read intensive workloads에서 DB의 load를 줄여준다.
→ 일반적인 쿼리는 캐시에 저장되므로 매번 DB를 쿼리하지 않아도 쿼리의 결과를 검색할 수 있기 때문이다.

를 보며 데이터베이스 수업도 떠오르고, 컴퓨터구조 수업도 떠올라서 재미있었다. 

억지로 재밌다고 하는건 절대 아니다..,

---

RDS (Relational Database Service)

Q. EC2 인스턴스 위에 자체 데이터베이스 서비스를 구축하는 대신 RDS를 사용하는 이유는 무엇일까?
A. RDS는 관리형 서비스이기 때문에 단순히 데이터베이스를 제공하는 것 외에도 다른 서비스를 제공한다.

• Automated provisioning, OS patching, Time restore, Monitoring, Read replicas, Multi AZ setup for Disaster Recovery, Scailing, Storage backed by EBS(gp2/io1) 등등
• 그러나 RDS 인스턴스에는 ssh를 적용할 수 없다. 즉, 기저 EC2 인스턴스에 엑세스 할 수 없다는 것.
  • RDS Custom을 이용하면 가능하다. 단 ,Oracle, Microsoft SQL server만 이용 가능하다.

RDS Storage Auto Scailing

• RDS 데이터베이스를 생성할 때, 원하는 스토리지 용량을 지정해야 한다. = Maximum Storage Threshold
  • application이 read/write를 하면 RDS가 storage를 auto scailing한다.

RDS Read Replicas for read scalability

• 주된 RDS 데이터베이스 인스턴스와 두 읽기 전용 복제본 사이에 Asynchronous replication(비동기식 복제)이 발생한다.
  • 결국 읽기가 일관적으로 유지된다는 것을 의미. 주 데이터베이스에 변경 사항이 발생한 후 일정시간 뒤에 복제본에 그 변경사항이 반영되기 때문이다.
• Read replicas는 SELECT 명령문에만 사용한다.

RDS Multi AZ

• Master DB의 모든 변화를 다른 AZ에 존재하는 RDS DB instance standby에 synchronous Replication
• 애플리케이션이 하나의 DNS name을 갖고 통신하며 master DB에 문제가 생길 때 standby DB에 자동으로 장애조치가 수행된다.
  • standby DB가 master가 되는 것.
  • standby는 scailing 목적이 아니다.
• Single AZ to Multi AZ
  • zero downtime, DB수정을 통해 multi AZ 기능을 활성화하기만 하면 된다. (ft. DB snapshot)

Amazon Aurora

고성능 클라우드 최적화 관계형 데이터베이스 서비스이다.
MySQL과 PostgreSQL과 호환되지만, Amazon이 데이터베이스 엔진을 최적화한 것.

• 1 Master, upto 15 Read Replicas, Store striping across 100s of volumes, Self healing with p2p replication(ft. block단위), Shared storage volume Auto expand
• Writer Endpoint : Pointing to the master
• Reader Endpoint : Connection Load Balancing
  • Auto scailing을 통해 항상 적절한 수의 읽기 전용 복제본이 존재하도록 할 수 있다. 그러나 애플리케이션 입장에서는 복제본이 어디에 있고 url은 무엇이고 어떻게 연결하는지 파악하기 어렵기 때문이다.
  • 모든 읽기 전용 복제본과 자동으로 연결되어 클라이언트가 reader endpoint에 연결될 때마다 읽기 전용 복제본 중 하나로 연결된다.
• Auto Scaling : Reader Endpoint extended, CPU Usage decreased
• Custom Endpoints : Define a subset of Aurora Instances as a custom endpoint
  • reader endpoint는 사라지진 않지만, 더이상 사용되지 않는다.
• Serverless :
  1. client는 Aurora가 관리하는 Proxy Fleets와 통신한다.
  2. 백엔드에는 많은 Aurora instance들이 workload에 기반하여 서버리스 방식으로 생성된다.
     1. capacity planning(provisioning)을 할 필요가 없다.
• Global Aurora : 1 Primary Region (Read/Write), Up to Secondary Region (Read only), Upto 16 Read replicas per secondary region
  • secondary region에서는 aurora global DB와 함께 데이터 복사 + application의 read only
  • 쳐외워 : Aurora global DB에서 평균적으로 cross-region replication은 1초 이하의 시간이 걸린다.
• Aurora는 sagemaker, Comprehend 등 Machine Learning과 결합되어 애플리케이션의 SQL query에 따라 ML service에 데이터를 보내고 예측을 받아와 애플리케이션에 반환하기도 한다.

RDS/Aurora Backups

• Automated Backups : Daily full backup of database (ft. 5min)
  • RDS는 비활성화 가능, Aurora는 비활성화 불가능
• Manual DB Snapshots : 원하는 기간동안 보관할 수 있다.

데이터베이스를 중지해도 스토리지 비용은 계속 지불해야한다.

→ 스냅샷을 만든 후, 원본 데이터베이스를 삭제하면 RDS 데이터베이스의 실제 스토리지 비용보다 저렴하다.

RDS&Aurora Security

• At-rest encryption : DB master&replicas에 저장된 데이터를 암호화한다. = 데이터가 볼륨에 암호화된다. using AWS KMS (ft. snapshot)
• In-flight encryption : 전송 중 데이터 암호화 기능을 갖추고 있으므로 클라이언트는 AWS TLS root certificates를 사용해야한다.
• IAM Authentication, Security Groups to control network access, no ssh, audit logs

Amazon RDS Proxy

• 애플리케이션을 RDS DB 인스턴스에 일일이 연결하는 대신 proxy에 연결하면 proxy 가 하나의 풀에 연결을 모아 DB 인스턴스로 가는 연결이 줄어든다.
• DB 인스턴스에 연결이 많은 경우 cpu, RAM 등 데이터베이스 리소스의 부담을 줄일 수 있다.
• DB에 개방된 연결과 시간초과를 최소화할 수 있다.
  • ex : Lambda함수의 연결 풀을 생성하면 Lambda 함수가 RDS 프록시를 오버로드한다.
• serverless, autoscailing, highly available (ft. multi AZ), IAM Authentication

ElasticCache

캐싱 기술인 Redis/Memcached를 관리할 수 있도록 도와준다.

애플리케이션을 stateless하게 도와준다.

• Solution Architecture : DB Cache, User Session Store
• Redis : Multi AZ with Auto-Failover, Read replica for high availablity, Backup and restore features, Supports Sets and Sorted Sets
  • 고가용성, 백업, 읽기 복제본 등을 위해 존재한다.
  • IAM 정책을 정의하여 AWS API-Level Security에 사용한다.
  • Redis AUTH : password/token, SSL in flight encryption
  • Redis Sorted sets : 요소가 추가될 때마다 고유성과 순서를 모두 보장
• Memchached : Multi-node for partitioning of data(sharding), No high availability(replication), Non persistent, No backup and restore, Multi-thread architecture
  • 여러 인스턴스가 모두 샤딩을 통해 동작한다.
  • 분산되어있는, 데이터가 손실되어도 괜찮은 경우에 사용하는 캐시
  • SASL-based authentication
• Lazy Loading : 모든 데이터가 캐시되고 데이터가 캐시에서 stale될 수 있다. (지체될 수 있다.)
• Write Through : DB에 데이터가 기록될 때마다 캐시에 데이터를 추가하거나 업데이트한다.
• Session Store : store temporary session data in a cache (using TTL features)

---

오답노트

Q. 다음 RDS (Aurora 아님) 기능들 중, 사용 시 SQL 연결 문자열을 변경하지 않아도 되는 것은 무엇인가요?
A. 읽기 전용 복제본 (X)
→ 읽기 전용 복제본은 DNS 이름을 갖는 새로운 엔드포인트를 추가한다. 복제본을 사용할 때에는 애플리케이션이 여러 엔드포인트 (DNS 이름)을 알고 각각의 복제본으로 읽기 요청을 보낼 수 있도록 애플리케이션의 코드를 수정해야 한다.
다중 AZ (O)
→ 다중 AZ는 활성화 상태의 DB 종류와 상관 없이 동일한 연결 문자열을 유지한다.

다중 AZ는 High Availability를 보장하지만, 성능 분산에는 기여하지 않는다.
즉, 주 DB에서 모든 R/W 작업을 처리해야하고, 대기 데이터베이스(Standby)는 failover가 일어날 때까지 사용되지 않는다.

Q. RDS PostgreSQL 데이터베이스의 특정 리전에서 정전이 발생했을 때 데이터베이스가 신속하게 다른 AWS 리전에서 읽고 쓰는 작업을 할 수 있도록 재해 복구 전략을 수립하려고 합니다. DR 데이터베이스는 가용성이 매우 높아야 합니다. 가장 적합한 방식은 무엇입니까?
A. 메인 데이터베이스에서 Multi-Region 설정을 활성화한다. (X)
→ RDS는 멀티 리전 간의 자동 복제/쓰기/읽기/동기화를 지원하지 않는다.

다른 리전에 읽기 전용 복제본을 만들고 해당 읽기 전용 복제본에서 다중 AZ를 활성화한다. (O)
→ Read Replica는 한 리전에서 생성된 데이터를 다른 리전으로 비동기적으로 복제한다.
실시간에 가깝게 복제되고, 읽기 전용 복제본을 승격하여 쓰기 기능을 갖춘 새로운 메인 데이터베이스로 전환할 수 있다.

Q. 암호화되지 않은 RDS DB 인스턴스를 암호화하는 방법?
A. 암호화되지 않은 RDS DB 인스턴스의 스냅샷을 생성하고, 스냅샷을 복사해 ‘암호화 활성화하기’ 박스를 체크한 뒤, RDS DB 인스턴스를 암호화되지 않은 스냅샷에서 복구하기

암호화되지 않은 RDS DB 인스턴스로는 암호화된 읽기 전용 복제본을 생성할 수 없다.

Q. 재해 복구 및 감사 목적으로 Aurora 데이터베이스에 대한 장기 백업을 저장해야 합니다. 어떤 것을 추천하시나요?
A. 자동 백업 활성화 (X)
Aurora 데이터베이스 복제 사용 (O)