[UDEMY] Section 9. AWS Fundamentals: RDS+Aurora+ElasticCache

아래는 Udemy의 Ultimate AWS Certified Solutions Architect Associate SAA-C03 강의내용 중 Section 9.

87 - 100강을 요약한 내용입니다.(Section 9. AWS Fundamentals: RDS+Aurora+ElasticCache)

 

1. Amazon RDS

1.1. Amazon RDS Overview

RDS는 관계형 데이터베이스 서비스를 위한 것임.

SQL을 사용하는 DB서비스으로 클라우드 상에 생성할 수 있고 관리되는 것임.

Postgres, MySQL, MariaDB, Oravle, Microsoft SQL Server, Aurora (AWS Proprietary database).

 

1.2. Advantage over using RDS versus deploying DB on EC2

프로비저닝과 OS패칭의 자동화

특정 타임스탬프에 지속적인 백업과 복구

모니터링 대시보드

향상된 읽기 성능을 위한 읽기 복제본

재난 복구를 위한 멀티 AZ 셋업

업그레이드를 위한 윈도우 유지

수직적, 수평적 스케일링 용량

EBS로의 스토리지 백업

단, 인스턴스에 SSH를 적용할 수는 없음

 

1.3. RDS - Storage Auto Scailing

RDS DB 인스턴스에 대해 동적으로 스토리지를 늘리는 것을 도움.

RDS가 무료 데이터베이스 스토리지 이상으로 운영중인 것을 감지하면 자동 스케일링함.

데이터베이스 스토리지를 손수 스케일링하는 것을 피함.

최대 스토리지 한계점을 세팅해야 함.

예측불가능한 워크로드가 있는 어플리케이션에 대해 유용함.

모든 RDS 데이터베이스 엔진들을 지원함.(MariaDB, MySQL, PostgresSQL, SQL Server, Oracle)

 

1.4. RDS Read Replicas for read scalability

AZ 내부에서, AZ를 가로질러서 15개까지 읽기 복제본을 가질 수 있음.

복제는 비동기적이므로 읽기 작업들은 결과적으로 일관됨.

어플리케이션은 읽기 복제본들에 영향을 주려면 반드시 연결 문자열을 업데이트해야 함.

 

1.5. RDS Read Replicas - Use Cases

일반 로드를 책임지는 프로덕션 데이터베이스를 가져야 함.

분석을 수행하는 보고용 어플리케이션을 운영해야 할 수 있음.

읽기 복제본을 그 새로운 워크로드를 위해 생성해야 함.

그러면 프로덕션 어플리케이션은 영향을 받지 않을 것임.

읽기 복제본들은 SELECT문을 위해 사용되고 INSERT, UPDATE, DELETE 문 등에서는 사용되지 않음.

 

1.6. RDS Read Replicas - Network Cost

데이터가 하나의 AZ에서 다른 곳으로 갈 때 AWS에서는 네트워크 비용이 발생함.

RDS 읽기 복제본들은 같은 리전 안에 있으면 AZ간 이동에 대한 요금을 내지 않아도 됨.

서로 다른 리전에 있으면 크로스 리전 비용이 발생함.

 

1.7. RDS Multi AZ (Disaster Recovery)

동기 복제본임.

DNS 이름이 하나임.

이용성이 증가함.

AZ에 대한 손실, 네트워크 손실, 인스턴스나 스토리지 손실등의 장애 극복 기능임.

앱에서 손으로 만든 간섭이 없음.

스케일링에 사용되지 않음.

장애 복구에 대해 그 읽기 복제본들은 멀티 AZ으로 셋업되야 함.

 

1.8. RDS - From Single-AZ to Multi-AZ

중단시간 없이 작동함. (DB를 스탑할 필요가 없음)

데이터베이스에 대해 '수정'을 클릭하기만 하면 됨.

스냅샷 획득하기, 새로운 AZ에 스냅샷으로부터 새로운 DB 복구하기, 두 데이터베이스간의 동기화 등이 내부적으로 실행됨.

 

1.9. RDS Custom

OS와 데이터베이스가 커스텀된  관리되는 Oracle 그리고 Microsoft SQL Server 데이터베이스임.

RDS는 자동 셋업, 작동하고 스케일링됨.

자동화 모드를 비활성화하고 커스텀을 수행해서 더 좋은 DB 스냅샷을 얻을 수 있음.

 

2. Amazon Aurora

Aurora는 AWS에서 소유하는 기술임.

Postgres 그리고 MySQL 양쪽 모두 Aurora DB에 의해 지원됨.

Aurora는 AWS 클라우드 최적화되어있고 MySQL on RDS보다 5배 더 나은 성능, Postgres on RDS보다 3배 더 나은 성능을 주장함.

Aurora 스토리지는 10GB에서 128TB까지 자동적으로 증가함.

Aurora는 15개까지 복제본을 가질 수 있고 MySQL보다 복제 처리가 빠름.

Aurora는 장애 복구 기능이 동시에 일어남.

Aurora는 RDS보다 20배 더 비용이 발생하고 더 효율적임.

 

2.1. Aurora High Availability and Read Scaling

3개의 AZ에 걸쳐서 데이터에 대해 6개의 복사본을 가짐.

하나의 Aurora 인스턴스는 쓰기를 책임짐. (master)

master에 대한 30초 내의 자동화된 장애 복구 기능.

15개까지 Aurora 읽기 복제본들이 읽기 작업을 함.

크로스 리전 복제를 지원함.

 

2.2. Aurora DB Cluster

쓰기 엔드포인트는 master에 대해 하나만 가르킴.

읽기 엔드포인트들은 로드 밸런싱되고 다수의 읽기 복제본들에 연결됨.

클러스터는 스토리지 볼륨을 공유하고 10GB부터 128TB까지 자동 확장됨.

 

2.3. Features of Aurora

자동화된 장애 복구 기능.

백압과 복구.

고립과 보안.

산업 규칙 준수.

푸시 버튼 스케일링.

자동화된 중단시간 없는 패칭.

향상된 모니터링.

루틴 유지.

백트랙: 백업 없이 어느 시점에든지 데이터를 복구.

 

2.4. Aurora Replicas - Auto Scaling

공유된 스토리지 볼륨에 대해 쓰기 엔드포인트는 한개임.

읽기 엔드포인트들에 대해 클라이언트가 많은 요청들을 하고 복제본들은 오토 스케일링됨.

 

2.5. Aurora - Custom Endpoints

커스텀 엔드포인트로서 Aurora 인스턴스들을의 서브셋을 정의함.

예를 들어, 분석적인 쿼리들을 특정 복제본들에 대해 수행함.

읽기 엔드포인트는 일반적으로 커스텀 엔드포인트들을 정의한 후에 사용되지 않음.

 

2.6. Aurora Serverless

자동화된 데이터베이스 인스턴스화 그리고 오토 스케일링은 실제 사용에 기반함.

빈번하지 않고 간헐적이거나 예측불가능한 워크로드들에 좋음.

용량 계획이 필요하지 않음.

매초마다 지불하고 더 비용 효율적일 수 있음.

 

2.7. Aurora Multi-Master

쓰기 노드들에 대해 지속적인 쓰기 유효성이 필요한 경우에 사용함.

새로운 마스터로서 읽기 복제본에 대응해 모든 노드들이 읽고 씀.

 

2.8. Global Aurora

Aurora 크로스 리전 읽기 복제본들은 장애 복구에 유용함.

Aurora Glabal Database들은 1개의 주요 리전을 가짐.

5개까지 부차적인 리전들을 가지고 리전마다 16개까지 읽기 복제본들을 가짐.

 

2.9. Aurora Machine Learning

SQL을 통해 어플리케이션들에 대해 머신러닝 기반의 예측들을 가능하게 함.

Aurora와 AWS ML 서비스간의 간단하고 최적화되고 안전한 통합.

Amazon SageMaker, Comprehend가 지원됨.

감정 분석, 상품 추천, 광고 타겟팅 등에 활용될 수 있음.

 

2.10. RDS Backups

2.10.1. 자동화된 백업

매일의 데이터베이스에 대한 백업이 자동화됨.

트랜잭션 로그들이 5분마다 백업되고 어떤 시점에서든 복구할 수 있음.

2.10.2. 직접 DB 스냅샷들을 가짐.

유저에 의해 직접 트리거됨.

원하는만큼 백업을 유지함.

 

2.11. Aurora Backups

2.11.1. 자동화된 백업

1에서 35일까지, 특정 시점에 대해 복구

2.11.2. 직접 DB 스냅샷

사용자에 의해 트리거되고 원하는 만큼 백업을 유지함.

 

2.11. RDS & Aurora Restore options

2.11.1. RDS / Aurora 백업 또는 스냅샷을 복구하는 것은 새로운 데이터베이스를 생성함.

2.11.2. MySQL RDS를 S3으로부터 복구.

온프로미스 데이터베이스로부터 백업을 생성.

Amazon S3에 그것을 저장함.

MySQL을 실행하는 새로운 RDS 인스턴스 위에 백업 파일을 복구함.

2.11.3. MySQL Aurora 클러스터를 S3으로부터 복구

Percona XtraBackup을 사용해 온프레미스 데이터베이스에 대한 백업을 생성함.

Amazon S3위에 백업 파일을 저장함.

MySQL을 실행하는 새로운 Aurora 클러스터 위에 백업 파일을 복구함.

 

2.12. Aurora Database Cloning

기존의 것으로부터 새로운 Aurora 디비 클러스터를 생성함.

스냅샷이나 복구보다 빠름. 그리고 비용 효율적임.

스테이징 데이터베이스를 프로덕션 데이터베이스로부터 생성하는 것에 유용함.

 

2.13. RDS & Aurora Security

AWS KMS를 사용해 암호화한 데이터베이스 마스터와 복제본들은 런치 시간에 정의되야 함.

마스터가 암호화되지 않았으면 읽기 복제본들도 암호화될 수 없음.

데이터베이스를 암호화하려면 스냅샷을 만들고 암호화된 채로 복구해야 함.

in-flight encryption: TLS가 기본, AWS TLS root 인증서들을 사용함.

IAM Authentication: IAM 역할들이 데이터베이스에 연결하기 위한 것임.

Security Groups: RDS / Aurora DB 에 접근하기 위한 컨트롤 네트워크임.

No SSH available: RDS 커스텀 제외

Audit Logs can be enables: 그리고 더긴 유지시간으로 클라우드워치에 보내짐.

 

2.14. Amazon RDS Proxy

완전히 관리된 RDS를 위한 데이터베이스 프록시임.

데이터베이스에 대해 설립된 디비 연결들을 모으고 공유하기 위한 앱들임.

데이터베이스 자원들에 대한 부하를 줄임으로서 효율화함.

RDS & Aurora 장애 복구 시간을 66%까지 줄임.

DB에 대한 IAM 인증을 강요하고 AWS Secrets Manager에 인증서들을 저장함.

RDS 프록시는 절대 공적으로 접근할 수 없음.

 

3. Amazon ElastiCache

3.1. Amazon ElastiCache Overview

ElastiCache는 관리되는 Redis 또는 Memcached를 갖는 것임.

캐시는 인메모리 데이터베이스이고 매우 높은 성능과 낮은 지연을 가짐.

읽기 집약적 워크로드들에 대해 부하를 감소시킴.

사용하려면 코드 수정이 많이 필요함.

 

3.2. ElastiCache Solution Architecture - DB Cache

어플리케이션이 일라스티캐시에 쿼리하고 불가능하면 RDS으로부터 조회해서 캐시에 저장함.

RDS에 대한 읽기 부하를 줄일 수 있음.

캐시는 반드시 무효화 전략이 필요하고 가장 최근 데이터가 사용되어야 함.

 

3.3. ElastiCache Solution Architecture - User Session Store

어플리케이션이 세션 데이터를 일라스티캐시에 작성함.

인스턴스는 데이터를 검색하고 사용자는 이미 로그인되었음을 확인함.

 

3.4. ElastiCache - Redis vs Memcached

3.4.1. REDIS

자동 장애 복구하고 멀티 AZ.

읽기 복제본들은 읽기작업을 스케일하고 높은 가용성을 가짐.

백업과 복구 피처들.

Sets와 저장된 Sets를 지원함.

3.4.2. MEMCACHED

데이터를 파티셔닝하기 위한 멀티노드.

높은 가용성이 아님.

퍼시스턴트가 아님.

백업과 복구가 안됨.

멀티 스레드 아키텍처임.

 

3.5. ElastiCache - Cache Security

일라스티캐시는 레디스를 위한 IAM 인증을 지원함.

Redis AUTH는 Redis 클러스터에 패스워드/토큰을 정하고

SSL 암호화를 지원하면서 캐시에 대한 더 높은 수준의 보안을 제공함.

Memcached는 SASL기반의 인증을 제공함.

 

3.6. Patterns for ElastiCache

3.6.1. Lazy Loading: 모든 읽기 데이터들은 캐시됨.

3.6.2. Write Through: DB에 쓰기작업이 있을 때 캐시 데이터를 더하거나 업데이트함.

3.6.3. Session Store: 일시적인 세션 데이터를 캐시에 저장함.

 

3.7. ElastiCache - Redis Use Case

게이밍 리더보드들은 계산적으로 복잡함.

Redis Sorted sets는 유일성과 원소 정렬 둘다를 보장함.

새로운 요소가 더해질 때마다, 실시간 랭크되고 올마든 순서로 더해짐.